Android稳定性（一）SWT/ANR

一、SWT
SWT：software watchdog，监控SystemServer进程，保证核心服务和核心进程卡住后可以复位。
注意：SWT启动是在SystemServer init 的后期, 如果SystemServer在init的过程中卡死了，意味着watchdog不会起作用。

<1>watchdog原理：
Android的Watchdog是一个单例线程，在SystemServer启动的startOtherServices()中就会init &start Watchdog。

watchdog的添加方式：
Watchdog在初始化时，会构建很多HandlerChecker，大致可以分为两类：
1、Monitor Checker，用于检查是Monitor对象可能发生的死锁, AMS, PKMS, WMS等核心的系统服务都是通过addMonitor()加入Watchdog.mMonitorChecker.mMonitors列表中，该列表会不断调用Monitor.Monitor()函数。通过定期检测monitor对象的锁，以此检测线程是否发生死锁或阻塞。
2、Looper Checker，用于检查线程的消息队列是否长时间处于工作状态。Watchdog自身的消息队列，Ui, Io, Display这些全局的消息队列都是被检查的对象。此外，一些重要的线程的消息队列，也会加入到Looper Checker中，譬如AMS, PKMS，这些是在对应的对象初始化时加入的。
通过addThread()将对应主线程Handler保存到Watchdog.mHandlerCheckers列表中，同时还会把上面的mMonitorChecker也保存到Watchdog.mHandlerCheckers中，Watchdog会不断判断这些线程的Looper是否空闲，如果一直非空闲，那么必然被blocked住了。

watchdog的运作逻辑大概如下：
1、Watchdog运行后，便开始无限循环，依次调用每一个HandlerChecker的scheduleCheckLocked()方法；
2、调度完HandlerChecker之后，便开始定期检查是否超时，每一次检查的间隔时间由CHECK_INTERVAL常量设定，为30秒；
3、每一次检查都会调用evaluateCheckerCompletionLocked()方法来评估一下HandlerChecker的完成状态：
a、COMPLETED表示已经完成
b、WAITING和WAITED_HALF表示还在等待，但未超时
c、OVERDUE表示已经超时。默认情况下，timeout是1分钟，但监测对象可以通过传参自行设定，譬如PKMS的Handler Checker的超时是10分钟
4、如果超时时间到了，还有HandlerChecker处于未完成的状态(OVERDUE)，则通过getBlockedCheckersLocked()方法，获取阻塞的HandlerChecker，生成一些描述信息；
5、保存日志，包括一些运行时的堆栈信息，这些日志是我们解决Watchdog问题的重要依据。如果判断需要杀掉system_server进程，则给当前进程(system_server)发送signal 9；

<2>SWT问题分析流程：（以MTK平台为例）
1、获取APLog和db文件，使用GAT工具解析db文件；
2、首先确认log有效性，确认问题类型。在SYS_ANDROID_EVENT_LOG中check SWT发生的时间点及卡住的线程，在SWT_JBT_TRACES中找到system_server一分钟内的两次backtrace（当SWT的两次有效trace打印的call stack完全一样时，才认为是block issue；如果两次trace打印的call stack不完全一样或者只有一次有效trace，怀疑系统Performance比较差，需要check系统performance状况）；
3、线程阻塞问题，需要查看堆栈调用，按以下顺序排查：①thread之间是否形成一个环，是否互相持锁形成死锁；②是否binder对端被锁，如果是，需要找到binder对端线程，查看该线程阻塞情况；③是否Native Call有问题，找到对应的so文件；④是否dump时间过久导致。
4、怀疑系统性能差，check以下三方面CPU、Low Memory、IO

二、ANR
ANR：Application Not Responding
只有当应用程序的UI线程响应超时才会引起ANR，超时原因有两种：
1、当前的事件没有得到处理
2、当前的事件处理耗时过长

主要有三种类型：KeyDispatchTimeout（5s）、BroadcastTimeOut（10s）、ServiceTimeOut（20s）

ANR问题分析流程：
1、获取APLog和trace，可以查看trace堆栈调用，查看main thread情况；
2、以inputdispatch ANR为例，首先check inputdispatch type：①No Focus Window：检查activity onResume时间点，如果发生ANR时onResume还未完成，则为APP Related Issue；然后再检查relayout window时间，如果发生ANR时resume activity还未call relayout window，则为APP Related Issue，否则为WMS Issue。②Waiting Previous Event：APP是否idle，是的话是view issue，否的话是APP Related issue；
3、APP Related Issue check

4、Broadcast/Service ANR大都是APP Related Issue