文章目录
- 一、为什么需要SWT
- 二、常见问题类型
- 三、常见SWT/ANR原因有如下几种
- 1.等锁
- 2. SurfaceFlinger卡住
- 3.Native方法执行时间过长
- 4. Binder Server卡住
- 5. Zygote fork进程时卡住
- 6. Dump时间过长
一、为什么需要SWT
System Server进程是Android的一个核心进程，里面为APP运行提供了核心的服务。如果System Server的一些核心服务和重要线程卡住，就会导致相应的功能异常。
如手机发生hang机，输入无响应，无法启动APP等一些不正常的情况。而且，如果没有一种机制，让这些服务复位的话，那么将严重影响客户体验。尤其是当前大多数手机把电池封装在手机里面的这种，想拨电池重启都很难。
所以有必要在核心服务和核心线程卡住的时候，让系统有自动复位的机会。于是，google引入了Sytem Server watchdog机制。这个机制来监控核心服务和核心线程是否卡住。
二、常见问题类型
根据问题的历史数据，整理了SWT/ANR常见的问题类型。
SWT主要分Blocked和非Blocked类型，这两大类又进行了模块层面的细化，并从trace和现象上给予一定的问题描述。
ANR主要分性能和非性能类型。
三、常见SWT/ANR原因有如下几种
1.等锁
线程状态为“Blocked”，通过关键字“held by”进一步确认哪个线程拿住了锁，如有死锁检查code逻辑进行解锁；
线程状态为“Waiting”，表示当前线程需要另外一个线程来notify()，需要根据callstack结合code来做分析，以找到是另外的某个线程拿住了锁。
如果很多线程在等同一把锁，可能产生资源竞争问题，导致某些线程可能拿不到锁。
2. SurfaceFlinger卡住
SF hang Time > 40s（Service.sf.status值），sf hang，
直接在”SYS_ANDROID_LOG”搜索”I watchdog”，看是否有“surfaceflinger hang”关键字。
如果有，请进一步确认main_log里有"SF-WD"相关log打印， 或者与SWT相关的thread block在android.view.SurfaceControl.XXXX，更进一步分析请参考如下链接内容：
Quick Start > SurfaceFlinger Hang issue Guide
3.Native方法执行时间过长
线程状态为”Native”，根据native方法找到对应模块的owner，进一步确认该native方法为何执行时间过长，例如是否等待硬件返回或者硬件本身存在问题等。
4. Binder Server卡住
线程状态为“Native”，且含有如下callstack：
IPCThreadState::waitForResponse–>IPCThreadState::talkWithDriver，
表示卡在binder对端，下一步要找到对端，找到对端后，从对端thread的callstack中确认卡住的接口，并请对端相关的owner帮忙解决。
怎么寻找binder对端信息？
a. 根据binder thread的sysTid在SYS_BINDER_INFO/SWT_JBT_TRACES/
kernel_log中查找binder通信对端，关键字“outgoing transaction”
b.在SYS_PROCESSES_AND_THREADS通过对端的sysTid查找process name
c. 如果对端是Monkey，比较特别，可以不用关注，除非是严重影响Monkey Test。
d. 上述方法找不到binder对端，请参考“[FAQ22212] 如何根据binder client端查找binder server端？”
e. 如果按照上述方法依然找不到对端，只能按照code逻辑关系请相关module owner帮忙排查。
SystemServer binder used up问题：
Backtrace卡在：
at android.os.Binder.blockUntilThreadAvailable(Native method)
at com.android.server.Watchdog$BinderThreadMonitor.monitor(Watchdog.java:271)
请参考“[FAQ21386] 怎么初步定位binder used up导致的SWT问题？”
5. Zygote fork进程时卡住
线程状态为”Native”，确认callstack中有”Process.zygoteSendArgsAndGetResult”，
对于Zygote fork进程时卡住的问题，一般是由于底层memory问题引起的，请检查是否有memory不足或者memory leak的问题
6. Dump时间过长
前面有ANR发生：
a. 前面有ANR发生，”ActivityManager” 线程正在做dump操作，通过如 下 callstack确认：
appNotResponding, dumpStackTraces
b. 从“SYS_ANDROID_LOG”中确认是dump哪一个进程花的时间过长
c. 搜索关键字”dumpStackTraces process”来确认ANR发生时所dump的进程
d. 通过dump的上一个进程与下一个进程来确认时间差是否大于60s，或者所有的 dump时间加起来远远超过60s
e. ANR所引起的dump时间过长，需要看是否某个进程dump时间过长，并确认其 原因
前面有fatal JE、NE、KE等Exception发生；
自动化测试脚本主动call “dumpsys”去dump系统信息：
a. 通过callstack中确认是其他进程通过binder call发起AMS进行dump
b. 自动化测试脚本一般是进程“adb” call进来的，该类SWT一般也不用关注，只会在eng/userdebug版本下，或者开启mtklog后才会发生
注意：这种dump所导致的SWT，一般来说是系统loading过重，或者需要dump的信息确实过多所引起。终端用户不会发生这类问题，建议不用过多关注。
