사이드 프로젝트에서 컴포넌트가 많은 뷰를 원해서 개발하는 도중, 그녀석을 맞닥뜨리고 말았다.
ANR급의 화면 렌더링에 이틀을 소비했던 주니어 안드 개발자의 고군분투기.. 지금 시작합니다.
뷰 그룹 확인하기
일단 첫번째로 확인했던건 뷰 그룹이 얼마나 많은지였습니다.
뷰의 중첩구조는 렌더링시간에 크나큰 영향을 끼칩니다.
둘 이상의 layout 과 measure 작업을 반복 수행해야 하는 것을 Double Taxing이라고 합니다.
Double Taxing으로 이어지는 몇 가지 시나리오 입니다.
- layout_weight 가 존재하는 LinearLayout은 자식 뷰를 두 번 측정해야합니다.
- GridLayout 의 weights나 fill gravity 는 전처리의 이점을 가지지 못합니다.
- RelativeLayout 은 레이아웃을 그릴 때 항상 최소 2회 이상의 작업을 거칩니다.
이처럼 Double Taxing을 통해, 렌더링이 급격하게 늘어나기 때문에 최대한 중첩을 Flat하게 유지해야 합니다.
Android에서는 Layout Inspecter로 해당 뷰의 레이아웃 트리구조를 확인할 수 있습니다.
Layout Inspector를 통해, 쓸모없는 View들을 소거 시키면 됩니다.
저는 Custom View를 했는데, CustomView의 ChildView를 merge를 통해 제거할 수 있습니다.
custom 1-depth줄이기 을 참고하시길 바랍니다.
프로파일러로 감지하기
레이아웃의 경우 16ms window 내에 draw, traversal, measure 프로세스가 전부 완료 되도록 해야합니다.
어느것이 문제인지 확인해보려면 Profiler를 사용하면 됩니다.
지금 inflate와 traversal이 전부 확연히 긴걸 알수 있습니다.
해당 부분을 좀더 확대해서 보면 어떤 레이아웃이 렌더링하는데 시간이 많이 잡아먹는지 알수 있습니다.
저같은 경우, RecyclerView를 측정하는데 시간이 오래걸려서, 해당 RecyclerView를 나중에 로드하는식으로 코드를 변경했습니다.
폰트 확인하기
폰트가 리소스를 많이 잡아먹는것 같아서 확인을 해보니
폰트가 여러개 적용되어 있는것을 발견할 수 있었습니다.
폰트를 한개만 적용하고 나니, 대단히 줄은걸 확인할 수 있었습니다.
아마 폰트 3개를 적용시키니 리소스가 4배 이상 불어놨던것 같네요.
아래의 두개의 작업만으로도 2.7초에서 0.7초사이까지 내려왔습니다.
처음에 ANR이 발생할만한 속도에서 장족의 발전을 했네요.
참고
UI PROFILER
속도 올리기
레이아웃 속도 개선하기 - 홍범
Gpu 렌더링 프로파일링
CPU 프로파일러를 사용하여 UI 버벅거림을 감지해보세요
overdraw 1-depth 줄이기
custom 1-depth줄이기
