四. Android 卡顿优化

1. 工具选择

CPU Profiler、Systrace、StrictMode

原因复杂：代码、内存、绘制、IO均有可能导致卡顿。难以定位。
不易复现：当时场景强相关。

CPU Profiler：图形的形式展示执行时间、调用栈等。信息全面，包含所有线程。整体会变慢。
使用方式：

Debug.startMethodTracing("");
Debug.stopMethodTracing("");

生成文件在SD卡：Android/data/packagename/files

Systrace：监控和跟踪Api调用、线程运行情况，生成Html报告

API 18以上使用，推荐TraceCompat

python systrace.py -t 10 [other-options] [categories]

https://developer.android.com/studio/command-line/systrace#command_options

优点：轻量级、开销小。直观反映CPU利用率。给出建议（Alert）
StrictMode：严苛模式，Android提供的一种运行时检测机制。方便强大，容易被忽视。
包含：线程策略和虚拟机策略检测。

线程策略：自定义的耗时调用，detectCustomSlowCalls()
磁盘读取操作，detectDiskReads
网络请求操作

虚拟机策略：
Activity泄漏，detectActivityLeaks()
Sqlite泄漏，detecteLeakedSqliteObjects
检测实例数量，setClassInstanceLimit()

2. 自动化卡顿检测方案及优化

原理：一个线程只有一个Looper
mLogging对象在每个message处理前后被调用
主线程发生卡顿，是在dispatchMessage执行耗时操作

具体实现：
1）Looper.getMainLooper().setMessageLogging();
2）匹配>>>>>Dispatching，阈值时间后执行任务（获取堆栈）
3）匹配<<<<<Finished，任务启动之前取消掉

AndroidPermormanceMonitor实战（blockcanary）
非侵入性的性能监控组件，通知形式弹出卡顿信息

问题及优化
卡顿了，但卡顿堆栈可能不准确。和OOM一样，最后的堆栈只是表象，不是真正的问题。

优化：获取监控周期内的多个堆栈，而不仅是最后一个。
startMonitor -> 高频采集堆栈-> endMonitor -> 记录多个堆栈 -> 上报

海量卡顿堆栈处理
高频卡顿上报量太大，服务端有压力。
分析：一个卡顿下多个堆栈大概率有重复
解决：对一个卡顿下堆栈进行hash排重，找出重复的堆栈。
效果：极大的减少展示量且找到真正发生问题的堆栈。

3. ANR分析与实战

KeyDispatchTimeout：5s
BroadcastTimeout：前台10s，后台60s
ServiceTimeout：前台20s，后台200s

ANR执行流程：发生ANR，进程接收异常终止信号，开始写入进程ANR信息。
弹出ANR提示框（ROM表现不一）

ANR解决套路：

adb pull data/anr/traces.txt

存储路径。根据此路径来判断是否ANR
详细分析：cpu/io

线上ANR监控方案
通过FileObserver 监控文件变化，高版本会有权限问题

ANR-WatchDog
非侵入式ANR监控组件

com.github.anrwatchdog:anrwatchdog:1.3.0

https://github.com/SalomonBrys/ANR-WatchDog

原理：
start -> post消息改值(主线程+1操作) -> 线程sleep
检测值是否被修改 ->判断ANR发生（没有被修改 message没有到即发生）
弥补高版本没有权限读取Trace.txt 的问题。结合使用
和BlockCanary区别：
BlockCanary监控Msg。适合监控卡顿。
ANR-WatchDog：看最终结果。适合补充ANR监控。

3. 卡顿单点问题检测方案

自动化卡顿检测方案并不够。很多操作的耗时并没有达到卡顿阈值，感受同样不佳但是不会抛出异常堆栈信息。

体系化解决方案务必尽早暴露问题。
单点问题：主线程IPC、DB IO、View绘制操作

IPC问题监测：
监测指标：IPC调用类型
调用耗时、次数
调用堆栈、发生线程。

常规方案：
IPC前后加埋点。不够优雅，容易忘记。维护成本大。

adb命令：

adb shell am trace-ipc start // 监控的开始
adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
//结束，存放信息
adb pull /data/local/tmp/ipc-trace.txt // 导出

优雅方案：
ARTHook 还是 AspectJ？
ARTHook 可以Hook系统方法。ASpectJ针对非系统方法。

IPC场景：PackageManger得到应用信息、get到设备的ID、AMS等等。
固定的调用方式，最后会调用到 “android.os.BinderProxy” transact方法