Android 卡顿方案研究
Android 卡顿研究
[TOC]
稳定化，不是说说而已
基础概念
这里主要是根据张绍文老师的文章做的笔记，根据张绍文老师的文笔去实践具体卡顿监控的内容
散列知识点
- JVM中的线程切换大概花费CPU 20000个时钟周期
CPU
这里CPU需要单独搞出来提一下，卡顿优化前需要搞清楚CPU是什么，能干什么，正在干什么，然后才是“什么”这个区间里面应用程序此时的参数是否合理，优化的空间又是多少
查看一个CPU的参数需要看CPU的频率，核心等参数，具体参考 Wiki
这里就仅仅点相对重要的一些参数含义
-
时钟周期：CPU每秒可以完成几个时钟周期，如
可以完成这么多个时钟周期 -
机器周期：主存中读取一个指令字的最短时间（由于CPU内部的操作速度较快．而CPU访问一次主存所花的时间较长，因此机器周期通常用主存中读取一个指令字的最短时间来规定。），所以 机器周期 = 时钟周期 * n(n >= 1)
-
指令周期：完成一个指令需要的时间，一般由 几个或者一个机器周期组成，相当于 指令周期 = 机器周期 * n(n >= 1)
方法论
指标
- CPU使用率
adb查看CPU.png
如果 CPU 使用率长期大于 60% ，表示系统处于繁忙状态,就需要进一步分析用户时间和系统时间的比例。对于普通应用程序，系统时间不会长期高于 30%，如果超过这个值，就得考虑是否I/O调用过多或者锁调用的过于频繁的问题。利用Android Studio的profile也能查看CPU的使用率
- CPU饱和度
CPU 饱和度反映的是线程排队等待 CPU 的情况，也就是 CPU 的负载情况。
CPU 饱和度首先会跟应用的线程数有关，如果启动的线程过多，易导致系统不断地切换执行的线程，把大量的时间浪费在上下文切换,要知道每一次 CPU 上下文切换都需要刷新寄存器和计数器,至少需要几十纳秒的时间。
可以通过vmstat命令查看CPU上下文切换次数
proc/self/sched:
nr_voluntary_switches:主动上下文切换次数，因为线程无法获取资源导致上下文切换，最普遍的就是IO
nr_involuntary_switches:被动上下文切换次数，线程被系统强制调度导致上下文切换，例如大量线程在抢占CPU
se.statistics.iowait_count:IO 等待次数
se.statistics.iowait_sum:IO 等待时间
此外也可以通过 uptime 命令可以检查 CPU 在 1 分钟、5 分钟和 15 分钟内的平均负载。比如一个 4 核的 CPU，如果当前平均负载是 8，这意味着每个 CPU 上有一个线程在运行，还有一个线程在等待。一般平均负载建议控制在“0.7 × 核数”以内。
00:02:39 up 7 days, 46 min, 0 users,
load average: 13.91, 14.70, 14.32
另外一个会影响 CPU 饱和度的是线程优先级，线程优先级会影响 Android 系统的调度策略，它主要由 nice 和 cgroup 类型共同决定。nice 值越低，抢占 CPU 时间片的能力越强。当 CPU 空闲时，线程的优先级对执行效率的影响并不会特别明显，但在 CPU 繁忙的时候，线程调度会对执行效率有非常大的影响。
关于线程优先级，你需要注意是否存在高优先级的线程空等低优先级线程，例如主线程等待某个后台线程的锁。从应用程序的角度来看，无论是用户时间、系统时间，还是等待 CPU 的调度，都是程序运行花费的时间。
市场调研
Traceview 和 systrace 都是我们比较熟悉的排查卡顿的工具，从实现上这些工具分为两个流派。
第一个流派是 instrument。获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。
第二个流派是 sample。有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。
根据流派，对目前市场上的性能监控工具做一些调研和使用，包括但不限于官方提供的性能监控工具，如systrace，Matrix等，关于Android上Systrace的使用可以参考我之前写过的一个blog里面有提到过如何使用Android 性能优化
选择哪种工具，需要看具体的场景。如果需要分析 Native 代码的耗时，可以选择 Simpleperf；如果想分析系统调用，可以选择 systrace；如果想分析整个程序执行流程的耗时，可以选择 Traceview 或者插桩版本的 systrace。
对目前市场上的一些性能监控框架做基本调研，如DoraemonKit，Matrix，BlockCanary
BlockCanary & DoraemonKit
这里之所以把两个都放到一起，是因为滴滴的哆啦A梦的卡顿检测其实就是blockCanary，实现很简单，但是思路很巧妙~
想要检测卡顿，其实就是检测主线程的运行情况，为什么这么说呢，因为每一帧渲染数据的创建，就依托于主线程来创建，而想要保证每一帧CPU都能在16.7ms内（这里仅限于60帧这种情况，如果是90或者120，可以反推的哈~）完成工作，这样就不会出现丢帧的现象，也就不会造成卡顿，而我们就监测每个而如何监测主线程的运行情况呢？这里需要知道安卓中的handler机制，通过检测每次处理主线程消息的耗时情况，就能够知道是否产生了卡顿，而在发生卡顿的时候，同时抓取此时主线程的堆栈，那么就更能方便的定位到需要优化的代码。
BlockCanary核心的地方，主要分为两个部分：
- 检测handleMessage
- 主线程抓取堆栈的部分
handleMessage
在主线程Looper每次处理消息的过程中，通过hook主线程Looper每次处理消息的过程，在处理消息之前记录一个时间戳，处理完消息之后记录一个时间戳，那么两个时间的差值，就是处理一条消息所花费的时间。通过给这个时间设置阈值，如：处理时间 > 阈值时间（430ms > 200ms）那么就认为是发生了卡顿
Looper处理消息.png
这里的hook其实非常简单，因为framework给咱们预留了这样的口子，可以看下在handlemessage这里的源码：
public void loop(){
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
......
final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
final long dispatchEnd;
try {
msg.target.dispatchMessage(msg);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
msg.recycleUnchecked();
}
}
......
/**
* Control logging of messages as they are processed by this Looper. If
* enabled, a log message will be written to <var>printer</var>
* at the beginning and ending of each message dispatch, identifying the
* target Handler and message contents.
*
* @param printer A Printer object that will receive log messages, or
* null to disable message logging.
*/
public void setMessageLogging(@Nullable Printer printer) {
mLogging = printer;
}
可见们只需要手动调用Looper.setMessageLogging方法就能给线程looper对象设置printer对象，在每次处理消息的时候，通过监听printer的println回调，解析出内容，就能知道知道分发消息的开始和结束了
//Printer 接口
public interface Printer {
/**
* Write a line of text to the output. There is no need to terminate
* the given string with a newline.
*/
void println(String x);
}
通过过滤printer.println打印的内容，判断是否是在消息分发处理相关的内容，然后进行时间差的计算，来判断卡顿是否发生
//LooperPrinter
class LooperPrinter implements Printer {
public Printer origin;
boolean isHasChecked = false;
boolean isValid = false;
LooperPrinter(Printer printer) {
this.origin = printer;
}
@Override
public void println(String x) {
if (null != origin) {
origin.println(x);
if (origin == this) {
throw new RuntimeException(MonitorConstants.LOG_TAG + " origin == this");
}
}
if (!isHasChecked) {
isValid = x.charAt(0) == '>' || x.charAt(0) == '<';
isHasChecked = true;
if (!isValid) {
InsectLogger.ne("[println] Printer is inValid! x:%s", x);
}
}
if (isValid) {
dispatch(x.charAt(0) == '>', x);
}
}
}
那么依据主线程卡顿的监控就已经完成了，接下来是对于卡顿问题的定位，也就是对主线程堆栈的抓取
dumpStack
这里不完全参照blockCanary的实现，但是大家都是为了解决能够抓取到问题发生的堆栈，这里先说一下对于主线程堆栈dump需要关注的问题。不同的抓取策略也是为了解决这个问题，此处先不考虑对性能带来的影响
假设此时发生了卡顿，那么在调用getStackTrace的时候，这时候虚拟机中所跟踪的堆栈中会把当前记录的一些堆栈返回。通过在发生卡顿的时候，dump出当前的堆栈，记录下来，再追溯问题的时候直接看存储下来的堆栈信息，那么定位问题就会方便很多，而实际情况下并不能如此理想，因为从VM中取出的堆栈dalvik.system.VMStack#getThreadStackTrace返回的数据是未知的，不能保证里面到底有多少内容，可能只有一部分，这样就可能会遗漏真正的问题所在，可以参考下图~
函数执行火图?.png
可以看到真正有问题的函数其实是FunctionA-1，而如果捞出来的堆栈只有FunctionA-2或者A-3的话，当然可以优化A-3，但是会漏掉真正发生问题的函数。所以对于堆栈的抓取，基于VMStack抓取堆栈的方式下，笔者思考了两种方案来解决这样的问题，这两种应该也是市面上基于VMStack方式的大概方案，再深入往VM中去研究感觉可以有，但是不推荐，因为成本高，且回报的话不太会有预期中的高。
周期性Dump
通过每个一段时间从VM中获取主线程的堆栈，在发生卡顿的时候，过滤出时间，然后直接取出这段时间内的堆栈来进行问题排查。
周期Dmp.png
在实现的时候需要注意的一些小细节：
- 循环队列
- 堆栈去重
- 时间区间筛选
起止Dump
这里可以“忽略”多线程的特性，因为我们关注的仅仅是主线程，那么只需要在消息分发之初dump一次堆栈，然后再消息处理之后再dump一次堆栈，这样既能在dump出来的堆栈中发现可能存在的问题，同时又能自行推断这中间的执行过程来观测代码中出现的问题。当然不可缺少一个代码耗时检测的小工具~
起止Dmp.png
Matrix
关于matrix解剖，需要先了解定义，再根据具体代码进行分析，最后根据代码梳理出实现的思路
卡顿定义
微信开发者对于卡顿的定义，很简单，很清晰，很明了，这里就cv过来了，一定要仔细读对卡顿的定义
什么是卡顿，很多人能马上联系到的是帧率 FPS (每秒显示帧数)。那么多低的 FPS 才是卡顿呢？又或者低 FPS 真的就是卡顿吗？（以下 FPS 默认指平均帧率）
其实并非如此，举个例子，游戏玩家通常追求更流畅的游戏画面体验一般要达到 60FPS 以上，但我们平时看到的大部分电影或视频 FPS 其实不高，一般只有 25FPS ~ 30FPS，而实际上我们也没有觉得卡顿。 在人眼结构上看，当一组动作在 1 秒内有 12 次变化（即 12FPS），我们会认为这组动作是连贯的；而当大于 60FPS 时，人眼很难区分出来明显的变化，所以 60FPS 也一直作为业界衡量一个界面流畅程度的重要指标。一个稳定在 30FPS 的动画，我们不会认为是卡顿的，但一旦 FPS 很不稳定，人眼往往容易感知到。
FPS 低并不意味着卡顿发生，而卡顿发生 FPS 一定不高。 FPS 可以衡量一个界面的流程性，但往往不能很直观的衡量卡顿的发生，这里有另一个指标（掉帧程度）可以更直观地衡量卡顿。
什么是掉帧（跳帧）？ 按照理想帧率 60FPS 这个指标，计算出平均每一帧的准备时间有 1000ms/60 = 16.6667ms，如果一帧的准备时间超出这个值，则认为发生掉帧，超出的时间越长，掉帧程度越严重。假设每帧准备时间约 32ms，每次只掉一帧，那么 1 秒内实际只刷新 30 帧，即平均帧率只有 30FPS，但这时往往不会觉得是卡顿。反而如果出现某次严重掉帧（>300ms），那么这一次的变化，通常很容易感知到。所以界面的掉帧程度，往往可以更直观的反映出卡顿。
流畅性
综上所述，其实可以明白对于卡顿的定义，衡量流畅性的指标可以简单理解为：
- 在用户有操作的前提下
- 平均掉帧率，只有在某一时刻发生的掉帧情况远远大于其他时刻，那么才界定为卡顿，这也是上面说到的界面的掉帧程度，才更直观的反映出卡顿
| Best | Normal | Middle | High | Frozen |
|---|---|---|---|---|
| [0:3) | [3:9) | [9:24) | [24:42) | [42:∞) |
Code实现
关于反射 Choreographer 来做到如何监测用户触发后开始计算平均帧率
关于Choreographer的知识相关，这里不做赘述，只根据实现原理来对使用的地方做说明
- 用户触发刷新
了解下源码中callbackType的含义
/**
* Callback type: Input callback. Runs first.
* @hide
*/
public static final int CALLBACK_INPUT = 0;
/**
* Callback type: Animation callback. Runs before traversals.
* @hide
*/
@TestApi
public static final int CALLBACK_ANIMATION = 1;
/**
* Callback type: Traversal callback. Handles layout and draw. Runs
* after all other asynchronous messages have been handled.
* @hide
*/
public static final int CALLBACK_TRAVERSAL = 2;
显而易见，CALLBACK_INPUT都已经注释好了，首先run的是这个类型的回调，然后我们平时注册的又是什么样子呢？
/**
* Posts a frame callback to run on the next frame.
* <p>
* The callback runs once then is automatically removed.
* </p>
*
* @param callback The frame callback to run during the next frame.
*
* @see #postFrameCallbackDelayed
* @see #removeFrameCallback
*/
public void postFrameCallback(FrameCallback callback) {
postFrameCallbackDelayed(callback, 0);
}
/**
* Posts a frame callback to run on the next frame after the specified delay.
* <p>
* The callback runs once then is automatically removed.
* </p>
*
* @param callback The frame callback to run during the next frame.
* @param delayMillis The delay time in milliseconds.
*
* @see #postFrameCallback
* @see #removeFrameCallback
*/
public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
if (callback == null) {
throw new IllegalArgumentException("callback must not be null");
}
postCallbackDelayedInternal(CALLBACK_ANIMATION,
callback, FRAME_CALLBACK_TOKEN, delayMillis);
}
注册类型的callbackType为ANIMATION的，而ANIMATION的type又是什么时候回调呢？
void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
......
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);
//优先执行CALLBACK_INPUT类型链表里面的回调
mFrameInfo.markInputHandlingStart();
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
mFrameInfo.markAnimationsStart();
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
mFrameInfo.markPerformTraversalsStart();
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
} finally {
AnimationUtils.unlockAnimationClock();
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
......
}
可见是在执行完优先级最高的输入类型的回调才会回调ANIMATION的（注意这里提供的两个参数，第一个是执行该frame的时间戳，第二个是当前帧号，是native调用，在DisplayEventReceiver事件中收到后维护的一个成员变量，具体实现类也在Choreagrapher中），而显然不能够符合我们的要求，我们是期望在用户有操作的情况下是否发生丢帧情况
Choreographer类结构.png
而如何计算input时机的帧率呢？ 势必需要在input类型中添加自己实现的callback，在animation开始的执行的时候，标识为input执行结束
Hook时机.png
好了，原理分析完毕，接下来看一下在Matrix中带佬如何实现的，核心类主要是com.tencent.matrix.trace.core.UIThreadMonitor
初始化中先拿到需要hook的方法，然后模拟顺序进行执行
public void init(TraceConfig config) {
......
//反射同步锁对象和对应doFrame的所有回调数组链表对象
choreographer = Choreographer.getInstance();
callbackQueueLock = reflectObject(choreographer, "mLock");
callbackQueues = reflectObject(choreographer, "mCallbackQueues");
//先拿到添加对应回调的可执行反射方法
addInputQueue = reflectChoreographerMethod(callbackQueues[CALLBACK_INPUT], ADD_CALLBACK, long.class, Object.class, Object.class);
addAnimationQueue = reflectChoreographerMethod(callbackQueues[CALLBACK_ANIMATION], ADD_CALLBACK, long.class, Object.class, Object.class);
addTraversalQueue = reflectChoreographerMethod(callbackQueues[CALLBACK_TRAVERSAL], ADD_CALLBACK, long.class, Object.class, Object.class);
frameIntervalNanos = reflectObject(choreographer, "mFrameIntervalNanos");
......
this.isInit = true;
......
}
通过上面分析可得，doframe的回调执行是顺序执行下来，也就是说一个类型的callback执行结束时间，就是下一个类型的开始时间，那么在addCallback的时机也是如此，最开始要添加的则是input类型回调
public void init(TraceConfig config) {
......
choreographer = Choreographer.getInstance();
callbackQueueLock = ReflectUtils.reflectObject(choreographer, "mLock", new Object());
//反射获取回调的数组链表对象，可以理解为单object的hashMap 数组+链表实现
callbackQueues = ReflectUtils.reflectObject(choreographer, "mCallbackQueues", null);
if (null != callbackQueues) {
addInputQueue = ReflectUtils.reflectMethod(callbackQueues[CALLBACK_INPUT], ADD_CALLBACK, long.class, Object.class, Object.class);
addAnimationQueue = ReflectUtils.reflectMethod(callbackQueues[CALLBACK_ANIMATION], ADD_CALLBACK, long.class, Object.class, Object.class);
addTraversalQueue = ReflectUtils.reflectMethod(callbackQueues[CALLBACK_TRAVERSAL], ADD_CALLBACK, long.class, Object.class, Object.class);
}
//主要是拿vsync回调上来的信号开始绘制的时间戳，可以分析出来丢帧数，源码也是这么干的
vsyncReceiver = ReflectUtils.reflectObject(choreographer, "mDisplayEventReceiver", null);
//产生vsync信号的时间戳
frameIntervalNanos = ReflectUtils.reflectObject(choreographer, "mFrameIntervalNanos", Constants.DEFAULT_FRAME_DURATION);
LooperMonitor.register(new LooperMonitor.LooperDispatchListener() {
@Override
public boolean isValid() {
return isAlive;
}
@Override
public void dispatchStart() {
super.dispatchStart();
UIThreadMonitor.this.dispatchBegin();
}
@Override
public void dispatchEnd() {
super.dispatchEnd();
UIThreadMonitor.this.dispatchEnd();
}
});
......
}
public synchronized void onStart() {
......
if (!isAlive) {
this.isAlive = true;
synchronized (this) {
MatrixLog.i(TAG, "[onStart] callbackExist:%s %s", Arrays.toString(callbackExist), Utils.getStack());
callbackExist = new boolean[CALLBACK_LAST + 1];
}
//为三种callback增加状态维护数组
queueStatus = new int[CALLBACK_LAST + 1];
//为三种callback增加耗时数组
queueCost = new long[CALLBACK_LAST + 1];
//首次添加input类型callback
addFrameCallback(CALLBACK_INPUT, this, true);
}
}
可以看到，在添加input类型的回调时，传的是自己，那么来分析一下接下来的run实现
@Override
public void run() {
//来自vsync信号开始
doFrameBegin(token);
//维护input类型数组们的状态
doQueueBegin(CALLBACK_INPUT);
//animation回调注册回调
addFrameCallback(CALLBACK_ANIMATION, new Runnable() {
@Override
public void run() {
//animation回调，input结束
doQueueEnd(CALLBACK_INPUT);
doQueueBegin(CALLBACK_ANIMATION);
}
}, true);
addFrameCallback(CALLBACK_TRAVERSAL, new Runnable() {
@Override
public void run() {
//traversal类型回调，animation结束
doQueueEnd(CALLBACK_ANIMATION);
doQueueBegin(CALLBACK_TRAVERSAL);
}
}, true);
}
可以看到，如此就能得到一个Vsync信号过来的轮回，但是走到这里只能完成一次，matrix如何把每一次串起来的咧？
还记得上面初始化的时候注册looper监听，每次消息的处理开始和结束都会激活一次dispatchStart和dispatchEnd，start这里就不分析了，其实就是往外回调，主要是end
private void dispatchEnd() {
......
//在第一次Vsync开始的时候赋值为true，直接进来
if (isVsyncFrame) {
doFrameEnd(token);
intendedFrameTimeNs = getIntendedFrameTimeNs(startNs);
}
......
//来自一次vsync信号结束
this.isVsyncFrame = false;
}
private void doFrameEnd(long token) {
//下一次input开始，上一次的traversal结束
doQueueEnd(CALLBACK_TRAVERSAL);
......
//开启下一次input轮回
addFrameCallback(CALLBACK_INPUT, this, true);
}
可以看到，这里才是真正的结束，一个完整的Choreographer循环~
卡顿策略
Matrix的文档里面已经非常清楚的用文字描述一个卡顿是如何产生的，以及卡顿的定义
FPS 低并不意味着卡顿发生，而卡顿发生 FPS 一定不高。 FPS 可以衡量一个界面的流程性，但往往不能很直观的衡量卡顿的发生，这里有另一个指标（掉帧程度）可以更直观地衡量卡顿。
什么是掉帧（跳帧）？ 按照理想帧率 60FPS 这个指标，计算出平均每一帧的准备时间有 1000ms/60 = 16.6667ms，如果一帧的准备时间超出这个值，则认为发生掉帧，超出的时间越长，掉帧程度越严重。假设每帧准备时间约 32ms，每次只掉一帧，那么 1 秒内实际只刷新 30 帧，即平均帧率只有 30FPS，但这时往往不会觉得是卡顿。反而如果出现某次严重掉帧（>300ms），那么这一次的变化，通常很容易感知到。所以界面的掉帧程度，往往可以更直观的反映出卡顿。
然后分析下关于瞬时平均帧率的代码需要重点关注的就是com.tencent.matrix.trace.tracer.FrameTracer这个类
在每一次doFrame的回调中去分析这个参数
@Override
public void doFrame(String focusedActivity, long startNs, long endNs, boolean isVsyncFrame, long intendedFrameTimeNs, long inputCostNs, long animationCostNs, long traversalCostNs) {
if (isForeground()) {
notifyListener(focusedActivity, startNs, endNs, isVsyncFrame, intendedFrameTimeNs, inputCostNs, animationCostNs, traversalCostNs);
}
}
private void notifyListener(final String focusedActivity, final long startNs, final long endNs, final boolean isVsyncFrame,
final long intendedFrameTimeNs, final long inputCostNs, final long animationCostNs, final long traversalCostNs) {
try {
//计算丢帧，跟源码的计算方式一致，上一个版本局部变量的声明并没有如此直观，这个版本改了，清爽许多
final long jiter = endNs - intendedFrameTimeNs;
final int dropFrame = (int) (jiter / frameIntervalNs);
synchronized (listeners) {
//listeners目前注册进来的就俩，一个内部类FPSCollect，一个用于UI展示的FrameDecorator
for (final IDoFrameListener listener : listeners) {
if (config.isDevEnv()) {
listener.time = SystemClock.uptimeMillis();
}
if (null != listener.getExecutor()) {
if (listener.getIntervalFrameReplay() > 0) {
//数据收集部分
listener.collect(focusedActivity, startNs, endNs, dropFrame, isVsyncFrame,
intendedFrameTimeNs, inputCostNs, animationCostNs, traversalCostNs);
} else {
//卡顿分析部分
listener.getExecutor().execute(new Runnable() {
@Override
public void run() {
listener.doFrameAsync(focusedActivity, startNs, endNs, dropFrame, isVsyncFrame,
intendedFrameTimeNs, inputCostNs, animationCostNs, traversalCostNs);
}
});
}
} else {
listener.doFrameSync(focusedActivity, startNs, endNs, dropFrame, isVsyncFrame,
intendedFrameTimeNs, inputCostNs, animationCostNs, traversalCostNs);
}
}
}
} finally {
}
}
为什么说丢帧计算和源码一致呢？ 这里我们可以和源码对比一下：
final long jiter = endNs - intendedFrameTimeNs;
final int dropFrame = (int) (jiter / frameIntervalNs);
//源码 android.view.Choreographer#doFrame
final long jitterNanos = startNanos - frameTimeNanos;
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
Log.i(TAG, "Skipped " + skippedFrames + " frames! "
+ "The application may be doing too much work on its main thread.");
}
这么看上去，瞬间就友好了很多~
从注释里面也能看到，注册的俩监听，一个用于记录，一个用于展示，记录其实就是填充此时此刻的关于FPS的快照，没什么可看的，学习而言，展示的要好一些，因为他需要分析数据，然后展示到UI上，那么接下来就直接看下Matix中的com.tencent.matrix.trace.view.FrameDecorator#doFrameAsync，源码过长，这里就一步一步分析代码是如何体现上面的表和描述
计算出平均每一帧的准备时间有 1000ms/60 = 16.6667ms，如果一帧的准备时间超出这个值，则认为发生掉帧，超出的时间越长，掉帧程度越严重。假设每帧准备时间约 32ms，每次只掉一帧，那么 1 秒内实际只刷新 30 帧，即平均帧率只有 30FPS，但这时往往不会觉得是卡顿。反而如果出现某次严重掉帧（>300ms），那么这一次的变化，通常很容易感知到
Best Normal Middle High Frozen [0:3) [3:9) [9:24) [24:42) [42:∞)
/**
* 流畅指标，佳0，正常1，中等2，严重3，冻帧4
*/
public enum DropStatus {
DROPPED_FROZEN(4), DROPPED_HIGH(3), DROPPED_MIDDLE(2), DROPPED_NORMAL(1), DROPPED_BEST(0);
public int index;
DropStatus(int index) {
this.index = index;
}
}
在回调回来的函数中，分析流畅指标
卡顿分布数据.png
@Override
public void doFrameAsync(String focusedActivity, long startNs, long endNs, int dropFrame, boolean isVsyncFrame, long intendedFrameTimeNs, long inputCostNs, long animationCostNs, long traversalCostNs) {
super.doFrameAsync(focusedActivity, startNs, endNs, dropFrame, isVsyncFrame, intendedFrameTimeNs, inputCostNs, animationCostNs, traversalCostNs);
......
if (dropFrame >= Constants.DEFAULT_DROPPED_FROZEN) { //冻帧
dropLevel[FrameTracer.DropStatus.DROPPED_FROZEN.index]++;
sumDropLevel[FrameTracer.DropStatus.DROPPED_FROZEN.index]++;
} else if (dropFrame >= Constants.DEFAULT_DROPPED_HIGH) { //严重
dropLevel[FrameTracer.DropStatus.DROPPED_HIGH.index]++;
sumDropLevel[FrameTracer.DropStatus.DROPPED_HIGH.index]++;
} else if (dropFrame >= Constants.DEFAULT_DROPPED_MIDDLE) { //中等
dropLevel[FrameTracer.DropStatus.DROPPED_MIDDLE.index]++;
sumDropLevel[FrameTracer.DropStatus.DROPPED_MIDDLE.index]++;
} else if (dropFrame >= Constants.DEFAULT_DROPPED_NORMAL) { //正常
dropLevel[FrameTracer.DropStatus.DROPPED_NORMAL.index]++;
sumDropLevel[FrameTracer.DropStatus.DROPPED_NORMAL.index]++;
} else {
dropLevel[FrameTracer.DropStatus.DROPPED_BEST.index]++;
sumDropLevel[FrameTracer.DropStatus.DROPPED_BEST.index]++;
}
......
}
这里的代码非常简单，接下来是分析造成严重卡顿的情况，也就是严重丢帧的时候，也是文章中所分析的内容：
如果出现某次严重掉帧（>300ms），那么这一次的变化，通常很容易感知到
sumFrameCost += (dropFrame + 1) * frameIntervalMs;
sumFrames += 1;
float duration = sumFrameCost - lastCost[0];
long collectFrame = sumFrames - lastFrames[0];
if (duration >= 200) {
//更新视图
}
综上，就是Matrix中对页面流畅性分析的核心代码，而对于Matrix中精准命中堆栈则可以取自冻帧或者所谓的duration >= 200这个条件下dump一次主线程的堆栈来获取
慢函数
其实关于上述严重掉帧情况下的抓取堆栈的数量不多，同样避不开上面提到的漏掉其他耗时代码的情况，不过笔者认为这样的情况不会特别多，因为卡顿发生的时候，大概率避免不了正在执行一个耗时操作，那么这个耗时操作的堆栈出现在此刻dump出来的堆栈里面的可能性很大，所以Matrix干脆利落的出了一个慢函数检测，这样感觉就无孔不入了，对所有在主线程上运行的函数耗时进行收集，和BlockCanary检测卡顿的策略一样，但是堆栈的抓取就要复杂一些，这也是为什么Matrix性能更好的原因，能在灰度下上线的能力。同时也能有对应的聚合策略，这样结合后端的能力方便我们分析代码运行情况，然后做 “狭义” 上的优化，这里推荐一个在解决卡顿时候您可以用到的方法耗时小插件
Matrix中的慢函数和BlockCanary的卡顿堆栈获取时机和检测卡顿或者慢的策略一致，下面可以简单看下，关于Matrix中如何去捞堆栈的~
@Override
public void dispatchEnd(long beginNs, long cpuBeginMs, long endNs, long cpuEndMs, long token, boolean isVsyncFrame) {
super.dispatchEnd(beginNs, cpuBeginMs, endNs, cpuEndMs, token, isVsyncFrame);
long start = config.isDevEnv() ? System.currentTimeMillis() : 0;
long dispatchCost = (endNs - beginNs) / Constants.TIME_MILLIS_TO_NANO;
try {
//查过阈值，和BlockCanary一样com.tencent.matrix.trace.constants.Constants.DEFAULT_EVIL_METHOD_THRESHOLD_MS = 700
if (dispatchCost >= evilThresholdMs) {
long[] data = AppMethodBeat.getInstance().copyData(indexRecord);
long[] queueCosts = new long[3];
System.arraycopy(queueTypeCosts, 0, queueCosts, 0, 3);
//scene拿的是当前的activity
String scene = AppMethodBeat.getVisibleScene();
MatrixHandlerThread.getDefaultHandler().post(new AnalyseTask(isForeground(), scene, data, queueCosts, cpuEndMs - cpuBeginMs, dispatchCost, endNs / Constants.TIME_MILLIS_TO_NANO));
}
} finally {
indexRecord.release();
}
}
可以看到，慢函数的阈值是700ms，如果超出阈值，则会从AppMethod中拿取相关的堆栈数据，同时记录下当前的页面然后上传一波，那么关键的地方就在于这个
AppMethodBeat.getInstance().copyData(indexRecord)
关于Matrix的堆栈实现主要分为两块
- ASM插桩记录方法
- Java侧关于记录方法耗时以及方法记录的实现
编译期：
通过代理编译期间的任务 transformClassesWithDexTask，将全局 class 文件作为输入，利用 ASM 工具，高效地对所有 class 文件进行扫描及插桩。
插桩过程有几个关键点：
1、选择在该编译任务执行时插桩，是因为 proguard 操作是在该任务之前就完成的，意味着插桩时的 class 文件已经被混淆过的。而选择 proguard 之后去插桩，是因为如果提前插桩会造成部分方法不符合内联规则，没法在 proguard 时进行优化，最终导致程序方法数无法减少，从而引发方法数过大问题。
2、为了减少插桩量及性能损耗，通过遍历 class 方法指令集，判断扫描的函数是否只含有 PUT/READ FIELD 等简单的指令，来过滤一些默认或匿名构造函数，以及 get/set 等简单不耗时函数。
3、针对界面启动耗时，因为要统计从 Activity#onCreate 到 Activity#onWindowFocusChange 间的耗时，所以在插桩过程中需要收集应用内所有 Activity 的实现类，并覆盖 onWindowFocusChange 函数进行打点。
4、为了方便及高效记录函数执行过程，我们为每个插桩的函数分配一个独立 ID，在插桩过程中，记录插桩的函数签名及分配的 ID，在插桩完成后输出一份 mapping，作为数据上报后的解析支持。
插桩流程.png
下面重点介绍一下关于Matrix中对性能考量以及具体的业务插桩代码
- 编译优化，内联规则
选择在该编译任务执行时插桩，是因为 proguard 操作是在该任务之前就完成的，意味着插桩时的 class 文件已经被混淆过的。而选择 proguard 之后去插桩，是因为如果提前插桩会造成部分方法不符合内联规则，没法在 proguard 时进行优化，最终导致程序方法数无法减少，从而引发方法数过大问题。
解释一下什么叫做方法内联，说白了其实就是你写了两个方法，在编译时会将其中一个方法的实现直接放到调用的地方，这样就无需去走一遍调用其他方法，从而达到优化的目的，因为每个方法会生成一个栈帧，然后进行压栈出栈的操作，过程比较反复，这里用代码解释一下编译优化之一，方法内联：
//编译前，source.java
public int doubleNum(int num){
return num * 2;
}
public void method1(){
int a = 10;
int b = doubleNum(2);
System.out.println(String.format("a:%s, b:%s", a, b));
}
//编译后， source.class
public void method1(){
int a = 10;
int b = a * 2;//doubleNum(2);
System.out.println(String.format("a:%s, b:%s", a, b));
}
可以看到在编译之后就没有了doubleNum这个方法，在method1中调用的时候直接变成了 a * 2 ， 这样就无需在运行的过程中去对doubleNum压栈操作
虽然能保证proguard时候优化能正常进行，不过优化程度上来讲，笔者也没有统计过哈，也不晓得从哪里能够看到，因为目前在7.0之后，安装的时候会进行JIT和AOT混合的方式，这个结果应该不是很好看，在JIT选择编译热代码的时候，优化的那部分内联又该如何考虑呢？想想太复杂了。。。大家感兴趣的话可以统计下在打出来的release包中，可以看日志，优化的效果~
那接下里就是Matrix中如何做到在proguard的transform后进行插桩呢，核心工程是matrix-gradle-plugin
入口：
//com.tencent.matrix.plugin.MatrixPlugin#apply
/**
* <p>Adds a closure to be called immediately after this project has been evaluated. The project is passed to the
* closure as a parameter. Such a listener gets notified when the build file belonging to this project has been
* executed. A parent project may for example add such a listener to its child project. Such a listener can further
* configure those child projects based on the state of the child projects after their build files have been
* run.</p>
*
* @param closure The closure to call.
*/
void afterEvaluate(Closure closure);
@Override
void apply(Project project) {
......
//完成所有transform之后执行
project.afterEvaluate {
def android = project.extensions.android
def configuration = project.matrix
android.applicationVariants.all { variant ->
if (configuration.trace.enable) {
//代码插桩入口
MatrixTraceTransform.inject(project, configuration.trace, variant.getVariantData().getScope())
}
......
}
}
}
在afterEvaluate后传入闭包，开始插桩代码，为什么是这个时机，可以参考上面的源码注释哈~
接下来就是注入代码，因为不依赖于自定义的transformTask，Matrix的实现是通过往transformTask里面去注入执行事件，这里的写法也是个新姿势~
//com.tencent.matrix.trace.transform.MatrixTraceTransform#inject
public static void inject(Project project, MatrixTraceExtension extension, VariantScope variantScope) {
......
try {
String[] hardTask = getTransformTaskName(extension.getCustomDexTransformName(), variant.getName());
for (Task task : project.getTasks()) {
for (String str : hardTask) {
if (task.getName().equalsIgnoreCase(str) && task instanceof TransformTask) {
//如果确实是Transform的task后进来执行反射hook注入matrix的transform任务
TransformTask transformTask = (TransformTask) task;
Log.i(TAG, "successfully inject task:" + transformTask.getName());
Field field = TransformTask.class.getDeclaredField("transform");
field.setAccessible(true);
//这里就是注入自定义的任务，在编译执行的时候
field.set(task, new MatrixTraceTransform(config, transformTask.getTransform()));
break;
}
}
}
} catch (Exception e) {
Log.e(TAG, e.toString());
}
}
//源码中可以看到执行transformTask的时候调用这个注入的transform执行处，com.android.build.gradle.internal.pipeline.TransformTask#transform
@TaskAction
void transform(final IncrementalTaskInputs incrementalTaskInputs)
throws IOException, TransformException, InterruptedException {
......
ThreadRecorder.get().record(ExecutionType.TASK_TRANSFORM,
new Recorder.Block<Void>() {
@Override
public Void call() throws Exception {
//这里就是调用transform.transform的时机
transform.transform(new TransformInvocationBuilder(TransformTask.this)
.addInputs(consumedInputs.getValue())
.addReferencedInputs(referencedInputs.getValue())
.addSecondaryInputs(changedSecondaryInputs.getValue())
.addOutputProvider(outputStream != null
? outputStream.asOutput()
: null)
.setIncrementalMode(isIncremental.getValue())
.build());
return null;
}
},
new Recorder.Property("project", getProject().getName()),
new Recorder.Property("transform", transform.getName()),
new Recorder.Property("incremental", Boolean.toString(transform.isIncremental())));
}
[手动表情秒啊~]，简直了。。。 不愧是微信的带佬，如果不是对编译任务的task有一定了解的话，要做到这里感觉不太可能。。。 不过还好能站在巨人的肩膀上~
这里注意下关于MatrixTraceTransform的构造，这里也是一个优秀的细节处理，虽然hook了系统transform的task，但是不会扔弃系统的transformTask，而是会传递进来，接下来在代码中分析这个伪代理的使用~
@Override
public void transform(TransformInvocation transformInvocation) throws TransformException, InterruptedException, IOException {
super.transform(transformInvocation);
long start = System.currentTimeMillis();
try {
//在执行系统的transform之前，执行自己的transform
doTransform(transformInvocation); // hack
} catch (ExecutionException e) {
e.printStackTrace();
}
long cost = System.currentTimeMillis() - start;
long begin = System.currentTimeMillis();
//ok 接下来，执行系统原来内置的orignTransformTask， 优秀的细节，不过貌似也只能这么干，可以考虑到卡顿hook looer中printer的时候也可以这么干~
origTransform.transform(transformInvocation);
}
最后就是插桩的核心代码了，这里分为两个部分来进行介绍，一个是如何过滤简单方法，一个是插桩细节
- 过滤简单方法
- 插桩
matrix编译工作.png
总的来说，流程也比较简单，整个方法分为三个过程
首先解析mapping文件，毕竟是对混淆过的代码插桩，这里要能知道自己到底插的哪个方法
然后是收集要插桩的方法，就是过滤，过滤黑名单中不需要插桩的类或者方法
对收集后的方法开始插桩
精简一下代码：
//com.tencent.matrix.trace.transform.MatrixTraceTransform#doTransform
private void doTransform(TransformInvocation transformInvocation) throws ExecutionException, InterruptedException {
final boolean isIncremental = transformInvocation.isIncremental() && this.isIncremental();
/**
* step 1 把编译后的mapping文件对应的混淆方法关系记录下来，如：a() -> onCreate()
*/
List<Future> futures = new LinkedList<>();
//...干掉乱八七糟的代码干掉哈，主要就是生成方法id，然后解析~
//拿到需要查找的类文件
for (TransformInput input : inputs) {
for (DirectoryInput directoryInput : input.getDirectoryInputs()) {
futures.add(executor.submit(new CollectDirectoryInputTask(dirInputOutMap, directoryInput, isIncremental)));
}
for (JarInput inputJar : input.getJarInputs()) {
futures.add(executor.submit(new CollectJarInputTask(inputJar, isIncremental, jarInputOutMap, dirInputOutMap)));
}
}
//这里调用get方法就是执行
for (Future future : futures) {
future.get();
}
futures.clear();
/**
* step 2 这里就是收集下来需要进行插桩的方法，过滤出来黑名单或者是简单方法，这些方法不需要插桩~ 这里这个判断再一次[手动秒啊~]
*/
MethodCollector methodCollector = new MethodCollector(executor, mappingCollector, methodId, config, collectedMethodMap);
methodCollector.collect(dirInputOutMap.keySet(), jarInputOutMap.keySet());
/**
* step 3 对收集的方法进行插桩~
*/
MethodTracer methodTracer = new MethodTracer(executor, mappingCollector, config, methodCollector.getCollectedMethodMap(), methodCollector.getCollectedClassExtendMap());
methodTracer.trace(dirInputOutMap, jarInputOutMap);
}
mapping的解析就是工作量问题，我们可以看下输入结果：
1,1,sample.tencent.matrix.listener.TestPluginListener <init> (Landroid.content.Context;)V
2,0,sample.tencent.matrix.trace.TestFpsActivity$4 <init> (Lsample.tencent.matrix.trace.TestFpsActivity;Landroid.content.Context;I[Ljava.lang.Object;)V
3,1,sample.tencent.matrix.trace.TestTraceFragmentActivity <init> ()V
4,1,sample.tencent.matrix.trace.TestTraceFragmentActivity$2 onClick (Landroid.view.View;)V
5,1,sample.tencent.matrix.listener.TestPluginListener onReportIssue (Lcom.tencent.matrix.report.Issue;)V
然后分析函数是否简单的地方，先看一下文档中的定义
为了减少插桩量及性能损耗，通过遍历 class 方法指令集，判断扫描的函数是否只含有 PUT/READ FIELD 等简单的指令，来过滤一些默认或匿名构造函数，以及 get/set 等简单不耗时函数。
简单方法过滤
内部获取方法同样利用ASM那一套逻辑，上面介绍耗时插件已经介绍过了哈~
可以重点关注核心代码：
//com.tencent.matrix.trace.MethodCollector.TraceClassAdapter#visitMethod
@Override
public MethodVisitor visitMethod(int access, String name, String desc,
String signature, String[] exceptions) {
//抽象类不做处理
if (isABSClass) {
return super.visitMethod(access, name, desc, signature, exceptions);
} else {
//判断该方法是不是onWindowFocus
if (!hasWindowFocusMethod) {
hasWindowFocusMethod = isWindowFocusChangeMethod(name, desc);
}
//真正核心处理过滤逻辑
return new CollectMethodNode(className, access, name, desc, signature, exceptions);
}
}
//com.tencent.matrix.trace.MethodCollector.CollectMethodNode#visitEnd
@Override
public void visitEnd() {
super.visitEnd();
TraceMethod traceMethod = TraceMethod.create(0, access, className, name, desc);
if ("<init>".equals(name)) {
isConstructor = true;
}
//判断是否是黑名单里面的，这里和黑名单中进行了互斥，在插桩中也会判断
//所以可以不用在意这个细节，说白了就是判断这个方法不在黑名单中而已
boolean isNeedTrace = isNeedTrace(configuration, traceMethod.className, mappingCollector);
// filter simple methods 这里就是过滤简单方法，我们重点关注这里
if ((isEmptyMethod() || isGetSetMethod() || isSingleMethod())
&& isNeedTrace) {
ignoreCount.incrementAndGet();
collectedIgnoreMethodMap.put(traceMethod.getMethodName(), traceMethod);
return;
}
......
}
上面截取出来的额低吗可见端倪，一个是判断构造方法，然后就是isEmptyMethod，isGetSetMethod，isSingleMethod，接下来就分析下这个所谓的过滤简单方法到底🐂🍺与否
//com.tencent.matrix.trace.MethodCollector.CollectMethodNode#isEmptyMethod
/**
* 检测空方法，不知道这里为什么这么写。。。反正我验证这个方法基本没有用
* -1 是F_NEW指令，不应该是判断return指令么？
*
* @return
*/
private boolean isEmptyMethod() {
ListIterator<AbstractInsnNode> iterator = instructions.iterator();
while (iterator.hasNext()) {
//逻辑就是过滤掉是new指令？ 说白了就是如果指令集不为空，就不是空方法
AbstractInsnNode insnNode = iterator.next();
int opcode = insnNode.getOpcode();
//-1对应的opcode是NEW这个指令
if (-1 == opcode) {
continue;
} else {
return false;
}
}
return true;
}
/*
这里是空方法反编译后的字节码
public void logClueMethod();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=0, locals=1, args_size=1
0: return
LineNumberTable:
line 22: 0
LocalVariableTable:
Start Length Slot Name Signature
0 1 0 this Lcom/done/testlibrary/Utils;
*/
首先空方法的判断不够牛批哈~
接下来看第二个isGetSetMethod，
private boolean isGetSetMethod() {
int ignoreCount = 0;
ListIterator<AbstractInsnNode> iterator = instructions.iterator();
while (iterator.hasNext()) {
AbstractInsnNode insnNode = iterator.next();
int opcode = insnNode.getOpcode();
if (-1 == opcode) {
continue;
}
if (opcode != Opcodes.GETFIELD
&& opcode != Opcodes.GETSTATIC
&& opcode != Opcodes.H_GETFIELD
&& opcode != Opcodes.H_GETSTATIC
&& opcode != Opcodes.RETURN
&& opcode != Opcodes.ARETURN
&& opcode != Opcodes.DRETURN
&& opcode != Opcodes.FRETURN
&& opcode != Opcodes.LRETURN
&& opcode != Opcodes.IRETURN
&& opcode != Opcodes.PUTFIELD
&& opcode != Opcodes.PUTSTATIC
&& opcode != Opcodes.H_PUTFIELD
&& opcode != Opcodes.H_PUTSTATIC
&& opcode > Opcodes.SALOAD) {
if (isConstructor && opcode == Opcodes.INVOKESPECIAL) {
ignoreCount++;
if (ignoreCount > 1) {
return false;
}
continue;
}
return false;
}
}
return true;
}
最后是判断是不是简单方法
private boolean isSingleMethod() {
ListIterator<AbstractInsnNode> iterator = instructions.iterator();
while (iterator.hasNext()) {
AbstractInsnNode insnNode = iterator.next();
int opcode = insnNode.getOpcode();
if (-1 == opcode) {
continue;
//出现这个指令区间内，都标识调用了其他方法，会出现压栈的情况
// 调用了别的方法，自然就不是简单的方法，不过这里没有判断指令的数量，感觉也不是一定可靠
} else if (Opcodes.INVOKEVIRTUAL <= opcode && opcode <= Opcodes.INVOKEDYNAMIC) {
return false;
}
}
return true;
}
三个过滤的函数都看完了，感觉不一定可取，可以借鉴和参考，但不一定准，可能是在下没有严谨的编译看吧。。。不过有这种思路也还好，可以自己定义所谓的简单方法吧~
插桩代码
这里只简单看一下插桩的代码，具体计算耗时的功能逻辑实现后面会继续介绍，那部分也不在plugin的工程中~
3、针对界面启动耗时，因为要统计从 Activity#onCreate 到 Activity#onWindowFocusChange 间的耗时，所以在插桩过程中需要收集应用内所有 Activity 的实现类，并覆盖 onWindowFocusChange 函数进行打点。
4、为了方便及高效记录函数执行过程，我们为每个插桩的函数分配一个独立 ID，在插桩过程中，记录插桩的函数签名及分配的 ID，在插桩完成后输出一份 mapping，作为数据上报后的解析支持。
插桩对外的类是com.tencent.matrix.trace.MethodTracer，这里就简单看一个插桩source代码的，因为到最后不管是jar还是source，可都是对class文件进行处理~
//com.tencent.matrix.trace.MethodTracer#innerTraceMethodFromSrc
private void innerTraceMethodFromSrc(File input, File output) {
ArrayList<File> classFileList = new ArrayList<>();
if (input.isDirectory()) {
listClassFiles(classFileList, input);
} else {
classFileList.add(input);
}
for (File classFile : classFileList) {
InputStream is = null;
FileOutputStream os = null;
try {
......
if (MethodCollector.isNeedTraceFile(classFile.getName())) {
is = new FileInputStream(classFile);
ClassReader classReader = new ClassReader(is);
ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_MAXS);
//关注这里插桩访问者访问类，然后里面插桩
ClassVisitor classVisitor = new TraceClassAdapter(Opcodes.ASM5, classWriter);
//调用这里后开始插桩
classReader.accept(classVisitor, ClassReader.EXPAND_FRAMES);
......
} else {
FileUtil.copyFileUsingStream(classFile, changedFileOutput);
}
} catch (Exception e) {
......
} finally {
.......
}
}
}
代码里面关键的实现还是asm的classVisitor，我们只需要关注这里面的实现即可~
这里由于封装的路径还是有个两三层，我就简单说下调用关系，这里代码咱们还是看核心实现哈~
//com.tencent.matrix.trace.MethodTracer.TraceMethodAdapter
//1. 调用com.tencent.matrix.trace.MethodTracer.TraceClassAdapter#visitMethod
//2. 调用com.tencent.matrix.trace.MethodTracer.TraceMethodAdapter#TraceMethodAdapter
//3. 利用AdviceAdapter的方法进入和退出回调插桩
public final static String MATRIX_TRACE_CLASS = "com/tencent/matrix/trace/core/AppMethodBeat";
@Override
protected void onMethodEnter() {
//这里的插桩结果就是在方法进入的时候插入 AppMethodBeat.i(methodid);
TraceMethod traceMethod = collectedMethodMap.get(methodName);
if (traceMethod != null) {
traceMethodCount.incrementAndGet();
mv.visitLdcInsn(traceMethod.id);
mv.visitMethodInsn(INVOKESTATIC, TraceBuildConstants.MATRIX_TRACE_CLASS, "i", "(I)V", false);
}
}
@Override
protected void onMethodExit(int opcode) {
//方法退出的插桩有判断逻辑
TraceMethod traceMethod = collectedMethodMap.get(methodName);
if (traceMethod != null) {
if (hasWindowFocusMethod && isActivityOrSubClass && isNeedTrace) {
TraceMethod windowFocusChangeMethod = TraceMethod.create(-1, Opcodes.ACC_PUBLIC, className,
TraceBuildConstants.MATRIX_TRACE_ON_WINDOW_FOCUS_METHOD, TraceBuildConstants.MATRIX_TRACE_ON_WINDOW_FOCUS_METHOD_ARGS);
if (windowFocusChangeMethod.equals(traceMethod)) {
//如果是onWindowFocusChanged，那么还会插入AppMethodBeat.at(activity, isFocus)
traceWindowFocusChangeMethod(mv, className);
}
}
//无论是不是 onWindowFocusChanged，都会插入AppMethodBeat.o(methodid);
traceMethodCount.incrementAndGet();
mv.visitLdcInsn(traceMethod.id);
mv.visitMethodInsn(INVOKESTATIC, TraceBuildConstants.MATRIX_TRACE_CLASS, "o", "(I)V", false);
}
}
插装部分就是纯工作量的事情了，有了前面的判断和过滤逻辑，这里就非常简单，主要插入 i 方法和 o 方法就行具体可以看上面的代码注释 多余的这里就不展开去看代码了
JavaLib AppMethodBeat 实现
上面就是trace插件在编译时所做的工作，可以看到插桩时期丝毫没有进行任何系统方法的调用，如：SystemClock.time或者System.nanoTime这些获取时间戳的native方法，这样可以理解为一个小优化的点~不通过系统方法获取时间，matrix利用很巧妙的方式来获取时间
考虑到每个方法执行前后都获取系统时间（System.nanoTime）会对性能影响比较大，而实际上，单个函数执行耗时小于 5ms 的情况，对卡顿来说不是主要原因，可以忽略不计，如果是多次调用的情况，则在它的父级方法中可以反映出来，所以为了减少对性能的影响，通过另一条更新时间的线程每 5ms 去更新一个时间变量，而每个方法执行前后只读取该变量来减少性能损耗。
具体就在java lib中去实现，下面我们就分析下java中的实现，其实上面插桩的时候就已经知道具体的实现的核心类是哪个了 => com.tencent.matrix.trace.core.AppMethodBeat
这个类的逻辑还是有一小丢丢绕，因为其中不仅仅包含了计算方法耗时，还兼顾了查看生命周期相关的，包括activity、service的生命周期，目测了下，contentProvider的还没完成，感兴趣的同学可以具体查看下内部关于hook mH相关的代码，这里就贴一下关键性的代码哈~
//com.tencent.matrix.trace.hacker.ActivityThreadHacker#hackSysHandlerCallback
public static void hackSysHandlerCallback() {
try {
Class<?> forName = Class.forName("android.app.ActivityThread");
Field field = forName.getDeclaredField("sCurrentActivityThread");
field.setAccessible(true);
Object activityThreadValue = field.get(forName);
//hook mH这个handler
Field mH = forName.getDeclaredField("mH");
mH.setAccessible(true);
Object handler = mH.get(activityThreadValue);
Class<?> handlerClass = handler.getClass().getSuperclass();
if (null != handlerClass) {
//接着hook系统的callback，方便内部调用从而不影响系统调动过程
Field callbackField = handlerClass.getDeclaredField("mCallback");
callbackField.setAccessible(true);
Handler.Callback originalCallback = (Handler.Callback) callbackField.get(handler);
HackCallback callback = new HackCallback(originalCallback);
callbackField.set(handler, callback);
}
} catch (Exception e) {
}
}
进入正题，我们先从插桩中的方法入口和方法出口来分析
编译期已经对全局的函数进行插桩，在运行期间每个函数的执行前后都会调用 MethodBeat.i/o 的方法，如果是在主线程中执行，则在函数的执行前后获取当前距离 MethodBeat 模块初始化的时间 offset（为了压缩数据，存进一个long类型变量中），并将当前执行的是 MethodBeat i或者o、mehtod id 及时间 offset，存放到一个 long 类型变量中，记录到一个预先初始化好的数组 long[] 中 index 的位置（预先分配记录数据的 buffer 长度为 100w，内存占用约 7.6M）。数据存储如下图：
在搞清楚内部的逻辑之前，笔者认为直接贴代码不是很好理解，所以我们先来配个图，然后结合图来理解这个过程：
private static final int STATUS_DEFAULT = Integer.MAX_VALUE;
private static final int STATUS_STARTED = 2;
private static final int STATUS_READY = 1;
private static final int STATUS_STOPPED = -1;
private static final int STATUS_EXPIRED_START = -2;
private static final int STATUS_OUT_RELEASE = -3;
public static void i(int methodId) {
......
//正式开始 step 1
if (status == STATUS_DEFAULT) {
synchronized (statusLock) {
if (status == STATUS_DEFAULT) {
realExecute();
status = STATUS_READY;
}
}
}
long threadId = Thread.currentThread().getId();
if (threadId == sMainThreadId) {
//合并方法堆栈 step 2
if (sIndex < Constants.BUFFER_SIZE) {
mergeData(methodId, sIndex, true);
} else {
sIndex = 0;
mergeData(methodId, sIndex, true);
}
++sIndex;
}
}
private static void realExecute() {
//记录开始执行的时间戳
sCurrentDiffTime = SystemClock.uptimeMillis() - sDiffTime;
sHandler.removeCallbacksAndMessages(null);
//启动计时器
sHandler.postDelayed(sUpdateDiffTimeRunnable, Constants.TIME_UPDATE_CYCLE_MS);
//状态维护，延迟15s后执行，由上可知有i首次进来以后状态是STATUS_READY
//这里得结合looper的监听来说，后面分析捕捉细节再详说，这里记得这个状态维护
sHandler.postDelayed(checkStartExpiredRunnable = new Runnable() {
@Override
public void run() {
synchronized (statusLock) {
MatrixLog.i(TAG, "[startExpired] timestamp:%s status:%s", System.currentTimeMillis(), status);
if (status == STATUS_DEFAULT || status == STATUS_READY) {
status = STATUS_EXPIRED_START;
}
}
}
}, Constants.DEFAULT_RELEASE_BUFFER_DELAY);
//注册监听
LooperMonitor.register(looperMonitorListener);
}
然后可以看到时间更新的方法为，主要工作其实就是更新时间戳，每次更新后睡5s，然后挂起自己，等待被主线程分发消息时候再唤醒：
/**
* 计时器
* update time runnable
*/
private static Runnable sUpdateDiffTimeRunnable = new Runnable() {
@Override
public void run() {
try {
while (true) {
while (!isPauseUpdateTime && status > STATUS_STOPPED) {
sCurrentDiffTime = SystemClock.uptimeMillis() - sDiffTime;
SystemClock.sleep(Constants.TIME_UPDATE_CYCLE_MS);
}
synchronized (updateTimeLock) {
updateTimeLock.wait();
}
}
} catch (Exception e) {
MatrixLog.e(TAG, "" + e.toString());
}
}
};
private static void dispatchBegin() {
sCurrentDiffTime = SystemClock.uptimeMillis() - sDiffTime;
isPauseUpdateTime = false;
synchronized (updateTimeLock) {
updateTimeLock.notify();
}
}
最后在合并数据的时候把方法进入退出和方法id以及时间戳带上，组成一个long变量：
/**
* merge trace info as a long data
*
* @param methodId
* @param index
* @param isIn
*/
private static void mergeData(int methodId, int index, boolean isIn) {
//如果是分发的函数过来的，更新一下时刻，以示尊重~ 就是更新时戳，这个时间可不能是简单的5的倍数[手动抠鼻]
if (methodId == AppMethodBeat.METHOD_ID_DISPATCH) {
sCurrentDiffTime = SystemClock.uptimeMillis() - sDiffTime;
}
//可见输入为1输出为0
long trueId = 0L;
if (isIn) {
trueId |= 1L << 63;
}
trueId |= (long) methodId << 43;
//将方法id和时间戳合并成一个long值，以达到8字节存储的目的
trueId |= sCurrentDiffTime & 0x7FFFFFFFFFFL;
sBuffer[index] = trueId;
checkPileup(index);
sLastIndex = index;
}
最后就把数据合并完成了。matrix的慢函数监控至此结束~
