Smooth Android Wear Animation (Android Performance Patterns Season 2 ep3)

Smooth Android Wear Animation (Android Performance Patterns Season 2 ep3)


Android – Padrões de desempenho Do you want your material design
inspired animation to be battery smooth on the user’s wrist and having the bonus
of being power efficient as well? I’m Hoi Lam. With a few simple but not
always obvious tricks, you can make your apps run smoothly
without straining the battery. Let’s take a look. One of the most important considerations
is the manipulation of large bitmaps. It is an expensive operation,
and you can save hugely by resizing bitmaps to what is needed
for your screen and crop the invisible
or transparent pixels out. For example, in the Santa watch face
we published during the 2014 holidays, we removed the transparent
areas around Santa’s hand. This reduced bitmap size by 97%
and increased frame rate by 56%. The reason for this performance gain
is that, on some devices, bitmaps are software rasterized. Getting rid of transparent pixels
greatly reduces the amount of work, which, of course, increases performance. Second, if you have a complex
and static graphical element, make sure that you only draw it once. For example, take my colleague’s
open source project, the “ultimate stopwatch”. Drawing all the elements
of the watch face in every frame would have cost about
100 to 150 milliseconds per frame. If you do the math, that’s only
about 10 frames per second. So instead of redrawing the
watch face in every frame, the app draws it once and saves it. When it redraws a frame,
it can load the saved watch face and draw the hand on top of it. So how do we implement this? Well, there are two ways. The first applies to general application
with a view hierarchy. The second relates to the specific case
of the watch face, which does not have a view hierarchy. For applications, you can refactor
the static background into a separate custom view
and set this layer type to hardware. For this type of view, the onDraw method will only be called once
when the view is first shown. Remember, this should only
be done for complex shapes. If the app just needs to draw a bitmap,
separating this into another layer will not improve performance. For watch faces, which do
not have a view hierarchy, and are not hardware accelerated,
override the onSizeChanged method in the watch face engine. Initiate your background object,
connect it to a canvas object, and draw on that. Whatever you draw on this canvas
will automatically be saved to the background bitmap. Of course, like all things
in computer science, there are trade-offs. In the case of offscreen canvas
rendering, there are two. First, we need to ask whether this
is faster than just drawing the image. In the case of the ultimate stopwatch,
the answer is yes. For a simpler design,
the answer may be no. Luckily, there is a simple way
to help you make the correct decision. You can use the Android Device Monitor
to see how your application or watch face is running. In Android Studio, go to Tools, Android,
and then Android Device Monitor, and select the device you want to profile. Generate a report by clicking
on the Systrace button. When prompted, select three items: Graphics, View Hierarchy,
and CPU Scheduling in your report. You can count the number
of SurfaceFlinger events per second during the sampling period
and obtain the frame rate. Second, we need to consider the
classic memory and processing trade-off. How will accelerated layers
take up video memory? For watch faces, the pre-drawn bitmap
requires up to 200 kilobytes of memory. For the ultimate stopwatch,
we made a conscious decision to trade memory for performance, because the processing time for each frame
was simply too long. Another technique that can save you pixels
is to consider where the two layers can be combined
without impacting the visuals. For example, with the Santa watch face,
we combined a blue sky with the minute mark around the edges,
resulting in a 39% gain in frame rate. Remember, when it comes to rendering,
less is more, because the fewer pixels you’re processing
the better your frame rates will be. Last but not least, how should developers
implement animations? Here are two sets of advice,
one for general application, the other for watch faces. For general application,
you should use the property of view animation framework. This enables the system to help determine
the most optimal frame rates for your animation. For watch faces, since that
does not have a view hierarchy, the recommendation is slightly different. Your aim should be to make
your animation code run as fast and as efficient as possible. For fluid animation on Android Wear,
aim for 30 frames a second. But more is better. In addition, please consider
if having one frame per second or one frame per minute,
rather than full animation, will be sufficient, as this will allow
the processes to sleep, saving significant battery power. To implement this, use a handler
which sends a delay message at set period and trigger an update. For a detailed example, please refer
to the analog watch face example. At the end of the day,
it’s important to realize that Android Wear is based on Android. As a result, many optimization
tips which works on Android also applies to Android Wear. There are lots of performance practices
and tips that you should know about. So check out the rest of the
Android Performance Pattern videos. Also, join the G+ community
for Android Wear and Android Performance Patterns
for more updates. I’m Hoi Lam, and thanks for watching. Android Wear is for people on the move.
So let’s keep those pixels moving. And remember, Perf Matters. (music playing)

2 Replies to “Smooth Android Wear Animation (Android Performance Patterns Season 2 ep3)”

Leave a Reply

Your email address will not be published. Required fields are marked *