Layout traversals on Android
summary
Android batches UI work on a per-frame tick (≈60fps, ~16ms) via Choreographer (Jellybean); input runs first, then animations, then traversal. requestLayout bubbles up to the root (ViewRootImpl) and only schedules one traversal per frame but each call walks parents, so deep hierarchies cost time. draw builds display lists → GPU; use hardware layers to avoid recreating them every frame. Avoid allocations in onDraw, avoid layout changes during animations, and invalidate regions not whole views.
AI-written summary · about
chapters (8)
- 0:00Start
- 8:59PRE-JELLY BEAN
- 12:53CHOREOGRAPHER
- 15:51LAZY MEASURE
- 16:39FRAME IT
- 17:13DISPLAY LISTS
- 20:40requestLayout()
- 22:05invalidate(...)
related talks
39mView performance deep dive
48mLet's sprinkle some #PerfMatters on our ViewGroups (fr)
37mMulti-threaded Rendering on Android (with Litho & Infer)
28mHow Android Uses Data Structures Behind the Scenes
45mImplementing Modern Android Architecture
45mExploring the possibilities of Unidirectional Data Flow Architectures on Android (en)
46mModern Android: How to ditch Activities and Fragments
49mRendering without lumpy bits