Huyen Tue Dao's talk at DroidKaigi 2016: "Loving Lean Layouts". Discusses why Android developers should strive to create efficient layouts and presents tricks and good practices for achieving this.
CPU) • No. of views, depth of view tree • No. of measure() and layout() executions • Bad performance → UI/animations jank • Maintainability • Complexity ∝ effort to maintain/refactor • Readability • Stability: a change to one part affects other part 4
starts measure/layout starting at root. r r r r Some layouts need multiple measure/layout passes, e.g. RelativeLayout Lists make many copies of same layout Deep hierarchies increase complexity and dependency
Used to be standalone; now in Device Monitor • Tree representation of view hierarchy • Evaluates performance of measure(), layout(), and draw() phases • Best: use on physical device running 4.1 up HIERARCHY VIEWER :
→ interactive reports • Frame rendering → how much time measure/layout takes up; warns of frames that exceed 16.6ms needed for 60fps • dumpsys: collects and dumps “interesting information” about system services status • adb shell dumpsys gfxinfo <PACKAGE_NAME> → perf info related to frames of animation • adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats → detailed frame timing info; on Marshmallow SYSTRACE + DUMPSYS :
not good ideas. • These things are good candidates for things that you should fix first. • Generally, straightforward: • Don’t nest weights • Remove useless views • Don’t nest too much MAKE LINT HAPPY :
opt for simplest • Often view attributes/features can replace multiple views. • TextView compound drawables • Spannable • LinearLayout → android:divider • If you need a placeholder/divider, just use a regular View. • Sometimes you just need to pick the right view/layout. SIMPLIFY AND REDUCE :
Total control over measure/layout logic. • Mitigate double-layout phases from platform layouts. • Starting out? Try with simple, straightforward layouts. • Also: totally custom Views (draw all the things). • Balance performance benefits with development effort. GO CUSTOM :
how to identify possible problem areas • Use simplest solutions where possible • Fewer/flatter Views and ViewGroups • “Don’t do too much stuff.” • Don’t use RelativeLayout at the root! Romain and Chet said so. • Don’t let problems accumulate • Balance performance benefit with effort required