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 • Evaluates performance of measure(), layout(), and draw() phases • Best: use on physical device running 4.1 up • Do not use runtime numbers given in Hierarchy Viewer; completely inaccurate 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 • FrameMetricsListener API: Android N; framestats without 120 frame limit SYSTRACE + DUMPSYS :
not good ideas. • Good candidates for things that you should fix first. • Don’t nest weights • Remove useless views • Don’t nest too much MAKE LINT HAPPY :
opt for simplest • Often attributes or other techniques can replace multiple views, e.g.: • TextView compound drawables • Spannable • Placeholder/divider → View or Space. • Sometimes you just need to pick the right view/layout. • Less views, less levels, less nesting • ConstraintLayout SIMPLIFY AND REDUCE :
Total control over measure/layout logic. • Mitigate double-layout phases. • Also: totally custom Views (draw all the things). • Start out with simple, straightforward layouts. • Balance performance gains with development effort. GO CUSTOM :
simplest solutions where possible • “Don’t do too much stuff.” • Fewer/flatter Views and ViewGroups. • Don’t use RelativeLayout at the root! • Don’t let problems accumulate. • Balance performance gains with development effort.