ANR
Application Not Responding
ANR类型
Service Timeout:比如前台服务在20s内未执行完成，后台服务Timeout时间是前台服务的10倍，200s；
BroadcastQueue Timeout：比如前台广播在10s内未执行完成，后台60s
ContentProvider Timeout：内容提供者,在publish过超时10s;
InputDispatching Timeout: 输入事件分发超时5s，包括按键和触摸事件。
对于input来说即便某次事件执行时间超过Timeout时长，只要用户后续没有再生成输入事件，则不会触发ANR
ANR文件获取方式
1.低于Android10系统的手机
adb pull data/anr
2.大于等于Android10系统的手机
如果在Android10以上系统，使用adb pull的方式拉取trace文件，会得到permission denied。需要使用新的命令完成
adb bugreport
导致ANR的原因
应用层导致ANR：
1.函数阻塞：如死循环、主线程IO、处理大数据。
2.锁出错：主线程等待子线程的锁。
3.内存紧张：系统分配给一个应用的内存是有上限的，长期处于内存紧张，会导致频繁内存交换，进而导致应用的一些操作超时。
系统导致ANR：
1.CPU被抢占：一般来说，前台在玩游戏，可能会导致你的后台广播被抢占。
2.系统服务无法及时响应：系统的服务都是Binder机制，服务能力也是有限的，有可能系统服务长时间不响应导致ANR。
3.其他应用占用大量内存。
系统ANR检测机制
ANR由消息处理机制保证，核心原理是消息调度和超时处理。
虽然系统触发anr的地方有好几种，但是检测机制和处理机制其实是差不多的，都是在操作前记录时间，然后向消息队列中丢向一个触发Anr的消息（基于消息机制），再执行完响应的操作的时候将消息移除，如果超过指定时间没有移除，那么则会触发anr操作。
ps发生anr的时候是主线程已经被阻塞了，anr也是基于消息机制，是一个延时消息，那为什么它还能被执行呢？
发生anr时，被阻塞的是app进程的主线程，而anr延时消息并不是在app进程中处理的。它是通过AMS所在进程中的子线程消息队列中执行的（ams内部除了有主线程的消息队列外，还持有了一个异步的消息队列），所以时间到了之后还是可以被looper取出; 然后将显示anr弹窗的消息发送到AMS主线程的消息队列（mUiHandler），去展示弹窗。
service: 当Service的生命周期开始时，bumpServiceExecutingLocked()会被调用，紧接着会调用scheduleServiceTimeoutLocked(),向消息队列发送一个延迟消息（20s（后台服务200s）），当Service的生命周期结束时，在serviceDoneExecutingLocked方法中移除这个消息，如果时间到了还没有移除，就提示anr。由AMS调度，利用Handler和Looper，设计了一个TIMEOUT消息交由AMS线程来处理，整个超时机制的实现都是在Java层。
broadcast:Broadcast ANR，前台的“串行广播消息”必须在10秒内处理完毕，后台的“串行广播消息”必须在60秒处理完毕， 每派发串行广播消息到一个接收器时，都会抛出一个定时消息BROADCAST_TIMEOUT_MSG，如果定时消息响应，则判断是否广播消息处理超时，超时就说明发生了ANR。由AMS调度，利用Handler和Looper，设计了一个TIMEOUT消息交由AMS线程来处理，整个超时机制的实现都是在Java层。
input: 在InputDispatcher派发输入事件时，会寻找接收事件的窗口，如果无法正常派发，则可能会导致当前需要派发的事件超时(默认是5秒)。 Native层发现超时了，会通知Java层，Java层经过一些处理后，会反馈给Native层，是继续等待还是丢弃当前派发的事件。 InputEvent由InputDispatcher调度，待处理的输入事件都会进入队列中等待，设计了一个等待超时的判断，超时机制的实现在Native层。
service、broadcast、provider 的ANR原理都是埋定时炸弹和拆炸弹原理，
但是input的超时检测机制稍微有点不同，需要等收到下一次input事件，才会去检测上一次input事件是否超时，input事件里埋的炸弹是普通炸弹，需要通过扫雷来排查。
SNR(System Not Respoding)
SNR由Watchdog机制保证。Watchdog定时（30s）检查一些重要的系统服务，举报长时间阻塞的事件，甚至杀掉system_server进程，让Android系统重启。
Monitor Checker(addMonitor)，用于检查是Monitor对象可能发生的死锁, AMS, PKMS, WMS等核心的系统服务都是Monitor对象。
Looper Checker(addThread)，用于检查线程的消息队列是否长时间处于工作状态。一些重要的线程的消息队列，也会加入到Looper Checker中，譬如AMS, PKMS，这些是在对应的对象初始化时加入的。
Monitor Checker预警我们不能长时间持有核心系统服务的对象锁，否则会阻塞很多函数的运行; Looper Checker预警我们不能长时间的霸占消息队列，否则其他消息将得不到处理。这两类都会导致系统卡住(System Not Responding)。
ANR主要流程
所有ANR，最终都会调用AppErrors的appNotResponding方法
1.系统监控到app发生ANR后，收集了一些相关进程pid（包括发生ANR的进程），准备让这些进程dump堆栈，从而生成ANR Trace文件。
2.系统开始向这些进程发送SIGQUIT信号(通过监听这个信号可以实现对anr的监控，如matrix的实现)，进程收到SIGQUIT信号之后开始dump堆栈。
AMS开始按照firstPids、nativePids、extraPids的顺序dump这些进程的堆栈。并且最长dump时间限制为20秒。
dump的调用过程：
→ dumpStackTraces
→ dumpJavaTracesTombstoned
→ ActivityManagerService#dumpJavaTracesTombstoned()
→ Debug#dumpJavaBacktraceToFileTimeout()
→ android_os_Debug#android_os_Debug_dumpJavaBacktraceToFileTimeout()
→ android_os_Debug#dumpTraces()
→ debuggerd_client#dump_backtrace_to_file_timeout()
→ debuggerd_client#debuggerd_trigger_dump()。
1.AMS进程间接给需要dump堆栈那个进程发送了一个SIGQUIT信号
2.除Zygote进程外，每个进程都会创建一个SignalCatcher守护线程，用于捕获SIGQUIT,然后开始dump
3.这个过程从收到SIGQUIT信号开始到使用socket写Trace结束。
ANR监控
一. WatchDog
ANRWatchDog 是一个自动检测ANR的开源库，往主线程发送消息，并设置超时检测，如果超时还没执行相应消息，则判定为可能发生ANR。需要进一步从系统服务获取相关数据（可通过ActivityManagerService.getProcessesInErrorState()方法获取进程的ANR信息），进一步判定是否真的发生了ANR。
缺点
1.存在5s的误差，假设当ANRWatchDog post消息的时候，已经卡了2s，然后再过3s卡完了恢复了，那么ANRWatchDog是监测不到的。
2.和BlockCanary一样不支持touch事件的监测
优化ANRWatchDog存在5s的误差的缺点（AnrMonitor）。每隔1s就会检查一下，并提示可能的风险，累计5s就触发ANR流程，这是一个实现思路，代码只提供了一个demo,还需要完善。此方案可以结合ProcessLifecycleOwner，应用在前台才开启检测，进入后台则停止检测。
二. SIGQUIT信号
该方案通过去监听SIGQUIT信号，从而感知当前进程可能发生了ANR，需配合当前进程是否处于NOT_RESPONDING状态以及主线程是否卡顿来进行甄别，以免误判。这种方案才是真正的监控ANR，matrix、xCrash都在使用这种方案。已经在微信等app上检验过，稳定性和可靠性都能得到保证。
1.监听SIGQUIT信号。
系统监控到app发生ANR后，收集了一些相关进程pid，并向这些进程发送SIGQUIT信号，进程收到SIGQUIT信号之后开始dump堆栈，通过对这个信号的监听，实现anr的监听，实现方式见matrix框架（https://github.com/Tencent/matrix/tree/master/matrix/matrix-android/matrix-trace-canary/src/main）。
2.监听NOT_RESPONDING标记。
发生ANR的进程一定会收到SIGQUIT信号；但是收到SIGQUIT信号的进程并不一定发生了ANR。为了解决这个问题，回到源码中，我们会发现执行makeAppNotRespondingLocked方法时，会给发生ANR的进程标记一个NOT_RESPONDING的flag，这个flag可以通过ActivityManager来获取：
private static boolean checkErrorState() {
try {
Application application = sApplication == null ? Matrix.with().getApplication() : sApplication;
ActivityManager am = (ActivityManager) application.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.ProcessErrorStateInfo> procs = am.getProcessesInErrorState();
if (procs == null) return false;
for (ActivityManager.ProcessErrorStateInfo proc : procs) {
if (proc.pid != android.os.Process.myPid()) continue;
if (proc.condition != ActivityManager.ProcessErrorStateInfo.NOT_RESPONDING) continue;
return true;
}
return false;
} catch (Throwable t){
MatrixLog.e(TAG,"[checkErrorState] error : %s", t.getMessage());
}
return false;
}
监控到SIGQUIT后，我们在20秒内（20秒是ANR dump的timeout时间）不断轮询自己是否有NOT_RESPONDING的flag，一旦发现有这个flag，那么马上就可以认定发生了一次ANR。
3.结合线程是否处于卡顿状态判断
发生ANR的进程并不一定会被设置为NOT_RESPONDING状态，如后台ANR会直接被杀死，另外有些机型修改了anr的逻辑，发生anr后直接杀死了进程，所以需要一种机制，在收到SIGQUIT信号后，需要非常快速的侦查出自己是否已经处于ANR的状态，进行快速的dump和上报，可以通过主线程释放处于卡顿状态来判断，可以通过Looper的mMessage对象，该对象的when变量，表示的是当前正在处理的消息入队的时间，我们可以通过when变量减去当前时间，得到的就是等待时间，如果等待时间过长，就说明主线程是处于卡住的状态。这时候收到SIGQUIT信号基本上就可以认为的确发生了一次ANR。
ANR Trace.txt文件获取
低版本可以直接拿到，但是高版本无法拿到，怎么解决这个问题？从上边的分析我们知道，除了Zygote进程之外，每个进程都有一个SignalCatcher线程来监听SIGQUIT信号，后边通过socket将dump的内容写入（write）文件中，可以直接hook这里的write，就能直接拿到系统dump的ANR Trace内容。
Trace.txt文件分析
"Signal Catcher" daemon prio=5 tid=4 Runnable
| group="system" sCount=0 dsCount=0 flags=0 obj=0x18c84570 self=0x7252417800
| sysTid=7772 nice=0 cgrp=default sched=0/0 handle=0x725354ad50
| state=R schedstat=( 16273959 1085938 5 ) utm=0 stm=1 core=4 HZ=100
| stack=0x7253454000-0x7253456000 stackSize=991KB
| held mutexes= "mutator lock"(shared held)
-"Signal Catcher" daemon ：线程名，有daemon表示守护线程
-prio：线程优先级
-tid：线程内部id
-线程状态：Runnable
-group：线程所属的线程组
-sCount：线程挂起次数
-dsCount：用于调试的线程挂起次数
-obj：当前线程关联的Java线程对象
-self：当前线程地址
-sysTid：线程真正意义上的tid
-nice：调度优先级，值越小则优先级越高
-cgrp：进程所属的进程调度组
-sched：调度策略
-handle：函数处理地址
-state：线程状态
-schedstat：CPU调度时间统计（schedstat括号中的3个数字依次是Running、Runable、Switch，Running时间：CPU运行的时间，单位ns，Runable时间：RQ队列的等待时间，单位ns，Switch次数：CPU调度切换次数）
-utm/stm：用户态/内核态的CPU时间
-core：该线程的最后运行所在核
-HZ：时钟频率
-stack：线程栈的地址区间
-stackSize：栈的大小
-mutex：所持有mutex类型，有独占锁exclusive和共享锁shared两类
ANR案例分析
1.主线程无卡顿，处于正常状态堆栈
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x74b38080 self=0x7ad9014c00
| sysTid=23081 nice=0 cgrp=default sched=0/0 handle=0x7b5fdc5548
| state=S schedstat=( 284838633 166738594 505 ) utm=21 stm=7 core=1 HZ=100
| stack=0x7fc95da000-0x7fc95dc000 stackSize=8MB
| held mutexes=
kernel: __switch_to+0xb0/0xbc
kernel: SyS_epoll_wait+0x288/0x364
kernel: SyS_epoll_pwait+0xb0/0x124
kernel: cpu_switch_to+0x38c/0x2258
native: #00 pc 000000000007cd8c /system/lib64/libc.so (__epoll_pwait+8)
native: #01 pc 0000000000014d48 /system/lib64/libutils.so (android::Looper::pollInner(int)+148)
native: #02 pc 0000000000014c18 /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+60)
native: #03 pc 00000000001275f4 /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce(Native method)
at android.os.MessageQueue.next(MessageQueue.java:330)
at android.os.Looper.loop(Looper.java:169)
at android.app.ActivityThread.main(ActivityThread.java:7073)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:536)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:876)
看起来很正常，主线程是空闲的，因为它正处于nativePollOnce，正在等待新消息。处于这个状态，那还发生了ANR，可能有2个原因：
1.dump堆栈时机太晚了，ANR已经发生过了，才去dump堆栈，此时主线程已经恢复正常了。
2.CPU抢占或者内存紧张等其他因素引起。
2.主线程执行耗时操作
//模拟主线程耗时操作,View点击的时候调用这个函数
fun makeAnr(view: View) {
var s = 0L
for (i in 0..99999999999) {
s += i
}
Log.d("xxx", "s=$s")
}
suspend all histogram: Sum: 206us 99% C.I. 0.098us-46us Avg: 7.629us Max: 46us
DALVIK THREADS (16):
"main" prio=5 tid=1 Runnable
| group="main" sCount=0 dsCount=0 flags=0 obj=0x73907540 self=0x725f010800
| sysTid=32298 nice=-10 cgrp=default sched=1073741825/2 handle=0x72e60080d0
| state=R schedstat=( 6746757297 5887495 256 ) utm=670 stm=4 core=6 HZ=100
| stack=0x7fca180000-0x7fca182000 stackSize=8192KB
| held mutexes= "mutator lock"(shared held)
at com.xfhy.watchsignaldemo.MainActivity.makeAnr(MainActivity.kt:58)
at java.lang.reflect.Method.invoke(Native method)
at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)
at android.view.View.performClick(View.java:7317)
at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1219)
at android.view.View.performClickInternal(View.java:7291)
at android.view.View.access$3600(View.java:838)
at android.view.View$PerformClick.run(View.java:28247)
at android.os.Handler.handleCallback(Handler.java:900)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:219)
at android.app.ActivityThread.main(ActivityThread.java:8668)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)
从日志上看，主线程处于执行状态，不是空闲状态，导致ANR了，说明com.xfhy.watchsignaldemo.MainActivity.makeAnr这里有耗时操作。
3.主线程被锁阻塞
fun makeAnr(view: View) {
val obj1 = Any()
val obj2 = Any()
//搞个死锁，相互等待
thread(name = "卧槽") {
synchronized(obj1) {
SystemClock.sleep(100)
synchronized(obj2) {
}
}
}
synchronized(obj2) {
SystemClock.sleep(100)
synchronized(obj1) {
}
}
}
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 flags=1 obj=0x73907540 self=0x725f010800
| sysTid=19900 nice=-10 cgrp=default sched=0/0 handle=0x72e60080d0
| state=S schedstat=( 542745832 9516666 182 ) utm=48 stm=5 core=4 HZ=100
| stack=0x7fca180000-0x7fca182000 stackSize=8192KB
| held mutexes=
at com.xfhy.watchsignaldemo.MainActivity.makeAnr(MainActivity.kt:59)
- waiting to lock <0x0c6f8c52> (a java.lang.Object) held by thread 22 //注释1
- locked <0x01abeb23> (a java.lang.Object)
at java.lang.reflect.Method.invoke(Native method)
at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)
at android.view.View.performClick(View.java:7317)
at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1219)
at android.view.View.performClickInternal(View.java:7291)
at android.view.View.access$3600(View.java:838)
at android.view.View$PerformClick.run(View.java:28247)
at android.os.Handler.handleCallback(Handler.java:900)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:219)
at android.app.ActivityThread.main(ActivityThread.java:8668)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)
"卧槽" prio=5 tid=22 Blocked //注释2
| group="main" sCount=1 dsCount=0 flags=1 obj=0x12c8a118 self=0x71d625f800
| sysTid=20611 nice=0 cgrp=default sched=0/0 handle=0x71d4513d50
| state=S schedstat=( 486459 0 3 ) utm=0 stm=0 core=4 HZ=100
| stack=0x71d4411000-0x71d4413000 stackSize=1039KB
| held mutexes=
at com.xfhy.watchsignaldemo.MainActivity$makeAnr$1.invoke(MainActivity.kt:52)
- waiting to lock <0x01abeb23> (a java.lang.Object) held by thread 1
- locked <0x0c6f8c52> (a java.lang.Object)
at com.xfhy.watchsignaldemo.MainActivity$makeAnr$1.invoke(MainActivity.kt:49)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
......
注意看，下面几行：
"main" prio=5 tid=1 Blocked
- waiting to lock <0x0c6f8c52> (a java.lang.Object) held by thread 22
- locked <0x01abeb23> (a java.lang.Object)
"卧槽" prio=5 tid=22 Blocked
- waiting to lock <0x01abeb23> (a java.lang.Object) held by thread 1
- locked <0x0c6f8c52> (a java.lang.Object)
主线程的tid是1，线程状态是Blocked，正在等待0x0c6f8c52这个Object，而这个Object被thread 22这个线程所持有，主线程当前持有的是0x01abeb23的锁。而卧槽的tid是22，也是Blocked状态，它想请求的和已有的锁刚好与主线程相反。这样的话，ANR原因也就找到了：线程22持有了一把锁，并且一直不释放，主线程等待这把锁发生超时。在线上环境，常见因锁而ANR的场景是SharePreference写入。
4. CPU被抢占
CPU usage from 0ms to 10625ms later (2020-03-09 14:38:31.633 to 2020-03-09 14:38:42.257):
543% 2045/com.test.demo: 54% user + 89% kernel / faults: 4608 minor 1 major //注意看这里
99% 674/[email protected]: 81% user + 18% kernel / faults: 403 minor
24% 32589/com.wang.test: 22% user + 1.4% kernel / faults: 7432 minor 1 major
......
可以看到，该进程占据CPU高达543%，抢占了大部分CPU资源，因为导致发生ANR，这种ANR与我们的app无关。
5.内存紧张导致ANR
如果一份ANR日志的CPU和堆栈都很正常，可以考虑是内存紧张。看一下ANR日志里面的内存相关部分。还可以去日志里面搜一下onTrimMemory，如果dump ANR日志的时间附近有相关日志，可能是内存比较紧张了。
10-31 22:37:19.749 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:37:33.458 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:38:00.153 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:38:58.731 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:39:02.816 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
6.系统服务超时导致ANR
系统服务超时一般会包含BinderProxy.transactNative关键字，来看一段日志：
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x727851e8 self=0x78d7060e00
| sysTid=4894 nice=0 cgrp=default sched=0/0 handle=0x795cc1e9a8
| state=S schedstat=( 8292806752 1621087524 7167 ) utm=707 stm=122 core=5 HZ=100
| stack=0x7febb64000-0x7febb66000 stackSize=8MB
| held mutexes=
kernel: __switch_to+0x90/0xc4
kernel: binder_thread_read+0xbd8/0x144c
kernel: binder_ioctl_write_read.constprop.58+0x20c/0x348
kernel: binder_ioctl+0x5d4/0x88c
kernel: do_vfs_ioctl+0xb8/0xb1c
kernel: SyS_ioctl+0x84/0x98
kernel: cpu_switch_to+0x34c/0x22c0
native: #00 pc 000000000007a2ac /system/lib64/libc.so (__ioctl+4)
native: #01 pc 00000000000276ec /system/lib64/libc.so (ioctl+132)
native: #02 pc 00000000000557d4 /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+252)
native: #03 pc 0000000000056494 /system/lib64/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+60)
native: #04 pc 00000000000562d0 /system/lib64/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+216)
native: #05 pc 000000000004ce1c /system/lib64/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+72)
native: #06 pc 00000000001281c8 /system/lib64/libandroid_runtime.so (???)
native: #07 pc 0000000000947ed4 /system/framework/arm64/boot-framework.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+196)
at android.os.BinderProxy.transactNative(Native method) ————————————————关键行！！！
at android.os.BinderProxy.transact(Binder.java:804)
at android.net.IConnectivityManager$Stub$Proxy.getActiveNetworkInfo(IConnectivityManager.java:1204)—关键行！
at android.net.ConnectivityManager.getActiveNetworkInfo(ConnectivityManager.java:800)
at com.xiaomi.NetworkUtils.getNetworkInfo(NetworkUtils.java:2)
at com.xiaomi.frameworkbase.utils.NetworkUtils.getNetWorkType(NetworkUtils.java:1)
at com.xiaomi.frameworkbase.utils.NetworkUtils.isWifiConnected(NetworkUtils.java:1)
从日志堆栈中可以看到是获取网络信息发生了ANR：getActiveNetworkInfo。系统的服务都是Binder机制（16个线程），服务能力也是有限的，有可能系统服务长时间不响应导致ANR。如果其他应用占用了所有Binder线程，那么当前应用只能等待。可进一步搜索：blockUntilThreadAvailable关键字：
at android.os.Binder.blockUntilThreadAvailable(Native method)
如果有发现某个线程的堆栈，包含此字样，可进一步看其堆栈，确定是调用了什么系统服务。此类ANR也是属于系统环境的问题，如果某类型手机上频繁发生此问题，应用层可以考虑规避策略。
还有不足
当前Trace堆栈所在业务耗时严重。
当前Trace堆栈所在业务耗时并不严重，但历史调度有一个严重耗时。
当前Trace堆栈所在业务耗时并不严重，但历史调度有多个消息耗时。
当前Trace堆栈所在业务耗时并不严重，但是历史调度存在巨量重复消息（业务频繁发送消息）。
当前Trace堆栈业务逻辑并不耗时，但是其他线程存在严重资源抢占，如IO、Mem、CPU。
当前Trace堆栈业务逻辑并不耗时，但是其他进程存在严重资源抢占，如IO、Mem、CPU。
这里的6个影响因素中，除了第一个以外，其他的根据ANR Trace有可能无法进行判别。这就会导致很多时候看到的ANR Trace里面主线程堆栈对应的业务其实并不耗时（因为可能是前面的消息导致的耗时，但它已经执行完了），如何解决这个问题？
字节跳动内部有一个监控工具：Raster，大致原理：该工具主要是在主线程消息调度过程进行监控。比较耗时的消息会抓取主线从堆栈，这样可以知道那个耗时的消息具体是在干什么，从而针对性优化。同时对应用四大组件消息执行过程进行监控，便于对这类消息的调度及耗时情况进行跟踪和记录。另外对当前正在调度的消息及消息队列中待调度消息进行统计，从而在发生问题时，可以回放主线程的整体调度情况。此外，该库将系统服务的CheckTime机制迁移到应用侧，应用为线程CheckTime机制，以便于系统信息不足时，从线程调度及时性推测过去一段时间系统负载和调度情况。因此该工具用一句话来概括就是：由点到面，回放过去，现在和将来。