?最近負(fù)責(zé)的項(xiàng)目中，有一定制客戶頻繁的抱怨設(shè)備在安裝一些客戶的app組件后，云端采集到的CPU占用率信息一直維持在78%以上，甚至還會(huì)出現(xiàn)90%的情況，與此同時(shí)，用戶也反映了卡頓、耗電快等現(xiàn)象。
?為了解決客戶這個(gè)痛點(diǎn)問題，拿了一臺(tái)復(fù)現(xiàn)設(shè)備來分析此CPU高的問題，以下是分析思路和過程，mark一下。

• 問題現(xiàn)象

?設(shè)備在刷入原生軟件版本時(shí)，后臺(tái)收集到的CPU占用信息大約在27%，正?，F(xiàn)象。
?而在客戶定制版本上，CPU至少在78%，對比兩個(gè)版本區(qū)別,發(fā)現(xiàn)定制客戶在原生軟件版本上多安裝了6個(gè)APP組件，此類app屬于客戶自研app,重啟機(jī)器靜置5分鐘后,觀察CPU信息,占用率沒有降低,對這么高cpu占用率嚇到了。

• CPU問題分析過程

1. 抓Log分析

?在客戶上報(bào)問題后,不管反饋的問題是什么(重啟\crash\卡頓等),一旦設(shè)備有問題出現(xiàn),對于研發(fā)人員來說,在了解到問題現(xiàn)象后,接下來就是需要一份Log,不能無的放矢。

選區(qū)_076.png

?上圖Log信息,發(fā)現(xiàn)后臺(tái)一直在重復(fù)打印如上信息,第一直覺告訴我,會(huì)不會(huì)截圖中l(wèi)og頻繁輸出導(dǎo)致cpu居高不下的。
?于是乎,根據(jù)這個(gè)懷疑點(diǎn),首先將以上日志信息注釋掉,不讓其打印出來,然后對比一下cpu前后使用情況,事實(shí)證明我的直覺一向不準(zhǔn),cpu使用率沒有什么改善。

2. Android Profiler工具,實(shí)時(shí)說明CPU使用情況

?Android Profiler這個(gè)工具就不多說了，簡而言之，就是Android Studio自帶的分析性能(包括cpu/memory/network)工具。
?將現(xiàn)場設(shè)備連上USB后，用Android Profiler工具查看CPU使用情況，發(fā)現(xiàn)system_process進(jìn)程的cpu一直維持在80%左右，如下圖：

system_cpu.png

?利用工具對system_server進(jìn)程單獨(dú)采樣一段時(shí)間，具體看看這段時(shí)間內(nèi)system_server進(jìn)程在進(jìn)行什么樣的操作，采樣信息如圖所示:

binder_1.png

binder_2.png

?兩張圖結(jié)合起來可以看出,system進(jìn)程中,十幾個(gè)binder線程都在輪詢工作,即占用cpu,而正是這些線程不斷執(zhí)行任務(wù),才導(dǎo)致system整個(gè)進(jìn)程cpu占用高,那么這些binder線程具體在進(jìn)行什么操作呢,還需要看單個(gè)線程的堆棧信息,如圖所示（這里只貼出其中一個(gè)線程的堆棧，因?yàn)槠渌€程都是類似的堆棧信息）:

binder_trace.png

?根據(jù)堆棧調(diào)用信息，system進(jìn)程在不斷地dump meminfo信息，多個(gè)binder線程不斷被請求dump meminfo信息，這才引起了cpu一直占用高。
?竟然binder線程被請求dump meminfo信息,那么客戶端是哪些進(jìn)程呢,在IPC中,服務(wù)端被調(diào)用,肯定是有個(gè)對端--客戶進(jìn)程發(fā)起請求的。
?所以還需要排查是哪個(gè)客戶進(jìn)程頻繁發(fā)起服務(wù)請求的，查看system進(jìn)程的binder調(diào)用情況，如下圖所示：

client&&server_pid.png

?根據(jù)system進(jìn)程的binder請求信息，可以看到是進(jìn)程號為4886、5207、5006這幾個(gè)客戶端進(jìn)程不斷在請求獲取么meminfo內(nèi)存信息的，而這幾個(gè)進(jìn)程號對應(yīng)的包名為:

client_pid.png

?這幾個(gè)應(yīng)用，正是客戶在設(shè)備上安裝的app，所以基本確認(rèn)是客戶app代碼不斷請求獲取meminfo內(nèi)存信息導(dǎo)致的，需要優(yōu)化客戶app的代碼邏輯，不要不停的獲取內(nèi)存信息，這樣頻繁請求meminfo信息，導(dǎo)致cpu負(fù)載很高，一直居高不下。

• 問題確認(rèn)

?為了再次確認(rèn)上述分析的原因，修改接口getMemoryInfo的邏輯，使其直接return返回，不再真正地執(zhí)行dump meminfo內(nèi)存信息，重啟機(jī)器后，cpu占用直接降到40%，正如所料。

• 問題總結(jié)

?有果比有因，需要具體分析到cpu占用高具體是在執(zhí)行什么操作，打印出問題進(jìn)程的堆棧信息,才能從代碼端解決問題,找到root cause。

以上純屬個(gè)人分析這個(gè)問題的記載?。。?/h1>