Analysis of "background invalid animation" behavior in Android

When an Android App is put into the background, as long as it is not killed, no one will be surprised at what it does, because this is Android. However, when users know that an App is still performing invalid animations after it is put into the background, and this animation is completely meaningless, and users do not know that it is performing animations and consuming the user's poor battery, at the very least, it will be killed by multitasking and prohibited from running in the background, or even directly uninstalled.

It is difficult for ordinary developers to find this problem, but if you use Systrace frequently, open dozens of applications and then return to the desktop, swipe left and right to grab Systrace, you can easily find that there are always a few background applications that are frequently performing invalid animations.

The background animation mentioned here means that for some reason, after the app retreats to the background and the user cannot see any of the App interface, it is still constantly updating in the background, consuming CPU. There may be many reasons for this problem. After all, there are too many places where CALLBACK_ANIMATION is thrown to Choreographer, and each app may be different, but in the end, each app still needs to fix it.

Below we will use two examples to explain the situation and cause of the incident from a technical perspective. I hope that developers who read this article will check whether their applications have this problem. If so, correct it. If not, congratulations.

Example - NetEase News

After using NetEase News, we will exit NetEase News to the background, then slide the desktop left and right to capture Systrace:

After NetEase News arrives at the background, it continues to do the Animation callback (in the red box), and each frame is still in the doFrame operation

Zooming in on each doFrame, we can see that neither the input nor the traversal in Choreographer is triggered, only the animation callback is always executed.

We select all the CPU parts in this trace, and then sort by Wall Duration. We can find that the background animation of NetEase News takes the longest time to execute. When the application is already in the background and invisible, it is still working so frequently, occupying CPU resources and consuming power. This is really not right.

From the corresponding MethodTrace, we can see that the animation is being done and has not been closed. The animation is still calling onAnimationUpdate in each frame. We can see that this is caused by the use of Airbnb's Lottie library. The animation is not closed, so it is still being triggered.

Example - QQ Music

Start QQ Music, then return to the desktop, slide the desktop left and right and capture Systrace and MethodTrace. You can see that the performance is consistent with the above NetEase News.

When capturing the MethodTrace of the background animation of QQ Music, I found that it was also caused by not pausing the animation after exiting to the background. It was also the fault of Airbnb's Lottie. In addition, QQ Music had three animations that were not stopped, which was more serious than NetEase News.

Zoom in and you can see

Of course, not every problem is caused by Airbnb's Lottie animation library. For example, the following example shows that the normal animation does not end.

root cause

The root cause is that the application does not pause the animation after it becomes invisible, which causes the animation callback to be refreshed after the application switches to the background. However, since it is invisible at this time, the Input Callback and Draw Callback will not be triggered, so there will be no drawing operation. In other words, the refresh of this Animation is completely meaningless (of course, it may also be a business requirement?)

In the above two examples, NetEase News and QQ Music both used Lottie to implement animations but did not close them correctly.

Development suggestions

Someone mentioned this in the issue list of the Lottie library:

Ask a question:

• I recently did some benchmarking on an app which uses lottie to do some animations (autoplay and looping). I noticed that there is quite some CPU usage when the app is in the background and tried to investigate.
• It seems to me looping animations do not pause/stop when the containing LottieAnimationView is off screen, and/or the Activity is paused.
• I believe this is due to the cleanup code being only in onDetachedFromWindow() which is not necessarily being called once the Activity goes into a paused state and most definitely not, when the view is simply not visible (GONE, INVISIBLE ) anymore.

Solution:

• Overriding LottieAnimationView and doing the following solves the visibility issue for me and Lottie is paused when not visible.

 @Override
 protected void onVisibilityChanged(@NonNull View changedView, int visibility) {
    super.onVisibilityChanged(changedView, visibility);
    if (visibility == VISIBLE && wasAnimatingWhenVisibilityChanged) {
 resumeAnimation();
 } else {
 if (isAnimating()) {
            wasAnimatingWhenVisibilityChanged = true ;
 pauseAnimation();
 } else {
            wasAnimatingWhenVisibilityChanged = false ;
 }
 }
 }

In short: When the App is not visible, stop all animations: pauseAnimation!!!