记一次anr问题排查

1首先我们从anr目录下的event日志定位到是什么类型的anr

并且通过下图红框的内容可以看出原因是：
Input dispatching timed out (Application does not have a focused window)
另外可以看出出现anr问题的进程是：31334

2 通过进程号可以定位出：具体的

根据：dvm_lock_sample关键词可以得出系统变慢
配合 Main Log(Android Log) 和 EventLog 把 CPU 开始和结束的时间点内的所有有用信息提取出来到一个 文件中，搜索的主要关键字：pid，进程名，WindowManager、ActivityManager（关键字参考下一节的关键 Log 那里）
收集关键操作场景，比如解锁、安装应用、亮灭屏、应用启动等
收集异常和系统关键 Log
系统变慢 ：比如 Slow operation、Slow dispatch、Slow delivery、dvm_lock_sample、binder_sample
进程变化 ：am_kill、am_proc_died、lowmemorykiller、ANR、应用启动关系等
系统信息 ：cpu info、meminfo、binder info（是否满了） 、iowait (是否过高)
消息监控 ：ANR 前的 ANR Message 打印，Block Message 信息，应用自己代码执行逻辑推断出的 Message 耗时等
收集 ANR 进程的所有关键线程的运行情况、线程优先级等
根据第四步提取出来的关键信息文件，进一步理出系统当时的情况、状态（（推荐 vscode 或者 notepad ++ ，有 线索就全局搜索）），比如
是处于低内存频繁杀进程？
重启第一次解锁系统繁忙
还是短时间内多个应用启动系统繁忙
还是应用自己的逻辑等待？
针对不同的 ANR 类型，提取不同的信息
3 这一行代码具体分析：
dvm_lock_sample
当某个线程等待 lock 的时间 blocked 超过阈值（比如：500ms）,则输出当前的持锁状态.
dvm_lock_sample：[system_server,1,Binder_9,1500,ActivityManagerService.java,6403,-,1448,0]
system_server: Binder_9 执行到 ActivityManagerService.java 的 6403 行代码,一直在等待 AMS 锁
"-"代表持锁的是同一个文件，即该锁被同一文件的 1448 行代码所持有, 从而导致 Binder_9 线程被阻塞 1500ms.
初步判定为系统问题