前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Android卡顿优化 | 卡顿单点问题监测方案

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

作者头像
凌川江雪
发布2020-04-09 15:51:31
2.3K0
发布2020-04-09 15:51:31
举报
文章被收录于专栏:李蔚蓬的专栏

本文要点

  • 背景介绍
  • 监测指标
  • 常规方案
  • IPC问题监测技巧
  • 相对优雅的方案【ARTHook】
  • ARTHook实战
  • 小结

项目GitHub

背景介绍

  • 前面提到过两种自动化自动化检测方案: AndroidPerformanceMonitorANR-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() BinderProxyBinder的内部类; 这里注意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: 【注意, 在打印的时候我加了一个logTAGARTHookTest 所以在查看logcat的时候可以定位ARTHookTest这个关键词, 方便调试!!!】 -IPC;IO类型单点问题;

View处理:

PMS类型的IPC调用:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 可以看到ARTHook框架帮助我们快速定位找出了存在IPC调用的代码位置, 收集打印出堆栈信息,说清楚了IPC调用来源和过程 并且是一直运行的, APP中只要发生了IPC操作调用 就会整个操作的信息都被捕获下来, 所以我们可以看到只要IPC在不断发生 logcat中关于ARTHook打印的信息就一直在滚动!!!!! 不同的时间点!!!!!!调用了什么IPC,全数被打印出来!!!!!! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 这样一来, APP的所有IPC操作调用、单点问题我们就能很方便地捕获到了, 并可以获取到IPC调用类型、调用耗时、发生次数、调用堆栈、发生的时刻等。 随后便可以进行详细的分析,统筹优化;

小结

  • 可以利用ARTHook完善线下工具;
  • 开发阶段Hook相关操作,暴露、分析问题;
  • 完善体系化性能优化解决方案

参考:

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 背景介绍
  • 监测指标
  • 常规方案
  • IPC问题监测技巧
  • 相对优雅的方案
  • ARTHook实战
  • 小结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档