Improve the performance of Android animations through the hardware layer

There were a lot of people who asked me why in the applications they developed, the performance of the animations was poor. For this kind of problem, I often ask them: Have you ever tried to solve the performance problem of animation at the hardware level?

As we all know, the view redraws itself when the animation is being played during the display of each frame. But if you use the view layer so that the view is rendered once and then placed in a buffer outside the screen (that is, layer), so that the view is constantly being reused instead of redrawing again and again, this kind of animation performance problem is solved.

In addition, the processing of images by the hardware layer is cached on the GPU, making it more efficient to perform specific operations on the view during animation playback. Simple transformation animations, such as panning, rotating, zooming, and fading, can be rendered quickly by leveraging hardware acceleration, and most animations are just a combination of these simple animations, so we can try to use hardware acceleration to improve the performance of these animations.

Usage

The API to set the layer cache for view is simple: just call View.setlayertype (). But we should only use the hardware layer briefly, because the hardware layer is not just responsible for the drawing of our page (after the animation has been drawn and possibly elsewhere), the basic flow is as follows:

1. Call View.setlayertype (View.layer_type_hardware, NULL) for each View to be cached during the animation
2. Run animations
3. When the animation ends, the hardware is consumed by View.setlayertype (View.layer_type_none, NULL)

1234567891011121314151617

//Set the layer type to hardwareMyView. Setlayertype(View. Layer_type_hardware, null); //Setup the animationobjectanimator animator = objectanimator. Offloat(myView, View. Translation_x, ( ); //ADD a listener that does cleanupanimator. AddListener(new animatorlisteneradapter() { @Override Public void onanimationend(Animator animation) { myView. Setlayertype(View. Layer_type_none, null);   }});//Start the animationanimator.   Start();

If the minimum version of the app is greater than 16, and you're using Viewpropertyanimator in your app, you can do it with a simpler Withlayer () method:

12345

myview. Animate     . Translationx (150   . Withlayer ()   . Start

With this, your animation will be silky smooth!

Precautions

hahaha, do you really think it's that simple? Too young, too naive!

While it's amazing how hardware acceleration can improve the performance of your animations, if you're using the wrong posture, the problem with animation performance can cause you 100 times times more headaches. Remember my words, don't misuse the layer cache view!

The reason is simple:

First, in some cases, drawing tasks done with hardware acceleration are more complex than the normal View drawing process. It takes more time to cache the layer because the entire rendering process becomes the following two procedures: 1, the View is drawn to a layer in the GPU, and 2, the GPU draws the layer into the Window. If the View's drawing process finishes faster than the GPU draws the layer's content into the Window, it can cause unnecessary overhead during the initialization of the drawing.

Second, as with all caching operations, the cache operations we have done here are also subject to cache invalidation. Any action that calls View.invalidate () during animation playback will cause the layer to redraw. Repeating the refresh will leave the layer advantage completely unused, as the hardware (as mentioned earlier) adds unnecessary overhead in the process of setting up the cache. If you need to constantly re-cache the content into a layer, it will certainly have a big impact on performance.

This is a common problem because animations often have multiple parts that can be transformed. If you are setting up an animation, it has the following three parts that emit transformations:

父布局：ViewGroup
--> Child View 1 (向左平移)
--> Child View 2 (向右平移)
--> Child View 3 (向上平移)

If you set up a separate layer for viewgroup, the layer will constantly cache the content because the cache content is invalidated because the viewgroup (consider it a whole) is constantly changing because of the animation of its child View. And every sub-View that takes place is just a translation operation. In this case, we should set a layer for each of the sub-View and do not set the layer for ViewGroup as the parent layout.

Because I didn't know it at first, so I'm going to repeat it now: hardware acceleration should usually be done for multiple view settings layers, so that these view will not be refreshed during animation playback.

"Show Hardware layers Updates" is a very useful development tool that we can use to check if the application has the problem I just mentioned. As long as the View draws a layer of the GPU, it will blink the screen once. In this post's scenario, it should blink once the animation starts (that is, the layer's first draw). However, if View always shows the green of the entire piece during the playback of the animation, the above mentioned cache invalidation problem exists in our code.

Third, using a hardware layer consumes a certain amount of GPU memory, and the last memory leak that every developer wants to see is likely to happen here. So we should use hardware acceleration only when necessary, as in the process of playing the animation.

In general, there are no hard rules for using hardware acceleration. In fact, the Android drawing system is much more complex than I thought, and in all of the performance issues, the View measurement is a key point. Turning on the "Show GPU drawing Information" and "Show hardware Refresh" Options can help us to determine whether the layer is improving or reducing performance.

Sample

I have developed a sample App to teach you how to use basic hardware acceleration, source code here.

Here is a real-world diagram of the "Show GPU drawing information" option on my Galaxy Nexus phone (some old, and very card):

When hardware acceleration is not turned on, the performance of the animation is really shocking. Its performance evaluation continues to exceed the Green Line, which makes people very headache. On the contrary, the performance evaluation has been under the green Line since the hardware acceleration was turned on, which is very satisfying.

The third picture shows the damage caused by the layer cache failure during the animation playback. A large portion of the performance gains from hardware acceleration are wasted by cache invalidation.

(Here's another point to explain – if the cache fails, why isn't its performance degraded to the first picture?) To be honest, I'm not particularly aware of the mysteries, but it's clear that the hardware layer has been optimized to some extent, making every redraw less resource-intensive than it used to be. Even so, we should use hardware acceleration correctly! )

A word summed up this article: hardware acceleration is a blessing is also a curse, so be sure to use it correctly!

Improve the performance of Android animations through the hardware layer