Android系统最开始是为⼿机设计的，在机顶盒，电视，带屏⾳箱等⼤屏上运⾏后，芯⽚⼚家做些适配，产品⼚家也会做系统客制化，有时候还要适配第三⽅应⽤..等待
这种适配容易引⼈系统的稳定性问题，系统稳定性对于⽤户体验⾄关重要，很多问题也都⽐较类似，android系统对系统性能，稳定性分析⼯具也⽐较多，下⾯根据⼯作中遇到的问题做个总结。
问题现象分类
从表现来看有: 死机重启, ⾃动关机, ⽆法开机，冻屏,⿊屏以及闪退, ⽆响应等情况;
Android稳定性问题分类.png
问题技术分类
从技术层⾯来划分⽆外乎两⼤类: 长时间⽆法执⾏完成(Timeout) 以及异常崩溃(crash). 主要分类如下:
Android系统稳定性.png
ANR
ANR(Application Not responding)，是指普通app进程超过⼀定时间没有执⾏完，系统会弹出应⽤⽆响应对话框. 如果该进程运⾏在system进程, 更准确的来说，应该是(System Not Responding, SNR) ANR场景触发条件
Service Timeout(服务在指定的时间内未处理完要做的事情)对于前台服务，超时为SERVICE_TMEOUT=20s，后台服务，超时为SERVICE_BACKGROUND_TIMEOUT=10s
BroadcastQueue Timeout(⼴播接收处理超时，onReceive处理任务超时)对于前台⼴播，超时为BROADCAST_FG_TIMEOUT=10s, 后台⼴播，超时为BROADCAST_BG_TIMEOUT=60s
ContentProvider
Tiemout(AMS.attachApplicationLocked⾥⾯
启动超时)
杯芳烃
CONTENT_PROVIDER_PUBLISH_TIMEOUT=10s
InputDispatching Timeout(输⼊事件响应超时
5秒)
KEY_DISPATCHING_TIMEOUT=5s
ANR产⽣的原因可能是各种各样的，但常见的原因可以分为：
原因举例
程序⾃⾝主线程有问题引起ANR主线程进⾏IO⽂件操作，误写了死循环操作
调⽤到其他服务接⼝堵塞导致应⽤主进程堵塞这种情况⼀般是客制化服务挂死⽐较多
后台有进程在进⾏⼤量的io操作，iowait过⾼后台下载版本或者媒体中⼼扫描硬件
cpu占⽤过⾼/
debug⼿段
1.logcat⽇志
从logcat⾥可以看到死锁的打印
从可以看到线程的函数调⽤栈
AN R实例
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% kern
el / 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
发⽣ANR的时间 00:50:10 ，可以从这个时间点之前的⽇志中，还原ANR出现时系统的运⾏状态
发⽣ANR的进程 com.android.system.ui
发⽣ANR的原因 Reason关键字表明了ANR的原因是处理TIME_TICK⼴播消息超时
CPU负载 Load关键字表明了最近1分钟、5分钟、15分钟内的CPU负载分别是30.4、22.3、19.94.CPU最近1分钟的负载最具参考价值，因为ANR的超时限制基本都是1分钟以内， 这可以近似的理解为CPU最近1分钟平均有30.4个任务要处理，这个负载值是⽐较⾼的
CPU使⽤统计时间段 CPU usage from XX to XX ago关键字表明了这是在ANR发⽣之前⼀段时间内的CPU统计，类似的还有CPU usage from XX to XX after关键字，表明是ANR发⽣之后⼀段时间内的CPU统计
各进程的CPU使⽤率
以com.android.systemui进程的CPU使⽤率为例，它包含以下信息：
总的CPU使⽤率: 3.3%，其中systemui进程在⽤户态的CPU使⽤率是2.6%，在内核态的使⽤率是0.7%
缺页次数fault：8402 minor表⽰⾼速缓存中的缺页次数，343 major表⽰内存的缺页次数。minor可以理解为进程在做内存访问，major可以理解为进程在做IO操作。 当前minor和major值都是⽐较⾼的，从侧⾯反映了发⽣ANR之前，systemui进程有有较多的内存访问操作，引发的IO次数也会较多气瓶水压试验
CPU使⽤汇总 TOTAL关键字表明了CPU使⽤的汇总，87%是总的CPU使⽤率，其中有⼀项iowait表明CPU在等待IO的时间，占到64%，说明发⽣ANR以前，有⼤量的IO操作。app_process、 system_server, com.android.systemui这⼏个进程的major值都⽐较⼤，说明这些进程的IO 操作较为频繁，从⽽拉升了整个iowait的时间
< 如下
----- 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=
diatek.anrappmanager.MessageLogger.println(SourceFile:77)
waiting to lock <0x26b337a3> (diatek.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.Pid(Process.java:754)
diatek.anrappmanager.MessageLogger.dump(SourceFile:219)
locked <0x26b337a3> (diatek.anrappmanager.MessageLogger)
diatek.anrappmanager.ANRAppManager.dumpMessageHistory(SourceFile:65)
分析 : systemui主线程⼀直在等待49号线程的0x26b337a3锁, anrappmanager是MTK在AOSP上的扩展，⽤ 于打印ANR⽇志，设计存在缺陷
Wa tc hdo g实例
Android系统中，有硬件WatchDog⽤于定时检测关键硬件是否正常⼯作，类似地，在framework层有⼀个软件WatchDog⽤于定期检测关键系统服务是否发⽣死锁事件。 watchdog 每过30s 检测⼀次， 如果要监控的线程30s 后没有响应，系统会dump出此进程堆栈，如果超过60s 没有相应，会触发watchdog，并重启系统
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.itor(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.Watchdog
DeliveryTracker.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锁,⽆法进⼀步分析，需要看
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)
继续分析:
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处未返回
然后转给rtk负责显⽰的同事的⼈，确认是申请memory的时候卡死的
应⽤闪退
当出现应⽤闪退，可以从两个⽅⾯查看：
1、是否应⽤崩溃：
可以通过logcat –s AndroidRuntime DEBUG过滤⽇志，查看应⽤奔溃的具体堆栈信息。
其中AndroidRuntime的TAG打印java层信息，DEBUG的TAG打印native层的信息。
2、是否被lowmemorykiller杀掉：
可以通过 logcat –s lowmemorykiller 过滤⽇志，注意adj 0是代表前台进程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: le.android.tvlauncher' (2520), uid 10007, adj 0
发⽣这种情况，需要dumpsys meminfo 查看当前内存状态，是否有进程内存泄漏，导致系统内存不够，出现前台进程被杀，造成闪退。
闪屏
测试过程中，经常遇到屏幕闪烁的现象，需要排除是OSD层闪烁，还是video层闪烁。
1、先通过android原⽣⽅法：screencap截图, screenrecord 录制视频，这⾥都是截取的OSD层，查看是否有闪屏现象。
2、OSD没有问题，就需要从更底层的显⽰模块分析，⼀般需要芯⽚⼚家提供debug⼿段，不同芯⽚⼚家⽅案不⼀样。
3, 有时候输出不稳定，hdmi/mipi信号⼲扰，输出频率异常等也会导致闪屏，这种情况需要硬件协助分析。
如果OSD层也闪烁，则需从系统和应⽤层⾯分析。如曾遇到在开机向导界⾯，有个应⽤不断被唤起，导致⾛开机向导时出现连续闪灰屏的现象。⿊屏
⿊屏分UI⿊屏，视频播放⿊屏但UI正常等，2种场景
U I⿊屏洗肾机
1、screencap截屏，排查OSD层图形是否正常，
2、如果OSD图形正常，需要排查显⽰输出模块是否异常。
3、电视机⾥⾯屏显是单独控制，如果屏参配置错误会导致整改⿊屏。
OSD异常，需要排查顶层activity是否⿊屏，window是否有异常等.
视频⿊屏
1，排查视频图层或者window是否创建成功。
2，排查解码是否有异常，不同的应⽤youtube,netflix,iptv解码⽅式不⼀样，需要具体问题具体分析。
系统重启
system_servic e重启
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议