Android启动优化、布局优化必经之路—如何精准获取页面绘制时间
作者:互联网
└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 等绘制操作之前进行
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
的,也就是 view.post() 中的任务是在绘制之前发送的,为什么它还能获取到 view 的真实宽高呢?
这就涉及到 Android 的消息机制了,整个 Android 体系都是由消息来驱动的,我们这里只涉及到主线程,所以我们通过 view.post(), new Handler().post() 等方式发送的任务,都被添加到了主线程到消息队列中,等待执行,而 performTraversals() 方法也是在另一个任务中执行的,源码如下:
ViewRootImpl.java
final class TraversalRunnable implements Runnable {
@Override
标签:优化,必经之路,任务,void,new,post,绘制,Android,view 来源: https://blog.csdn.net/m0_65145219/article/details/122141928