[摘]Android稳定性（一）SWT和ANR

前言

查找SWT啥意思时找到这篇文章，加上项目中用的也是MTK平台，因此摘抄这篇文章于此，方便自己学习和查阅。

本文摘抄，感谢作者分析。

好记性不如烂笔头

正文

SWT

这里解释了什么是SWT以及SWT的作用。

什么是SWT

SWT：software watchdog，监控SystemServer进程，保证核心服务和核心进程卡住后可以复位。

注意：SWT启动是在SystemServer init 的后期,如果SystemServer在init的过程中卡死了，意味着watchdog不会起作用。

watchdog原理

Android的Watchdog是一个单例线程，在SystemServer启动的startOtherServices()中就会init &start 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的完成状态：① COMPLETED表示已经完成；② WAITING和WAITED_HALF表示还在等待，但未超时；③ OVERDUE表示已经超时。默认情况下，timeout是1分钟，但监测对象可以通过传参自行设定，譬如PKMS的Handler Checker的超时是10分钟
4. 如果超时时间到了，还有HandlerChecker处于未完成的状态(OVERDUE)，则通过getBlockedCheckersLocked()方法，获取阻塞的HandlerChecker，生成一些描述信息；
5. 保存日志，包括一些运行时的堆栈信息，这些日志是我们解决Watchdog问题的重要依据。如果判断需要杀掉system_server进程，则给当前进程(system_server)发送signal 9；

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、引起ANR的原因、ANR的类型以及分析流程。（这里相对简陋了）

什么是ANR

ANR：Application Not Responding

引起ANR的原因

只有当应用程序的UI线程响应超时才会引起ANR，超时原因有两种：

1. 当前的事件没有得到处理
2. 当前的事件处理耗时过长

ANR主要有三种类型

括号内表示需要的时间内处理完，要不然就存在ANR

1. KeyDispatchTimeout（5s）
2. BroadcastTimeOut（10s）
3. 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

参考文章

1. 《Android稳定性（一）SWT/ANR》