fancy animations andsmooth transitions are at the core ofmodern mobile app design. while these things may makebeautiful, transcendent experiences for yourusers, it's easy to forget what they might be costingyou, in terms of performance.
Android activity, my name is colt mccanlis. and writing performantandroid applications start with the simplestep of understanding what's going on inthe android system,
when you update the visualproperties of a view. remember that to drawsomething on your device, android generally needs toconvert all that high-level xml into some thatthe gpu can accept and use to render to the screen. this is done with the helpof an internal object called a display list. i display list basically holdsall the information needed to render a view on the gpu.
it contains a list ofany gpu resident assets that might be needed,as well as a list of commands toexecute to opengl, when it's time to render it. the first time a viewneeds to be rendered, a display list iscreated for it. and when we need to renderthat view to the screen, we execute that display list bysubmitting its drawing commands to the gpu.
if we want to render thatview again in the future, like if it's positionchanged on the screen, we simply need to execute thatdisplay list one extra time. however, in the future, ifsome visual part of the view changes, the previous displaylist may no longer be valid. as such, we'll need to go back,recreate the display list, and then re-execute it onceagain, to update the screen. but remember this. any time the drawing contentof your view changes,
it will repeat this processof recreating the display list and re-executing it to thescreen, the performance of which varies,depending on how complex your review actually is. and depending on thetype of visual change, there's other impact on therendering pipeline as well. for example, let's say, a textbox suddenly doubles in size, causing the parent container toreposition other sibling views, before updating its own size.
in this case, we'veupdated one view, and it cascaded to other workthat needed to be done as well. these types of visualchanges require additional stages of therendering pipeline to occur. see, when the sizingof your view changes, the measure phasewill be kicked off. and it will walk throughyour view hierarchy, asking each view whatits new sizes are. and if you change the positionof things, call request layout,
or if a view grouprepositions its children, the layout phase will kickoff, traverse the hierarchy, and figure out whereeverything needs to be located. and you need to be consciousthat each one of these stages takes time to run. while by themselves, thatmay not be impactful, when there's a suddenlarge amount of views that get invalidated orrepositioned, this can trigger a largeperformance drain, which means,
to improve the overallperformance of your rendering system minimizinginvalidations in layouts is a really greatplace to start. of course, you'llneed some way to get more specificinformation about where your problems are showing up. firstly, you canget a better sense of what part of yourrendering pipeline has issues by turning on theprofile gpu rendering tool
on your device, whichwill provide you with a handy, at-a-glance viewof the time it took to create, execute, and process portionsof your drawing pipeline. secondly, you can get a senseof what types of invalidations are occurring inyour application, by turning on the showgpu view updates option. any time and invalidationoccurs in your app, you'll see invalidatedpart briefly flash red, which can helpyou understand what
parts of your screen aregetting invalidated, even for the simplest of actions. thirdly, make sure you're usinghierarchy viewer to constantly check your viewhierarchy and work to keep it as flatas possible, trying to remove any redundant views. this will help reduce theoverhead of the layout and measure phases whenthey actually occur. but this is just the beginning.
for more information on reducinginvalidations, flattening your hierarchy, andusing hardware layers, check out the rest of theresources on the android performance patterns page. and don't forget to jointhe google community
for more great tips and tricks. so keep calm. profile your code. and always remember,perf matters.
