Intro
1.
피드 및 스토어 검색결과의 이미지 흐림 효과 및 프레임 드랍 현상
2.
스크롤을 했을때 메모리 할당후 해제되지 않는 메모리 누수 현상
3.
검색 페이지의 무한 스크롤 성능 개선
문제점 :
⇒ 스토어 이미지의 흐림 + 스크롤을 내릴수록 메모리가 축적됨에 따라 사용자성이 매우 떨어짐
⇒ 메모리의 사용량 증가에 따라 프레임 드랍현상 및 앱 크래시 발생
⇒ 많은 이미지를 보여주는 검색 결과 페이지에서 메모리의 할당량이 비정상적으로 올라가는 현상
현재 방식으로 서버에서 압축된 이미지 100% 값을 적용한 후 스크롤 테스트 해본 결과
(기존에는 10% 적용 되어 있음)
스크롤 시 메모리가 점점 쌓이는 걸 볼 수 있다.
메모리의 할당량이 점점 올라가는 모습을 확인 할 수 있다.
테스트폰인 J5, J7 기준으로 약 1.5~2.0GB에서 앱이 크래시 되는걸 확인 되었다.
지금 당장 프론트에서도 이미지 압축률 90% 적용하고 나면 지금은 문제가 없지만 이미지가 쌓여 결국엔 앱 크래시 초과치를 넘어서는 지점이 언젠가는 생길것이다.
그리고 이미지의 화질이 좋지 않은건 사용자성에 매우 떨어진다.
How to
이미지 관련 문제 해결 방안
1.
firebase crashlytics 연결 후 앱 강제종료될때 데이터 확인
2.
이미지 압축률 40% => 90% 압축한후 webp 파일로 변환
=> 그래도 비정상 종료 현상 발생
3.
정확히 크래시 나는 곳을 확인 후 페이지를 이동해도 다른 페이지로 가도 메모리가 계속 누적되는 현상 확인
리스트뷰의 addAutomaticKeepAlives, addRepaintBoundaries 옵션을 이용하여 간략하게 요약하여 List View 저장 기능 off
=> 메모리 누적 현상은 없어졌지만 여전히 이미지가 많은 위젯에 접근하면 비정상 종료 현상 발생
4.
cached_network_image 패키지의 문제점 발견
캐쉬 이미지를 앱에서 저장하고 사용을 하는데 그곳의 크키를 정하지 않고
그대로 저장하여 메모리를 많이 먹었던것으로 보입니다. (memCacheHeight, memCacheWidth 크기 설정)
ListView & Widget 관련 문제 해결 방안
1.
build() 비용 축소 (위젯 캡슐화)
•
기능이 너무 큰 단일 위젯을 나누어서 새로 렌더링을 하더라도 부담이 가지 않게 위젯 분할화
2.
ListView 저장 방식 변경
•
ListView Builder 위젯의 설정 변경
◦
ListView의 전체 cache를 저장하는 관련 설정을 현재 보이는 화면에만 받을 수 있게 설정 수정
기존 적용되어있던 방식
새롭게 변경한 적용 방식
2-1. Scroll to Top 기능 로직 변경
•
기존 방식은 가장 보편적인 스크롤을 가장 위로 보내는 방식을 사용했지만
◦
이렇게 했을 경우, 전체 스크롤을 0.n초만에 지나간 화면을 모두 렌더링을 하기 때문에 기능 사용시 메모리가 다시 축적이 되어 크래시 나는 경우가 있다.
•
해당 페이지를 다시 접속하는 방법으로 로직 변경
◦
Scroll to Top 기능을 사용하면 결국 사용자에게 보여지는 페이지는 가장 윗부분 첫 스크롤이므로 뒤로가기 한 후 다시 해당 페이지를 접속하여 처음 접속할때 스크롤을 보여준다.
◦
버튼을 클릭했을때, 페이지의 Route를 다시 초기화하고 이전에 봤던 스크롤이라면 스크롤 했던 위치는 저장하여 사용자가 이미 봤던 페이지는 다시 스크롤하여 기다리지 않는 작업을 진행했다.
무한 스크롤 성능 개선
1.
50~80%의 페이지를 내렸을때 다음 페이지의 API를 받아온다.
•
기존 방식에서는 페이지를 제일 밑으로 내렸을때 API를 호출 하는 방식을 사용했지만, 이렇게 사용하면 사용자 편의성에 떨어지기 때문에 미리 API를 받아온다.
2.
새로운 데이터를 받았다는 함수를 새로 만들어서 데이터를 처리한다.
•
화면의 받아서 위치 만으로 다음 페이지의 데이터를 처리하면 50~80% 스크롤만 계속 하면 API를 계속 call 하는 문제가 발생
•
따라서 새로운 데이터를 받지 않았다는 조건과 50~80% 위치의 스크롤 조건을 만족해야 다음 API를 호출 해야한다.
모든 기능을 적용하고 나서 메모리 포함하여 프레임까지 최적화의 성공한것을 볼 수 있다.
제주 아라동 검색후 모든 스크롤을 내린 메모리의 양
⇒ 첫 스크롤과 마지막 스크롤 모두 동일하게 약간의 메모리가 할당 후 해제된다.