Android系統(tǒng)最開始是為手機設(shè)計的，在機頂盒，電視，帶屏音箱等大屏上運行后，芯片廠家做些適配，產(chǎn)品廠家也會做系統(tǒng)客制化，有時候還要適配第三方應(yīng)用..等待
這種適配容易引人系統(tǒng)的穩(wěn)定性問題，系統(tǒng)穩(wěn)定性對于用戶體驗至關(guān)重要，很多問題也都比較類似，android系統(tǒng)對系統(tǒng)性能，穩(wěn)定性分析工具也比較多，下面根據(jù)工作中遇到的問題做個總結(jié)。

問題現(xiàn)象分類

從表現(xiàn)來看有: 死機重啟, 自動關(guān)機, 無法開機,凍屏,黑屏以及閃退, 無響應(yīng)等情況;

Android穩(wěn)定性問題分類.png

問題技術(shù)分類

從技術(shù)層面來劃分無外乎兩大類: 長時間無法執(zhí)行完成(Timeout) 以及異常崩潰(crash). 主要分類如下:

Android系統(tǒng)穩(wěn)定性.png

ANR

ANR(Application Not responding)，是指普通app進程超過一定時間沒有執(zhí)行完，系統(tǒng)會彈出應(yīng)用無響應(yīng)對話框. 如果
該進程運行在system進程, 更準確的來說,應(yīng)該是(System Not Responding, SNR)

ANR產(chǎn)生的原因可能是各種各樣的，但常見的原因可以分為：

debug手段

1.logcat日志
2.trace文件(保存在/data/anr/traces.txt)
從logcat里可以看到死鎖的打印
從traces.txt可以看到線程的函數(shù)調(diào)用棧

ANR實例

10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4 / 22.34 / 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time :[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to -4ms ago:
10-16 00:50:10 820 907 E ActivityManager: 47% 320/netd: 3.1% user + 44% kernel / faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager: 15% 10007/com.sohu.sohuvideo: 2.8% user + 12% kernel / faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager: 13% 10654/hif_thread: 0% user + 13% kernel
10-16 00:50:10 820 907 E ActivityManager: 11% 175/mmcqd/0: 0% user + 11% kernel
10-16 00:50:10 820 907 E ActivityManager: 5.1% 12165/app_process: 1.6% user + 3.5% kernel / faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager: 3.3% 29533/com.android.systemui: 2.6% user + 0.7% kernel / faults: 8402 minor 343 major
......
10-16 00:50:10 820 907 E ActivityManager: +0% 12832/cat: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: +0% 13211/zygote64: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user + 18% kernel + 64% iowait + 0.5% softirq

發(fā)生ANR的時間 00:50:10 ,可以從這個時間點之前的日志中，還原ANR出現(xiàn)時系統(tǒng)的運行狀態(tài)
發(fā)生ANR的進程 com.android.system.ui
發(fā)生ANR的原因 Reason關(guān)鍵字表明了ANR的原因是處理TIME_TICK廣播消息超時
CPU負載 Load關(guān)鍵字表明了最近1分鐘、5分鐘、15分鐘內(nèi)的CPU負載分別是30.4、22.3、19.94.CPU最近1分鐘的負載最具參考價值，因為ANR的超時限制基本都是1分鐘以內(nèi)， 這可以近似的理解為CPU最近1分鐘平均有30.4個任務(wù)要處理，這個負載值是比較高的
CPU使用統(tǒng)計時間段 CPU usage from XX to XX ago關(guān)鍵字表明了這是在ANR發(fā)生之前一段時間內(nèi)的CPU統(tǒng)計,類似的還有CPU usage from XX to XX after關(guān)鍵字，表明是ANR發(fā)生之后一段時間內(nèi)的CPU統(tǒng)計
各進程的CPU使用率
以com.android.systemui進程的CPU使用率為例，它包含以下信息：
總的CPU使用率: 3.3%，其中systemui進程在用戶態(tài)的CPU使用率是2.6%，在內(nèi)核態(tài)的使用率是0.7%
缺頁次數(shù)fault：8402 minor表示高速緩存中的缺頁次數(shù)，343 major表示內(nèi)存的缺頁次數(shù)。minor可以理解為進程在做內(nèi)存訪問，major可以理解為進程在做IO操作。 當前minor和major值都是比較高的，從側(cè)面反映了發(fā)生ANR之前，systemui進程有有較多的內(nèi)存訪問操作，引發(fā)的IO次數(shù)也會較多
CPU使用匯總 TOTAL關(guān)鍵字表明了CPU使用的匯總，87%是總的CPU使用率，其中有一項iowait表明CPU在等待IO的時間，占到64%，說明發(fā)生ANR以前，有大量的IO操作。app_process、 system_server, com.android.systemui這幾個進程的major值都比較大，說明這些進程的IO操作較為頻繁，從而拉升了整個iowait的時間

traces.txt 如下
----- pid 29533 at 2015-10-16 00:48:29 -----
Cmd line: com.android.systemui
DALVIK THREADS (54):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
| sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
| state=S schedstat=( 289080040422 93461978317 904874 ) utm=20599 stm=8309 core=0 HZ=100
| stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
| held mutexes=
at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)

• waiting to lock <0x26b337a3> (a com.mediatek.anrappmanager.MessageLogger) held by thread 49
  ......
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:770)
  ...
  "Binder_5" prio=5 tid=49 Native
  ......
  at android.os.Process.myPid(Process.java:754)
  at com.mediatek.anrappmanager.MessageLogger.dump(SourceFile:219)
• locked <0x26b337a3> (a com.mediatek.anrappmanager.MessageLogger)
  at com.mediatek.anrappmanager.ANRAppManager.dumpMessageHistory(SourceFile:65)
  分析 : systemui主線程一直在等待49號線程的0x26b337a3鎖, anrappmanager是MTK在AOSP上的擴展，用 于打印ANR日志,設(shè)計存在缺陷

Watchdog實例

Android系統(tǒng)中，有硬件WatchDog用于定時檢測關(guān)鍵硬件是否正常工作，類似地，在framework層有一個軟件WatchDog用于定期檢測關(guān)鍵系統(tǒng)服務(wù)是否發(fā)生死鎖事件。
watchdog 每過30s 檢測一次， 如果要監(jiān)控的線程30s 后沒有響應(yīng)，系統(tǒng)會dump出此進程堆棧，如果超過60s 沒有相應(yīng)，會觸發(fā)watchdog，并重啟系統(tǒng)
10:57:23.718 579 1308 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread (android.fg), Blocked in handler on main thread (main), Blocked in handler on ActivityManager (ActivityManager)
10:57:23.725 579 1308 W Watchdog: android.fg annotated stack trace:
10:57:23.726 579 1308 W Watchdog: at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:26271)
10:57:23.727 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.727 579 1308 W Watchdog: at com.android.server.WatchdogDeliveryTracker.alarmTimedOut(AlarmManagerService.java:4151)
10:57:23.733 579 1308 W Watchdog: - waiting to lock <0x00aaee38> (a java.lang.Object)
......
10:57:23.736 579 1308 W Watchdog: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
10:57:23.739 579 1308 W Watchdog: ActivityManager annotated stack trace:
10:57:23.740 579 1308 W Watchdog: at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:405)
10:57:23.740 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.740 579 1308 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:106)
10:57:23.741 579 1308 W Watchdog: *** GOODBYE!
分析：
提示 ActivityManagerService的android.fg,main,ActivityManager 線程Block了,但logcat里只能看到
android.fg等待0x0bb47e39 鎖,main 等待0x00aaee38鎖,ActivityManager等待0x0bb47e39鎖,無法進一步分析,需要看traces.txt
Cmd line: system_server
......
"main" prio=5 tid=1 Blocked

• waiting to lock <0x00aaee38> (a java.lang.Object) held by thread 48
  "WifiStateMachine" prio=5 tid=48 Blocked
• waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService) held by thread 86
  "Binder:579_C" prio=5 tid=86 Blocked
• waiting to lock <0x0f75d902> (a com.android.server.wm.WindowHashMap) held by thread 108
  ......
  "Binder:579_1D" prio=5 tid=108 Native
  native: #00 pc 00053d20 /system/lib/libc.so (__ioctl+8)
  ......
  native: #07 pc 000a3331 /system/lib/libandroid_runtime.so (android::nativeCreate(_JNIEnv, _jclass, _jobject, _jstring, int, int, int, int, long long, int, int)+120)
  at android.view.SurfaceControl.nativeCreate(Native method)
  ......
  at com.android.server.wm.WindowManagerService.addWindow(WindowManagerService.java:1248)
• locked <0x0f75d902> (a com.android.server.wm.WindowHashMap)
  at com.android.server.wm.Session.addToDisplay(Session.java:205)
  繼續(xù)分析:
  1.system_server的main線程(tid=1)等待(tid=48)線程持有的0x00aaee38鎖
  2.tid=48線程等待(tid=86)線程持有的0x0bb47e39鎖
  3.tid=86線程等待(tid=108)線程持有的0x0f75d902鎖
  4.tid=108線程等待(tid=108)線程卡在SurfaceControl.nativeCreate處未返回
  然后轉(zhuǎn)給rtk負責顯示的同事的人，確認是申請memory的時候卡死的

應(yīng)用閃退

當出現(xiàn)應(yīng)用閃退，可以從兩個方面查看：
1、是否應(yīng)用崩潰：
可以通過logcat –s AndroidRuntime DEBUG過濾日志，查看應(yīng)用奔潰的具體堆棧信息。
其中AndroidRuntime的TAG打印java層信息，DEBUG的TAG打印native層的信息。
2、是否被lowmemorykiller殺掉：
可以通過 logcat –s lowmemorykiller 過濾日志，注意adj 0是代表前臺進程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: Killing'com.google.android.tvlauncher' (2520), uid 10007, adj 0
發(fā)生這種情況，需要dumpsys meminfo 查看當前內(nèi)存狀態(tài)，是否有進程內(nèi)存泄漏，導致系統(tǒng)內(nèi)存不夠，出現(xiàn)前臺進程被殺，造成閃退。

閃屏

測試過程中，經(jīng)常遇到屏幕閃爍的現(xiàn)象，需要排除是OSD層閃爍，還是video層閃爍。
1、先通過android原生方法：screencap截圖, screenrecord 錄制視頻，這里都是截取的OSD層，查看是否有閃屏現(xiàn)象。
2、OSD沒有問題，就需要從更底層的顯示模塊分析，一般需要芯片廠家提供debug手段，不同芯片廠家方案不一樣。
3, 有時候輸出不穩(wěn)定，hdmi/mipi信號干擾，輸出頻率異常等也會導致閃屏，這種情況需要硬件協(xié)助分析。
如果OSD層也閃爍，則需從系統(tǒng)和應(yīng)用層面分析。如曾遇到在開機向?qū)Ы缑妫袀€應(yīng)用不斷被喚起，導致走開機向?qū)r出現(xiàn)連續(xù)閃灰屏的現(xiàn)象。

黑屏

黑屏分UI黑屏，視頻播放黑屏但UI正常等，2種場景

UI黑屏

1、screencap截屏，排查OSD層圖形是否正常，
2、如果OSD圖形正常，需要排查顯示輸出模塊是否異常。
3、電視機里面屏顯是單獨控制，如果屏參配置錯誤會導致整改黑屏。
OSD異常，需要排查頂層activity是否黑屏，window是否有異常等.

視頻黑屏

1，排查視頻圖層或者window是否創(chuàng)建成功。
2，排查解碼是否有異常，不同的應(yīng)用youtube,netflix,iptv解碼方式不一樣，需要具體問題具體分析。

系統(tǒng)重啟

system_service重啟

如下，ActivityManager因為空對象引用而掛掉，導致system_server重啟
*** [FATAL EXCEPTION IN SYSTEM PROCESS: ActivityHanager [
^ava.lang.NullPointerException: Attempt to invoke virtual method 'void co?.android.internal.os.KernelSingleUidTimeReader.iBarkDataAsStale(boolean)' on a null object reference
at com.android.internal.os.BatteryStatsIiaplSConstants.upddteTrackCpuTiinesByProcStdteLocked(BatteryStatslnpl.java:13355)
at com.android.internal.os.BatteryStatsInplSConstants.upddteConstants(BatteryStatsImpl.java:13330)
at com.android.internal-o-batteryStatslMpl$Constants-onChange(BatteryStatsInpl-java:13316)
at android.database.Contentobserver.onChange(ContentObserver.java:145)
解決方法：修復空指針

SurfaceFlinger掛掉（從開機動畫開始重啟）

DEBUG : pid: 296, tid: 1721, name: Binder：296_4 >>> /system/bin/surfaceflinger <<<
DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr ------
DEBUG : Abort message: 'status.cpp:149] Failed HIDL return status not checked: Status(EXTRANSACTIONFAILED):
DEBUG : r0 00000000 rl 000006b9
DEBUG ： C4 00000128 r5 000006b9
r2 00000006 r3 a5c5d620
r6 a235d60c r7 0000010c
DEAD_OB3ECT：
DEBUG : r8 00000019 r9 0000015d
DEBUG : ip a6ablbec sp a235d5f8
rlO a568f090 rll a620dce9
Ir a5be901d pc a5be0da2
/system/lib/libc.so (abort+62)
/system/lib/libbase.so (android::base::DefaultAborter(char const)+6)
backtrace:
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libbase.so (android::base::LogMessage::~LogMessage()+502)
/system/lib/libhidlbase.so (android::hardware::details::return_status::~return_status()+184)
(android::Hwc2::impl::Composer::getActiveConfig(unsigned long long, unsigned int)+56)
(HWC2::Display::getActiveConfig(std::_1::shared_ptr<HWC2：:Display::Config const>*) const+38)
(android::HWComposer::getActiveConfig(int) const+64)
(android::SurfaceFlinger::resyncToHardwareVsync(bool)+64)
可以根據(jù)backtrace來進行定位異常崩潰的地方。Android P上， backtrace使用Java上下文來顯示，省去使用addr2line來轉(zhuǎn)換的一個過程，方便調(diào)試分析問題。但是實際場景中，
有些native進程崩潰只有pc地址，而無函數(shù)信息，或者需要定位到具體的某個文件某個函數(shù)，則可借助堆棧分析工具addr2line。
addr2line：根據(jù)堆棧定位具體函數(shù)和文件
addr2line -e libsurfaceflinger.so -f 00071a09
addr2line -e libsurfaceflinger.so -f 00071a09
_ZN7android14SurfaceFlinger12waitForEventEv
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意兩點：
1、需用帶debug信息的LINK目錄里面的so庫，機頂盒上的so庫是無法定位的：
out/target/product/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/product/xx/symbols/system/lib/libsurfaceflinger.so
2、定位的文件，必現(xiàn)和機器上出現(xiàn)問題的版本一致，否則定位不準確
debuggerd：打印當前進程實時堆棧：debuggerd –b pid

kernel 重啟

主要可以分為以下3類
1)Data abort
Unable to handle kernel NULL pointer dereference at virtual address...
Unable to handle kernel paging request at virtual address...
Unhandled fault...at...
Unhandled prefetch abort...at...
2)BUG/BUG_ON
Oops - BUG...
例如：
Out of memory and no killable processes...
rbus timeout...
...
PS:WARN_ON只dump stacks，kernel還是正常
3)bad mode
Oops - bad mode...
日志打印:
〃錯誤類型原因
[214.962667] 08:14:19.315 (2)-0488 Unable to handle kernel paging request at virtual address 6b6b6cl7
[214.973889] 08:14:19.326 (2)-0488 addr：6b6b6c17 pgd = d0824000
[214.980132] [6b6b6c17J ?pgd=O000eO0e
〃Oopsttl誤碼序號
[214.983865] 08:14:19.336 (2)-0488 Internal error： Oops： 805 [#1] PREEMPT SMP ARM
[214.9914S3] Modules linked in: 8192eu ufsd(PO) jnl(O) fusion(O)
〃發(fā)生也錯誤的CPU序號
(215.001878] 08:14:19.354 (2)-0488 CPU： 2 PID: 488 Comm: system_server Tainted: P 4.4.3+ #113
(2)-0488 Hardware name: rtd284x
[215.011865] 08:14:19.364
〃當前PC指針 98:14:19.377 (2)-0488 PC is at mutex_unlo<k+0xc/0x38
(21S.024846] 08:14:19.383 (2)-0488 LR is at storage_pm_event+0xb4/0xe8
(21S.031026]
//Registers 08:14:19.390 (2)-0488 ：[<ceb78ffc>] Ir : [<C0542034>] psr: 200f0013
I 215.037644] sp : ccf79e38 ip : eceoeeee fp : 9b34648c
I 215.037644]
08:14:19.404 (2)-0488 rlO： 00000080 r9 ：Cl8b3864 r8 : oeeeeeoe
215.051370]
215.058692] 08:14:19.411 (2)-0488 P7 ： C1293a98 P6 ：C1293940 r5 : C1293940 r4 ：C1293a80
21S.067345]
[ 215.076014] 08:14:19.420 (2)-0488 r3 : 00000033 r2 ：00000000 ri : 000^000 re ：6b6b6c07
[ 215.085307]
08:14:19.428 (2)-0488 Flags: nzCv IRQs on FIQs on Mode SVC 32 ISA ARM Segment user
08:14:19.438 (2)-0488 Control: 10c5383d Table： 1082406a DAC： 00000055
//Process.不 ,定是該process的錯誤，只是發(fā)生錯誤時,剛好在運行該process
[215.093168]
//Stacks 08:14:19.446 (2)-0488 Process syste?i_server (pid: 488, stack limit = 0xccf78218)

(21S.101827] 08:14:19.454 (2)-0488 Stack: 0xccf79e38 (Oxccf79d7。 to 0xccf7a08Q) - par(0xcf796d4)

---[ end trace 45d55384id6a0974 ]--- Kernel panic not syncing: Fatal exception
[217.359794] 08:14:21.712 (0)-0488
解決方案: kernel異常一般找芯片原廠協(xié)助分析。

系統(tǒng)卡頓

系統(tǒng)卡頓時，一般先分三步走：
1、查看當前系統(tǒng)的CPU，IO等參數(shù)，輸入top、iotop命令： （如：iotop -s io -m 9）
如果有異常飆高的進程，kill掉后會發(fā)現(xiàn)系統(tǒng)恢復正常。
之前項目上遇到過某些U盤IO性能比較差，媒體中心又在后臺掃描媒體問題，導致系統(tǒng)各種卡頓，io wait時間比較長。
2、系統(tǒng)進程卡住，觸發(fā)Watchdog：ps –A |grep system_server,一般而言，system_server正常的進程號是200多，如果發(fā)現(xiàn)進程號變成幾千，則可能出現(xiàn)重啟，結(jié)合tombstone和 /data/anr下的trace文件分析重啟原因
3、當前應(yīng)用出現(xiàn)卡頓，造成ANR。輸入logcat | grep ANR，如果有ANR打印，再去/data/anr下面查看相應(yīng)進程的traces文件
有時在應(yīng)用里面操作卡頓，按鍵響應(yīng)延遲，但是卻沒有生成ANR，此時如果退出該應(yīng)用（如果無法退出，在抓取足夠信息的情況下，可以串口直接kill掉卡頓的應(yīng)用），則一切正常，可能是應(yīng)用自身實現(xiàn)問題，或者調(diào)用了其它接口導致（例如曾遇到應(yīng)用調(diào)用了中間件、mediaplayer某些接口導致操作嚴重卡頓，按鍵響應(yīng)延遲），這種情況則需應(yīng)用和相應(yīng)接口的實現(xiàn)者去排查。

系統(tǒng)卡死

系統(tǒng)完全卡死，一般分三種情況
1，串口無響應(yīng)，大概率kernel panic，
2，串口日志狂輸出，把系統(tǒng)堵塞， 優(yōu)化日志輸出，關(guān)注關(guān)閉后壓測。
3，Input系統(tǒng)完全堵塞，導致任何輸入都無響應(yīng)。