Shulou(Shulou.com)06/02 Report--

In this issue, Xiaobian will bring you an example analysis of the behavior of "background invalid animation" in Android. The article is rich in content and analyzes and narrates it from a professional perspective. After reading this article, I hope you can gain something.

When an Android App retires to the background, as long as it's not killed, don't be surprised at what it does, because that's Android. However, when the user knows that an App continues to do invalid animation after retreating to the background, and this animation is completely meaningless, and the user does not know that he is doing animation, consuming the user's poor power, light is killed by multitasking, prohibit background running, heavy is directly uninstalled.

It's hard for ordinary developers to find this problem, but if you use Systrace regularly, 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, but also frequently do invalid animation.

The background animation here refers to that for some reason, after the application retreats to the background, when the user does not see any of the App interface, he is still constantly updating in the background, consuming CPU. There may be many reasons for this problem. After all, there are too many places to throw CALLBACK_ANIMATION to Choreographer, and each application may be different, but in the end, each application needs to fix it.

Below we will take two examples, from a technical point of view when the incident occurred and the reasons, I hope to see this article developers, check whether their application has this problem, if there is a change, no congratulations

Example-Netease News

After using Netease News, we will retreat Netease News to the background, then slide the desktop left and right, grab Systrace to see:

After Netease News arrives in the background, it continues to do Animation callback (in red box), and every frame is still operating in doFrame.

Zoom in on each doFrame and see that neither input nor traversal in Choreographer has been triggered, only animation callback has been executed

We select all the cpu parts on this Trace, and then sort by Wall Duration below, you can find that Netease News background animation takes the longest execution time. When the application is already in the background and invisible, it is still working so frequently, occupying CPU resources and consuming power. It should not be.

Grasp the corresponding MethodTrace to see, is doing animation, not closed, animation is still in each frame onAnimationUpdate callback, you can see here is caused by the use of Airbnb Lottie library, animation is not closed, so still do trigger

Example- QQ Music

Start QQ music, then go back to the desktop, slide the desktop left and right and grab Systrace and MethodTrace, you can see the same performance as Netease News above.

MethodTrace found when capturing QQ music background animation, it was also caused by no pause animation after retreating to the background, it was also the Lottie pot of Airbnb, and QQ music had three animations that did not stop, which was more serious than Netease News.

If you zoom in, you can see

Of course, not all of them are caused by Airbnb's Lottie animation library, such as the following, that is, ordinary animation does not end.

root cause

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

In the above two examples, Netease News and QQ Music are both caused by the use of Lottie to achieve animation, but there is no correct closure.

development suggestion

Someone in the Lottie library issue list mentioned this situation:

Ask questions:

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 invisible, stop all animation: pauseAnimation!!!

The above is an example analysis of the behavior of "background invalid animation" in Android shared by Xiaobian. If there is a similar doubt, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.