當(dāng)一個(gè) Android App 退到后臺(tái)之后，只要他沒(méi)有被殺死，那么他做什么事情大家都不要奇怪，因?yàn)檫@就是 Android。但是當(dāng)用戶知道一個(gè)你一個(gè) App 退到后臺(tái)之后還在持續(xù)做無(wú)效的動(dòng)畫，而這個(gè)動(dòng)畫完全是無(wú)意義的，而且用戶還不知道他在做動(dòng)畫，消耗用戶那可憐的電量的時(shí)候，輕則被多任務(wù)殺掉，禁止后臺(tái)運(yùn)行，重則直接卸載。

一般的開發(fā)者很難發(fā)現(xiàn)這個(gè)問(wèn)題，但是如果你經(jīng)常使用 Systrace ，多開幾十個(gè)應(yīng)用然后退回到桌面，左右滑動(dòng)抓取 Systrace ，就可以很容易發(fā)現(xiàn)，總有那么幾個(gè)后臺(tái)的應(yīng)用，還在頻繁地做無(wú)效的動(dòng)畫。

這里說(shuō)的后臺(tái)做動(dòng)畫，指的是由于某種原因，應(yīng)用在退到后臺(tái)之后，用戶看不到任何這個(gè) App 界面的時(shí)候，他仍然在后臺(tái)不斷地更新，耗費(fèi) CPU。引起這個(gè)問(wèn)題的原因可能有好多個(gè)，畢竟 往 Choreographer 扔 CALLBACK_ANIMATION 的地方太多了，而且每個(gè)應(yīng)用可能都不一樣，但最終還是需要各個(gè)應(yīng)用去做修復(fù)

下面我們就以兩個(gè)實(shí)例，從技術(shù)的角度來(lái)看一下事件發(fā)生時(shí)候的情況和原因，希望看到這篇文章的開發(fā)者，檢查一下自己的應(yīng)用是否有這個(gè)問(wèn)題，有則改之，無(wú)則恭喜

實(shí)例 - 網(wǎng)易新聞

我們?cè)谑褂镁W(wǎng)易新聞后，將網(wǎng)易新聞退到后臺(tái)，然后左右滑動(dòng)桌面，抓 Systrace 來(lái)看：

網(wǎng)易新聞到后臺(tái)之后還在持續(xù)做 Animation 的回調(diào)(紅框內(nèi))，每一幀都還是在 doFrame 操作

放大每一個(gè) doFrame 來(lái)看，Choreographer 中的 input 和 traversal 都沒(méi)有觸發(fā)，只有 animation 的回調(diào)一直在執(zhí)行

我們把這份 Trace 上的 cpu 部分全選，然后下面按照 Wall Duration 排序，可以發(fā)現(xiàn)網(wǎng)易新聞后臺(tái)動(dòng)畫執(zhí)行時(shí)間最長(zhǎng)。應(yīng)用已經(jīng)在后臺(tái)且不可見的時(shí)候，還在這么頻繁地工作，占用 CPU 資源，消耗電量，實(shí)在是不應(yīng)該

抓對(duì)應(yīng)的 MethodTrace 來(lái)看，就是在做動(dòng)畫，沒(méi)有進(jìn)行關(guān)閉 ，動(dòng)畫依舊在每一幀進(jìn)行 onAnimationUpdate 的回調(diào) ，可以看到這里是因?yàn)槭褂昧?Airbnb 的 Lottie 庫(kù)導(dǎo)致的，動(dòng)畫沒(méi)有關(guān)閉，所以還是一直在做觸發(fā)

實(shí)例 - QQ音樂(lè)

啟動(dòng) QQ 音樂(lè)，然后回到桌面， 左右滑動(dòng)桌面并抓取 Systrace 和 MethodTrace ，可以看到跟上面的網(wǎng)易新聞的表現(xiàn)一致

抓取了 QQ 音樂(lè)的后臺(tái)動(dòng)畫時(shí)候的 MethodTrace 發(fā)現(xiàn)，也是由于退到后臺(tái)之后，沒(méi)有暫停動(dòng)畫導(dǎo)致的，也是 Airbnb 的 Lottie 的鍋， 而且 QQ 音樂(lè)有三個(gè)動(dòng)畫沒(méi)有停止，比網(wǎng)易新聞還要嚴(yán)重一些

放大后可以看到

當(dāng)然也不是每一個(gè)都是 Airbnb 的 Lottie 動(dòng)畫庫(kù)引起的，比如下面這個(gè)，就是普通的動(dòng)畫沒(méi)有結(jié)束

根本原因

根本原因是應(yīng)用在不可見之后，沒(méi)有將動(dòng)畫暫停，導(dǎo)致應(yīng)用切換到后臺(tái)之后，依然在刷新動(dòng)畫的回調(diào)，但此時(shí)由于是不可見的，不會(huì)觸發(fā) Input Callback 和 draw Callback ，所以也不會(huì)有任何的繪制操作，也就是說(shuō)這個(gè) Animation 的刷新完全是沒(méi)有意義的(當(dāng)然也有可能是業(yè)務(wù)需求?)

上面兩個(gè)例子里面，網(wǎng)易新聞和 QQ 音樂(lè)都是因?yàn)槭褂昧?Lottie 來(lái)實(shí)現(xiàn)動(dòng)畫，但是沒(méi)有正確的關(guān)閉導(dǎo)致的。

開發(fā)建議

Lottie 庫(kù)的 issue 列表里面有人提到了這個(gè)情況：

提出問(wèn)題：

• 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.

解決方法：

• 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; 
        } 
    } 
} 

總之就是 ： 當(dāng) App 不可見的時(shí)候，停止所有的動(dòng)畫：pauseAnimation!!!