阅读 1133

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() 在主线程的消息队列尾部重新添加一个任务,用来作为绘制结束的标记,是相对准确的。

参考文章

DoKit支持Activity启动耗时统计方案

通过View.post()获取View的宽高引发的两个问题

Handler之同步屏障机制(sync barrier)

【Android源码解析】View.post()到底干了啥