1APR问题分类
1.1错误(目前主要集中在这里)
1>ANR Application Not Responding 应用程序无响应的 crash 崩溃
2>tombstone 一般是由Dalvik错误、状态监视调试器、C层代码以及libc的一些问题导致的
1.2重启
1>watchdog可以把Watchdog比作系统级的ANR，应用级的ANR后果是应用不响应最后挂掉，Watchdog的后果是AP侧重启modemcrash modem侧崩溃
2>vmreboot 虚拟机重启
3常见log剔除
3.1CPU使用率过高
0% 124/kworker/u:2: 0% user + 0% kernel
0% 1148/com.baidu.input: 0% user + 0% kernel / faults: 73 minor
0% 1185/com.erdo.mm.cartoonplayer: 0% user + 0% kernel / faults: 318 minor
0% 1481/mpdecision: 0% user + 0% kernel / faults: 2 minor
0.1% 1495/ksoftirqd/1: 0% user + 0.1% kernel
0.1% 20312/com.huawei.hidisk: 0.1% user + 0% kernel / faults: 74 minor
93% TOTAL: 61% user + 21% kernel + 10% iowait
CPU超过70以上就很高了，可以直接剔除
3.2Iowait高
3.7% 325/surfaceflinger: 0.8% user + 2.8% kernel / faults: 3884 minor 20 major
3.7% 1075/com.android.systemui: 3.2% user + 0.5% kernel / faults: 399 minor
2% 121/mmcqd/0: 0% user + 2% kernel
1.1% 18138/com.huawei.mmitest: 0.6% user + 0.5% kernel / faults: 385 minor
57% TOTAL: 24% user + 11% kernel + 20% iowait + 0% softirq
Iowait一般超过10%就属于比较高的水平了，这种情况下通常是程序在做一些频繁的IO读写操作导致的比较常见的是数据库读写操作，定位问题要往这个方向分析。
3.3nativepollonce问题
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:125)
at android.os.Looper.loop(Looper.java:124)
at android.app.ActivityThread.main(ActivityThread.java:5074)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
at dalvik.system.NativeStart.main(Native Method)
报错的进程的主线程停在MessageQueue.nativePollOnce， 这类问题目前无法解决，直接剔除
3.4Google原生
直接剔除
FRM-SCR不会计入APR，直接剔除
4典型问题的分析
4.1ANR等待锁（）
下面我们举个例子
从标灰地方可以看出当前在执行DeviceManager被锁,在这种情况下有两种办法查看该问题
1>根据如上堆栈梳理流程查问题（相关模块责任人应该比较了解,门外汉不管用）
2>直接查看被锁对象在做什么（如果没有就看流程吧）
搜索DeviceManager
搜索完毕后发现DeviceManager在handleMessage执行后又被SetParameterRequest locked了，而SetParameterRequest执行execute后卡在native_getParameters继续查看上面堆栈
如上可以看到阻塞在binder通信过程中，而native_getParameters根据堆栈看到他调用的是libcamera_client.so
搜索libcamera_client
到了这里是不是很清晰了，类和方法名都打出来了（红色标注），直接查看，再不清楚直接反编译定位行数
4.2tombstone （）
通过上面可以看出该tombstone 发生在system/bin/mediaserver进程中，错误代号是SI_TKILL
SI_TKILL是指被系统发送kill杀掉，如下官方解释
继续看报错堆栈吧
正常情况下可以通过反编译定位哪一行报错，目前无对应版本symbols的so库给出方法（该问题出现是B092版本 B092的服务器上已删了）,用新编的symbols行号对应不上，
然后根据对应行号去分析逻辑发现当时程序执行的是post但是却发送了senderAwaitsResponse, 故使得CHECK时出错，出现该问题（修改方案见DTS单）。
5总结
APR就目前而言出现最多就两类
1>ANR: ANR问题的分析思路，主要是看ANR主线程被什么线程阻塞了。
2>tombstone ：先根据报错类型，然后排查相关逻辑，类型定义如下（也还有其它类型可自行查阅）：
