本文要点
- 背景介绍
- 监测指标
- 常规方案
- IPC问题监测技巧
- 相对优雅的方案【ARTHook】
- ARTHook实战
- 小结
项目GitHub
#背景介绍
-
前面提到过两种自动化自动化检测方案：
AndroidPerformanceMonitor和ANR-WatchDog； -
需要本方案的原因：自动化卡顿检测方案无法满足所有场景； 如，有很多Message要执行， 但是所有Message的时间， 都没有达到
自动化卡顿检测方案所配置的卡顿的判定阈值， 那这种情况，自动化卡顿检测方案对这些“较小型”的卡顿问题便无能为力了； 可是这些没有达到卡顿的判定阈值的“较小型”的卡顿问题， 却会一直影响用户体验，这显然是不行的！！ -
需要建立
体系化的卡顿解决方案， 便要尽早地尽可能多地暴露问题，补充已有方案的不足； -
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 需要关注的
单点问题：IPC、DB操作、IO、View绘制等； 下面以主线程IPC为例， 因为IPC其实是一个很耗时的操作， 但实际开发时很多时候都没有得到足够的重视， 偶尔还会在主线程进行IPC操作，以及频繁的调用， 而这种耗时其实很少达到卡顿的阈值； ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#监测指标
- IPC的调用类型
如
PackageManager的调用、ActivityManagerService的调用和TelephoneManager的调用就是属于不同的调用类型（不同类型的IPC操作）； - IPC的调用耗时、次数
- IPC的
调用堆栈【哪行代码调用的】、发生线程【IPC具体发生在哪个线程】
#常规方案
- 在IPC前后加埋点
- 缺点：不优雅，容易忘记； 维护成本大，人员交接也麻烦；
#IPC问题监测技巧
- 【线下】adb命令
-
adb shell am trace-ipc start运行这行命令，可以对IPC的操作进行监控； -
adb shell am trace-ipc stop -dump-file /data/local/tmp/ipc-trace.txt监控结束，并将监控到的信息存放到相对应的文件当中； -
adb pull /data/local/tmp/ipc-trace.txt将文件导出；
-
#相对优雅的方案
-
ARTHook：可以Hook系统方法， 对系统方法来说，其实并没有办法对其修改， 但是我们可以Hook它的方法， 再在方法体中，加上自己的代码；
-
AspectJ：只能针对非系统的方法， 即我们自己APP的源码或者我们自己引用的库包， AspectJ实际上是往我们的具体方法里面插入相对应的代码， 即无法针对系统方法做一个操作；
-
所以这里使用ARTHook；
-
其实诸如通过
PackageManagerService的调用拿到应用的信息、get到群从设备标识符(GSID)的信息、ActivityManagerService的调用和TelephoneManager的调用等都是有涉及到IPC操作， 这样的操作其实都是有一个固定的调用方式， 即不管是通过那种IPC调用类型， 只要是IPC操作，^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 最终都会调用到一个类android.os.BinderProxy， ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 然后它会调用其自身方法transact()；BinderProxy是Binder的内部类； 这里注意transact()的几个参数！！！！！！！！：
#ARTHook实战
- Epic是一个虚拟机层面，以Java Method为粒度的运行时Hook框架
- 支持Android4.0 - 10.0
- 官网 github.com/tiann/epic
- 依赖
compile 'me.weishu:epic:0.6.0' - Hook的意思是勾住，也就是在消息过去之前， 可以先把消息暂时勾住，不让其传递，我们可以优先处理； 《Hook的基础原理》
- 引入依赖； - **使用框架： 首先需要给ARTHook传入一个Class， 这里是以映射的方式间接引用到`BinderProxy`， 因为`BinderProxy`是没有办法直接引用到的， 然后二参是Hook方法，即这里的`transact()`， 然后传入一些类实例， 最后传入的是一个回调接口， 在回调方法`beforeHookedMethod()`中， 我们就可以打印`具体的调用栈信息`， 便可以知道这次的`IPC`调用 是从哪里调过来的； 下面项目准备了几个类型的单点问题模拟， 运行程序，查看logcat: 【注意， 在打印的时候我加了一个`logTAG`即`ARTHookTest`， 所以在查看logcat的时候可以定位`ARTHookTest`这个关键词， 方便调试！！！】 -`IPC；IO`类型单点问题；View处理： PMS类型的IPC调用：^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 可以看到`ARTHook框架`帮助我们快速定位找出了存在`IPC调用`的代码位置， 并`收集打印出堆栈信息`，说清楚了`IPC调用`的`来源和过程`； 并且是一直运行的， APP中只要`发生了IPC操作调用`， 就会整个`操作的信息`都被捕获下来， 所以我们可以看到只要`IPC`在不断`发生`， logcat中关于`ARTHook`打印的信息就一直在滚动！！！！！ 不同的`时间点`！！！！！！调用了什么`IPC`，全数被打印出来！！！！！！ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这样一来， `APP的所有IPC操作调用、单点问题`我们就能很方便地捕获到了， 并可以获取到`IPC调用`的`类型、调用耗时、发生次数、调用堆栈、发生的时刻`等。
随后便可以进行详细的分析，统筹优化；**
#小结
- 可以利用ARTHook完善线下工具；
- 开发阶段Hook相关操作，暴露、分析问题；
- 完善体系化性能优化解决方案
参考：
