Android卡顿优化 | 卡顿单点问题监测方案

本文要点

• 背景介绍
• 监测指标
• 常规方案
• 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
• 官网 https://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相关操作，暴露、分析问题；
• 完善体系化性能优化解决方案

---

参考：

• 慕课网
• PackageManager的使用