Android系统（110）---稳定性问题总结
稳定性问题总结
稳定性问题⽐较杂，且很多是概率性问题，没有统⼀处理⽅式，需要针对具体的问题，具体分析，
必现的问题较易解决，针对当前代码添加各种调试log，⼀步步debug去定位，过程虽然可能慢点，但⼀般都会解决。
但针对偶发性的概率问题，则较为⿇烦，依赖于⼤量的测试复现，然后统计 分析当前抓取到的 events、system 等log中，找到复现的步骤，然后去定位。
颧骨高的人
且针对与这种概率问题，最好能够拿到当时的现场，所以有时候需要将 tombstone 或者anr、crash 转为anr 去处理。
稳定性问题分类
ANR
Watchdog
Crash、界⾯、流程异常
Tombstone
Panic
ANR
系统中发⽣的ANR ⼤概分为三类：
以上三类ANR产⽣的原因可能是各种各样的，但常见的原因可以分为：
1. 程序⾃⾝主线程有问题引起的anr，此类问题往往可以直接通过 ANR的 backtrace 定位，此类异常常见的为：
吊车租赁合同1.
a、主进程进⾏IO⽂件操作
b、主进程进⾏⼤量频繁的数据库操作
c、主进程进⼊死循环简爱第一章概括
d、主进程进⾏联⽹操作(应该已经限制不允许了)
但也有⼀些诡异的⽆法通过堆栈定位的异常，需要针对具体情况，具体分析。例如：
证卷类的 ⼤富翁apk，更新时在某些低端机上会产⽣anr，主线程会卡在
at android.os.MessageQueue.nativePollOnce(Native Method)
1
这个⽅法是表⽰主线程处于空闲状态，主线程 handler 等待消息过来处理，那应该不会发⽣问题啊？
之后多次怀疑，多次定位，才定位出来原因是：
⼤富翁在更新时, 会在主线程⾥⾯有⼀个显⽰更新的进度条，每下载⼀个字节会使⽤handler 通知主进程 更新⼀下进度条，会毫秒级的 发送handler 消息。
在低端机上，性能较差，主进程的 handler 消息处理不过来，正常事件没有机会的到处理因⽽产⽣anr
⾼端机旗舰机，性能好，不会产⽣此问题。
2. 调⽤到对端，对端异常造成的ANR，此类常见的为 通过am、pm等相关manager 调⽤到了 system_rver 进程内的 rvice 实
2.
现，system_rver 因为某些异常没有及时返回，导致主进程black 产⽣的ANR， 究其根本是system_rver 异常引起的问题，常见原因为：
a、system_rver 对应的rvice 正在等待某个锁，没有及时处理请求。
b、system_rver 正在频繁的进⾏io操作(例如:system_rver 正在抓取bugreport)
所以定位处理此类的问题的关键为：
问题产⽣时 dump 到的堆栈必须齐全
3. iowait 过⾼，此类异常是后台有进程在进⾏⼤量io磁盘操作，导致cpu空转，严重影响系统性能，使发⽣ANR的主线程不能够获得
3.
cpu执⾏，因⽽产⽣的anr，例如：
迅雷app 后台以1~2M/s的速度下载数据，会造成整体较为卡钝，会有很⼤⼏率产⽣anr
这种异常从backtrace并不能看出异常，但问题发⽣的时间，往往伴随着⼤量anr， 此类问题，找出⼤量进⾏io操作的 进程即可，往往不需要具体定位。
ps：iowait 达到20% 就已经算⾮常⾼了
4.
4. cpu占⽤率过⾼，查看backtrace 中cpu的信息，看那个进程占⽤cpu较⾼，具体分析占⽤cpu较⾼的
罗彩霞案进程是否正常。
5. 内存过低, ⼿机在内存过低的情况下，系统会不断的LowMemeoryKiller优先级低进程，进⾏整体GC释放内存，对性能影响较⼤，
5.
也是⽆法直接从backtrace 中看出有效信息的，需要解决当时情况，去分析是否属于正常。
6.
6. 还有⼀种是 很⿇烦的情况，进程卡钝产⽣了ANR， 但在抓取堆栈的时候，进程恢复过来了，因此 ⽆法从堆栈中看出有效信息，且
也是概率性的产⽣ANR，这类情况，如果发⽣概率较⾼，需要综合分析log，没有很好的处理⽅式。
Watchdog
watchdog 每过30s 检测⼀次， 如果 要监控的线程30s 后没有相应，系统会dump出此进程堆栈，如果超过60s 没有相应，会触发watchdog，并重启系统。
系统原⽣的watchdog 分为两种 monitorCheck 与handlerChecker 这两种类型， 在MTK平台上结合现有的流程，添加了⼀种⽤于检测watchdog线程的机制：hang_detect, 所以说watchdog的检测类型有三种：
AccountManagerService
BatteryStatsService
DreamManagerService
MountService
寂寞才说爱歌词NetworkManagementService
PackageManagerService
usb相关（debug, device, portmanager）
WindowManagerService(screenshotApplicationsInner)
b、 android.bg 主要处理的事物为：
mBgHandler.handleMessage()的两个消息：CHECK_INTERNET_PERMISSION_MSG、COLLECT_PSS_BG_MSG
c、 main thread 主要处理的事物为：
system_rver 的主线程
d、 ui thread 主要处理的事物为：
AMS UiHandler⾥show各种msg字母的音标
DisplayManagerService⾥的overlay相关msg
PointerEventDispatcher inputevent相关
VoiceInteractionManagerService Voice交互
WindowManagerPolicy init操作
e、 i/o thread 主要处理的事物为：
BluetoothManagerService 相关操作
MountService⾥的obb操作
Tethering ⽹络共享（usb ／wifi／mobile？）
502胶水弄衣服上怎么去除TvInputManagerService tv⾥channel ssion相关
f、 display thread 主要处理的事物为：
DisplayManagerService（display adapter,viewport ,event…）
InputManagerService (keyboard , input device …)
WindowManagerService 实例的创建大蒜苗
ps：正常情况下只有foreground thread 线程，才会存在 monitorCheck。
2. monitorCheck检测
2.
monitorCheck主要⽤来检测系统常见的各个服务，在android系统⾥⾯，monitorCheck 是基于foreground thread 的handlerChecker的，⽽monitorCheck检测的动作是由要检查的服务⾃⼰继承Monitor接⼝ 去实现，⽬前各个rvice的实现是去检测各⾃对应的锁。
3. hang_detect检测
3.
hang_detect 是 mtk 设计的⽤来检测 watchdog ⾃⾝是否正常的⼀套机制，它的实现⽅式为 在kernel 中专门注册了⼀个设备( /dev/RT_Monitor )，⽤于和上层通信 监控 watchdog是否正常。
⼤概流程为：watchdog 向/dev/RT_Monitor 设置⼀个值，然后hang_detect 驱动根据此值，计算出⼀个时间，在此时间内，watchdog，必须再次通知⼀下hang_detect， 来表⽰并未超时，如果超时也去会dump 相关堆栈，重启⼿机。
正常情况下 watchdog 的解决办法，就是从watchdog ⽂件定位查找死锁原因，但也有⼀些复杂的情况，例如：
1、 死锁：watchdog 中最简单的情况，直接根据watchdog ⼀步步查找出来死锁即可
1、
2、 native层 与java 层互掉造成的死锁， 这种情况⽐较少见，但也遇到过，例如：
2、
乐视的三指截屏功能，java 层在system_rver ⾥⾯，申请锁后 会调⽤到底层去实现 三指截屏的功能，⽽在底层，也会去申请⼀个native的⽅法锁，去进⾏三指截屏，截屏操作完，会回调java 层 发送⼴播，截屏完毕，⽽发送⼴播依赖java 锁， 然后native的锁就与 java 层的锁，死锁了。
因为native的锁，并不会在 backtrace 体现，所以碰到这种情况的死锁，要堆栈结合代码，⼀步步定位，
3、 system_rver的16 个 binder 全部堵塞，这种情况也⽐较少见，⼀般是因为system_rver的某些异常引起的，我也是只遇
3、
到⼀次：
这个bug也是在乐视碰到的，某段时间，⼀些⼿机概率报出 同⼀类的watchdog，查看堆栈是：system_rver 的16 个binder 线程全部处于等待状态，从堆栈看不出特异的情况，
结合 发⽣问题时的log， 才确定问题：
进程Crash， 会出来⼀个 fc 弹窗，此弹窗是交互式的，会堵塞binder，等⽤户相应后，会释放binder， ⽽问题就发⽣在
这⾥，⼀个进程如果同⼀时间发⽣两次 异常，那么android 会直接kill 此进程，并将 弹窗dismiss 了， ⽽乐视 覆写了 弹
窗的dismiss ⽅法，没有在弹窗dismiss 时释放binder， 因⽽就造成⼀个binder堵塞， 多发⽣⼏次，system_rver 的
16 个binder 就全部堵塞了。
ps：我写的有关watchdog 的博客，多多光顾，多多光顾
Crash、界⾯、流程异常
crash 类型的问题，是⾮常常见的，问题原因也⽐较杂，但每⼈应该都有⾃⼰的定位⽅式，在此就介绍⼀些定位的⼯具与⼩⽅法：
protected static final void commonInit() {
......
Thread.tUncaughtExceptionPreHandler(new LoggingHandler());
Thread.tDefaultUncaughtExceptionHandler(new KillApplicationHandler()); ......
}
