一、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