在卡頓數(shù)據(jù)里，iOS13退到后臺(tái)占了50%左右。這個(gè)特定場(chǎng)景讓我們困擾了很久，使用instruments分析了工程在退到后臺(tái)時(shí)CPU的變化情況。并得出以下結(jié)論：

1. 退到后臺(tái)一瞬間CPU占用率升高，同時(shí)產(chǎn)生的操作太多

2. 主線程占用比例大

3. 過(guò)多的線程

4. 神策，SDWebimage，TD，ADJust等使用了backgroundTask，十分消耗資源

5. 并且在backgroundTask中進(jìn)行了大量耗時(shí)操作

6. JPush直接創(chuàng)建了一個(gè)Runloop在運(yùn)行，長(zhǎng)期持有系統(tǒng)資源，并且在退到后臺(tái)時(shí)進(jìn)行文件寫(xiě)入

針對(duì)上面的4，5我們可以比較容易觸達(dá)到，所以制定以下策略：

1. 首先嘗試攔截backgroundTask，并根據(jù)其ID，進(jìn)行分時(shí)處理

2. 如果不行，嘗試單獨(dú)hook每個(gè)SDK的方法，進(jìn)行分時(shí)處理

具體分析過(guò)程如下，測(cè)試機(jī)型，iPhone7 iOS13.3.1。

國(guó)內(nèi)的工程在退到后臺(tái)之后，我們可以看到，CPU的峰值一下飆升到了90%。

Image

從圖中可以看出來(lái)，主要有兩個(gè)高柱，我們分別來(lái)看，其中究竟做了什么。

Image

在第一個(gè)高柱中，占用CPU峰值為40%。從堆棧中可以看出，JPush占比47.8%，其中它生成了一個(gè)新的Runloop在不斷運(yùn)行它的的業(yè)務(wù)，其中退到后臺(tái)的操作主要為給緩存寫(xiě)入數(shù)據(jù)。

還有兩個(gè)線程分別為21.7%（bugly），21.7%（微信），主線程占比8.6。

從這里可以看出，其中JPush在退到后臺(tái)的瞬間對(duì)CPU使用率影響巨大。

Image

在第二個(gè)高柱中，可以看到CPU使用率峰值達(dá)到了90%，其中主線程占比65%，而其中神策為10%，SDWebimage為5%，還有一部分無(wú)法解析。

而除了主線程，還有4個(gè)子線程，分別為：

1. 神策上報(bào)線程，占比15%

2. 微信，占比10%

3. 環(huán)信5%

4. SDWebimage清理緩存線程，5%。

我們?cè)偕钊胍徊剑?/p>

Image

其中波峰90%的消耗中，主線程占比28.5%。

1. 神策上報(bào)線程，28.5%

2. 微信28.5%

3. SDWebimage清理緩存線程14.2%

在上述中可以得到結(jié)論，在APP退到后臺(tái)時(shí)，CPU產(chǎn)生兩次波動(dòng)。

1. JPush進(jìn)行緩存寫(xiě)入。開(kāi)辟新的Runloop

2. 神策進(jìn)行上報(bào)。使用后臺(tái)backgroundTask，并進(jìn)行了子線程處理

3. SDWebimage清理緩存。使用后臺(tái)backgroundTask，并進(jìn)行了子線程處理

4. 微信和環(huán)信做了些不知名的操作

我們反過(guò)來(lái)再進(jìn)行操作，在不對(duì)神策，JPush進(jìn)行初始化時(shí)的CPU變化：

Image

可以看出，CPU使用率略微平穩(wěn)了一些，并且主線程占比也減少到了34%，其中第二段，可以看出，這次是TD上報(bào)，同樣是使用了backgroundTask，并且還是在主線程使用。

接下來(lái)，我們繼續(xù)屏蔽TD

Image

可以看出來(lái)，主線程只剩下SDWebimage，而且CPU使用率平穩(wěn)了很多。

海外工程表現(xiàn)類似，我們來(lái)看一下具體的：

Image

從分析中可以看出，CPU峰值為100%，并且分布細(xì)密。

從具體堆棧中可以看出，相比于H2，H2O的情況更加惡劣一些。

首先，除了退到后臺(tái)一瞬間CPU使用增高之外，在正常的使用過(guò)程中，CPU也一直由FacebookSDK，SDAutoLayout，GAD等占據(jù)著。

其中，如下圖，F(xiàn)acebook不斷的在hook并收集網(wǎng)絡(luò)信息

Image

SDAutoLayout在跑著，重新布局View。

GAD也在不斷的在內(nèi)存中寫(xiě)入數(shù)據(jù)，具體寫(xiě)的什么不得而知。

而這些問(wèn)題，都是因?yàn)槲覀冄h(huán)輪播的Banner，所以最近一步棋，優(yōu)先使輪播Banner在頁(yè)面離開(kāi)，App退到后臺(tái)等場(chǎng)景停止工作，解決平時(shí)CPU持續(xù)占用問(wèn)題。

而在退到后臺(tái)一瞬間：

1. Facebook在進(jìn)行資源回收

2. SDAutoLayout在重新布局View

3. 神策在上報(bào)數(shù)據(jù)

4. SDWebimage在清理舊圖片

5. JPush在進(jìn)行文件IO

6. ADJust也在進(jìn)行IO操作

其中Facebook,ADJush,JPush在退到后臺(tái)一瞬間，是CPU使用率達(dá)到了70%。不到1s后，神策和SDAutoLayout使CPU使用率達(dá)到了100%。

從以上可以看出，我們?cè)偻说胶笈_(tái)時(shí)，由于自身代碼邊界條件不清楚，三方SDK濫用，導(dǎo)致了CPU使用率集中過(guò)高。需要好好治理。