时间管理大师教你Android如何精准获取页面绘制时间
前言
我们都知道，在 Activity 里的 onCreate(), onStart(), onResume() 等方法里通过 view.getWidth() 或者 view.getMeasureWidth() 方法获取到的结果都是 0。这是因为，在这些回调方法被调用的时候，UI 还没有开始绘制，UI 的绘制是发生在 onResume() 方法之后，通过执行以下方法进行
ViewRootImpl.doTraversal->
ViewRootImpl.performTraversals->
└ViewRootImpl.relayoutWindow
└ViewRootImpl.performMeasure
└ViewRootImpl.performLayout
└ViewRootImpl.performDraw
ViewRootImpl.reportDrawFinished
复制代码
通常的解决方案是用 view.post() 方法发送一个任务，该任务会在 UI 绘制完成之后执行。关于原理，可以参考文章 【Android源码解析】View.post()到底干了啥
现在，我们知道了 UI 绘制完成的时机，但是还不够，我们要研究的是如何能够精准量化页面的绘制时间，也就是寻找绘制开始和绘制结束两个时间点。我们可以根据这个时间来进行启动优化，布局优化。
绘制开始的点可以从 onResume() 方法开始，关键是绘制结束点的选取。文章 DoKit支持Activity启动耗时统计方案 提供了三条思路，我们可以详细分析一下。
方法一
Activity.java
@Override
protected void onResume() {
super.onResume();
final long start = System.currentTimeMillis();
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
Log.d(TAG, "onRender cost:" + (System.currentTimeMillis() - start));
return false;
}
});
}
复制代码
该方法实现比较简单，通过添加 idleHandler 的方式，发送一个任务，该任务只有在线程处于空闲的状态下会被调用
方法二
@Override
protected void onResume() {
super.onResume();
final long start = System.currentTimeMillis();
getWindow().getDecorView().post(new Runnable() {
@Override
public void run() {
new Hanlder().post(new Runnable() {
@Override
public void run() {
Log.d(TAG, "onPause cost:" + (System.currentTimeMillis() - start));
}
});
}
});
}
复制代码
该方法首先用 view.post() 的方式创建一个任务，我们上面也说了，该任务会在 UI 绘制之后执行，那为什么这里不直接在这个任务里获取结束绘制的时间，而是要另外再用 Handler 发送一个新的任务呢？我们如果在这两个任务里各自打上 log 看一下执行时间，就会发现，它们相差了十几到几十毫秒，直接在 view.post() 任务里获取绘制结束时间是不够精确的。下面我们探究原因。
看一下 view.post() 方法的源码
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
getRunQueue().post(action);
return true;
}
复制代码
这里会首先判断 attachInfo 是否为空，不为空的话，会直接调用 handler.post() 方法。也就是说，如果 attachInfo 对象不为空，view.post() 和 new Handler().post() 的效果是相同的。
反之，如果 attachInfo 为空，就会调用 mRunQueue 对象的 post() 方法
public void postDelayed(Runnable action, long delayMillis) {
final HandlerAction handlerAction = new HandlerAction(action, delayMillis);
synchronized (this) {
if (mActions == null) {
mActions = new HandlerAction[4];
}
mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
mCount++;
}
}
复制代码
查看该方法的源码，会发现它并没有将任务直接发送，而是创建了一个 HandlerAction 数组保存了起来。也就是说，如果 attachInfo 对象为空，就将任务暂时保存到数组中，在后续的某一个时刻，再进行发送。
ViewRootImpl.java
private void performTraversals() {
......
// host即DecorView
host.dispatchAttachedToWindow(mAttachInfo, 0);
.......
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
.......
performLayout(lp, mWidth, mHeight);
.......
performDraw();
.......
}
View.java
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
......
// Transfer all pending runnables.
if (mRunQueue != null) {
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
......
}
复制代码
可以看到，在 dispatchAttachedToWindow 方法里，通过执行 executeActions 将之前保存的任务全部发送。
这里可能会有人有疑问，dispatchAttachedToWindow 方法是在 performMeasure 等绘制操作之前进行的，也就是 view.post() 中的任务是在绘制之前发送的，为什么它还能获取到 view 的真实宽高呢？
这就涉及到 Android 的消息机制了，整个 Android 体系都是由消息来驱动的，我们这里只涉及到主线程，所以我们通过 view.post(), new Handler().post() 等方式发送的任务，都被添加到了主线程到消息队列中，等待执行，而 performTraversals() 方法也是在另一个任务中执行的，源码如下：
ViewRootImpl.java
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
复制代码
所以，executeActions() 方法发送的任务，只是将其添加到主线程到任务队列中，只有当 performTraversals() 方法所在的任务执行完毕后，才会执行队列中的其他任务。
回到最初的问题，我们在 onResume() 方法中直接执行 view.post() 方法的时候，attachInfo 对象此时为空，具体原理请参考 【Android源码解析】View.post()到底干了啥。所以 view.post() 中的任务会被暂时存放到数组中，在开始绘制之前被发送到主线程的消息队列中，绘制完成后会被执行。但是被缓存的任务一定不止我们添加的这一个，还有一些其他的系统任务，所以我们还要通过 new Handler().post() 在主线程的消息队列尾部重新添加一个任务，用来作为绘制结束的标记，是相对准确的。
最后
平时在写bug还有学习的过程中，习惯将一些学习笔记、资料整理收集下来，放在自己的githup里面，需要的同学可以点击这里自取，共同学习进步，不要嫌弃哈~
