本文要点
AndroidPerformanceMonitor
和ANR-WatchDog
;自动化卡顿检测方案
所配置的卡顿的判定阈值
,
那这种情况,自动化卡顿检测方案
对这些“较小型”的卡顿问题
便无能为力了;
可是这些没有达到卡顿的判定阈值
的“较小型”的卡顿问题
,
却会一直影响用户体验
,这显然是不行的!!体系化的卡顿解决方案
,
便要尽早地尽可能多地暴露问题,补充已有方案的不足;单点问题
:IPC、DB操作、IO、View绘制
等;
下面以主线程IPC为例,
因为IPC
其实是一个很耗时
的操作,
但实际开发时很多时候都没有得到足够的重视
,
偶尔还会在主线程进行IPC
操作,以及频繁的调用,
而这种耗时
其实很少达到卡顿的阈值
;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^PackageManager
的调用、ActivityManagerService
的调用和TelephoneManager
的调用就是属于不同的调用类型(不同类型的IPC操作)
;调用堆栈
【哪行代码调用的】、发生线程
【IPC具体发生在哪个线程】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
将文件导出;PackageManagerService
的调用拿到应用的信息、get到群从设备标识符(GSID)的信息
、ActivityManagerService
的调用和TelephoneManager
的调用等都是有涉及到IPC操作
,
这样的操作其实都是有一个固定的调用方式,
即不管是通过那种IPC调用类型,
只要是IPC
操作,^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
最终都会调用到一个类android.os.BinderProxy
,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
然后它会调用其自身方法transact()
;
BinderProxy
是Binder
的内部类;
这里注意transact()
的几个参数!!!!!!!!:
compile 'me.weishu:epic:0.6.0'
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调用
的类型、调用耗时、发生次数、调用堆栈、发生的时刻
等。
随后便可以进行详细的分析,统筹优化;
参考: