[摘]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对象的锁,以此检测线程是否发生死锁或阻塞。

  1. 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()方法;
  1. 调度完HandlerChecker之后,便开始定期检查是否超时,每一次检查的间隔时间由CHECK_INTERVAL常量设定,为30秒;
  2. 每一次检查都会调用evaluateCheckerCompletionLocked()方法来评估一下HandlerChecker的完成状态:① COMPLETED表示已经完成;② WAITING和WAITED_HALF表示还在等待,但未超时;③ OVERDUE表示已经超时。默认情况下,timeout是1分钟,但监测对象可以通过传参自行设定,譬如PKMS的Handler Checker的超时是10分钟
  3. 如果超时时间到了,还有HandlerChecker处于未完成的状态(OVERDUE),则通过getBlockedCheckersLocked()方法,获取阻塞的HandlerChecker,生成一些描述信息;
  4. 保存日志,包括一些运行时的堆栈信息,这些日志是我们解决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

[摘]Android稳定性(一)SWT和ANR

  1. Broadcast/Service ANR大都是APP Related Issue

参考文章

  1. Android稳定性(一)SWT/ANR
广告也精彩
版权声明:125la.com站长 发表于 2021年7月5日 下午7:54 。
转载请注明: [摘]Android稳定性(一)SWT和ANR | 125啦读书导航

相关文章

广告也精彩

暂无评论

暂无评论...
广告也精彩