最近負責的項目中，有一定制客戶頻繁的抱怨設備在安裝一些客戶的app組件后，云端采集到的CPU占用率信息一直維持在78%以上，甚至還會出現90%的情況，與此同時，用戶也反映了卡頓、耗電快等現象。

為了解決客戶這個痛點問題，拿了一臺復現設備來分析此CPU高的問題，以下是分析思路和過程，mark一下。

問題現象

設備在刷入原生軟件版本時，后臺收集到的CPU占用信息大約在27%，正常現象。

而在客戶定制版本上，CPU至少在78%，對比兩個版本區別,發現定制客戶在原生軟件版本上多安裝了6個APP組件，此類app屬于客戶自研app,重啟機器靜置5分鐘后,觀察CPU信息,占用率沒有降低,對這么高cpu占用率嚇到了。

CPU問題分析過程

1. 抓Log分析

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

選區_076.png

上圖Log信息,發現后臺一直在重復打印如上信息,第一直覺告訴我,會不會截圖中log頻繁輸出導致cpu居高不下的。

于是乎,根據這個懷疑點,首先將以上日志信息注釋掉,不讓其打印出來,然后對比一下cpu前后使用情況,事實證明我的直覺一向不準,cpu使用率沒有什么改善。

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

Android Profiler這個工具就不多說了，簡而言之，就是Android Studio自帶的分析性能(包括cpu/memory/network)工具。

將現場設備連上USB后，用Android Profiler工具查看CPU使用情況，發現system_process進程的cpu一直維持在80%左右，如下圖：

system_cpu.png

利用工具對system_server進程單獨采樣一段時間，具體看看這段時間內system_server進程在進行什么樣的操作，采樣信息如圖所示:

binder_1.png

binder_2.png

兩張圖結合起來可以看出,system進程中,十幾個binder線程都在輪詢工作,即占用cpu,而正是這些線程不斷執行任務,才導致system整個進程cpu占用高,那么這些binder線程具體在進行什么操作呢,還需要看單個線程的堆棧信息,如圖所示(這里只貼出其中一個線程的堆棧，因為其他線程都是類似的堆棧信息):

binder_trace.png

根據堆棧調用信息，system進程在不斷地dump meminfo信息，多個binder線程不斷被請求dump meminfo信息，這才引起了cpu一直占用高。

竟然binder線程被請求dump meminfo信息,那么客戶端是哪些進程呢,在IPC中,服務端被調用,肯定是有個對端--客戶進程發起請求的。

所以還需要排查是哪個客戶進程頻繁發起服務請求的，查看system進程的binder調用情況，如下圖所示：

client&&server_pid.png

根據system進程的binder請求信息，可以看到是進程號為4886、5207、5006這幾個客戶端進程不斷在請求獲取么meminfo內存信息的，而這幾個進程號對應的包名為:

client_pid.png

這幾個應用，正是客戶在設備上安裝的app，所以基本確認是客戶app代碼不斷請求獲取meminfo內存信息導致的，需要優化客戶app的代碼邏輯，不要不停的獲取內存信息，這樣頻繁請求meminfo信息，導致cpu負載很高，一直居高不下。

問題確認

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

現場

未屏蔽

已屏蔽

CPU占用

80%以上

45%

問題總結

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

以上純屬個人分析這個問題的記載！！！

總結

以上是生活随笔為你收集整理的安卓apkcpu占用过高_Android CPU占用高问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。