（1）原理性
（2）SWT如何抓取Log
遇到SWT问题详细可参考MTK提供的FAQ：SWT机制介绍。
获取Ap Log的路径：/sdcard/debuglogger/mobilelog/APLog_XXXXX
获取db的路径：/data/aee_exp
如果db没有打包完成，而trace文件已经生成，请adb pull data/anr/ 目录下的trace文件。
DB文件备注
Android user/userdebug版本因受Security限制，导致在M版本之后打开mtklogger也只能抓到fatal db，不能抓普通的ANR db，O版本开始默认不会抓取第三方APP的ANR db。
如需抓取（包括第三方app）ANR db，请参考如下FAQ进行修改：Android user/userdebug load，如何抓到所有异常的aee db？。
//Android P 后需修改
//vendor/mediatek/proprietary/external/aee/config_external/init.aee.customer.vendor.rc里添加
on init
setprop ro.vendor.aee.enforcing no（注意修改此属性后, 无法通过CTS 安全测试项, 在正式发布版本时, 需要恢复默认设置，把此行修改去掉）
setprop persist.vendor.aeev.core.dump enable
setprop persist.vendor.aeev.core.direct enable
setprop persist.vendor.mtk.aee.mode 3
setprop persist.vendor.mtk.aeev.mode 3
（3）解析DB文件
解析DB需要特定的工具：GAT 或者 QAAT
DB常用文件说明：
（4）确认trace有效性
先通过event_log确认SWT/ANR发生的时间点：
Keyword：
SWT —— “watchdog”
ANR —— “am_anr”
有效trace时间：
SWT —— （swt_time – swt_timeout – 10s）~ （swt_time + 10s），之间的两次trace
ANR —— （anr_time – anr_timeout – 10s）~ （anr_time + 10s）
（5）SWT Analysis Flow
当SWT的两次有效trace打印的call stack完全一样时，才认为是block issue，重点从call stack来入手分析，常规分析流程如上图。
如果两次trace打印的call stack不完全一样或者只有一次有效trace，很有可能是系统Performance比较差，需要check系统performance状况，请参考下面流程图先判断是CPU or Low Memory or IO Loading bound。
（6）ANR Analysis Flow
APP is Idle：检查CallStack，查看main thread的CallStack停在nativePollOnce (From SWT_JBT_TRACES)。
短时间内发生多次ANR，请先解掉第一个ANR，再确认后续ANR是否还能复现。
（7）Call Stack Analysis
（A）查找Backtrace
（a_1）SWT追踪
（a_2）ANR追踪
（B）线程状态
（b_1）Idle：main thread的message queue空闲
（b_2）Blocked：当前thread被其他thread block住
（b_3）Waiting / TimedWaiting：当前thread在等待其他thread notify
（b_4）Sleeping： 当前Thread主动调用sleep(ms)
