View的post函数详析

基于Android 28

View本身也提供了post接口来在主线程中处理异步任务。但是不同的是,view中做了保障机制:即所有的任务都是在绘制第一帧的时候才能进入MainLooper。

下面看具体分析:

HandlerActionQueue

那么就先从入口往里面一层层看,下面是post函数的具体实现。

View.post()函数

// frameworks/base/core/java/android/view/View.java
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发送消息。这同正常的Handler机制是一致的。
  • 如果不存在,那么获取一个RunQueue并post给它。

至于AttachInfo什么情况下不为空,一会会跟下面的RunQueue会合起来看。这里主要看一下RunQueue。

getRunQueue()

// frameworks/base/core/java/android/view/View.java
private HandlerActionQueue getRunQueue() {
    if (mRunQueue == null) {
        mRunQueue = new HandlerActionQueue();
    }
    return mRunQueue;
}

getRunQueue返回的是本地缓存的一个HandlerActionQueue类的实例mRunQueue,并且mRunQueue本身是lazyInit的。

下面再看来看mRunQueue如何处理postDelayed():

postDelayed

// frameworks/base/core/java/android/view/HandlerActionQueue.java
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++;
    }
}

这里其实也非常明显,首先HandlerActionQueue会将进来的Runnable对象封装成HandlerAction。最后将HandlerAction对象加入到本地的mActions(即HandlerAction数组中)缓存起来。

到这里其实调用就结束了,那么什么时候才会执行到呢?

dispatchAttachedToWindow

其实稍微注意一下源码就可以发现,在View的dispatchAttachedToWindow方法中会设置AttachInfo并且处理mRunQueue中的队列:

// frameworks/base/core/java/android/view/View.java
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
    mAttachInfo = info;
    // ...
    // Transfer all pending runnables.
    if (mRunQueue != null) {
        mRunQueue.executeActions(info.mHandler);
        mRunQueue = null;
    }
    performCollectViewAttributes(mAttachInfo, visibility);
    onAttachedToWindow();
    // ...
}

上面提到的mAttachInfo就在这里赋值的,经过这一步之后再执行View的post方法就会直接使用Handler发送消息了。

之后会读取mRunQueue(默认情况下没人调用post等相关方法这个变量会是null),并将mAttachInfo中的mHandler对象传递到其内部的executeActions中,同时在View里将mRunQueue置null。

下面来看HandlerActionQueue的executeActions函数

executeActions

// frameworks/base/core/java/android/view/HandlerActionQueue.java
public void executeActions(Handler handler) {
    synchronized (this) {
        final HandlerAction[] actions = mActions;
        for (int i = 0, count = mCount; i < count; i++) {
            final HandlerAction handlerAction = actions[i];
            handler.postDelayed(handlerAction.action, handlerAction.delay);
        }

        mActions = null;
        mCount = 0;
    }
}

这里其实就是读取HandlerAction数组并通过View中传递过来的mHandler执行postDelay的行为。

其实不论是在什么时机调用post最终都会用到mAttachInfo的mHandler对象来发送消息到MainLooper中。

虽然知道view.post的任务最终的一定会通过AttachInfo的mHandler对象post出去,但是他是哪里来的呢?

doTraversal()

我们都知道Android上面View的绘制都是在doTraversal的完成的。

// frameworks/base/core/java/android/view/ViewRootImpl.java
void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }

        performTraversals();

        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}

而doTraversal()函数本身会调用 performTraversals()来完成具体的绘制调用,因为绘制涉及到非常多的流程,所以这一步其实非常庞大,但是还是可以找到上面提到的dispatchAttachedToWindow相关的行为:

// frameworks/base/core/java/android/view/ViewRootImpl.java
private void performTraversals() {
// ...
    Rect frame = mWinFrame;
    if (mFirst) {
        // ...
        host.dispatchAttachedToWindow(mAttachInfo, 0);
        mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);
        dispatchApplyInsets(host);
    // ...
    }
    // ...
    mFirst = false;
    // ...
    boolean cancelDraw = mAttachInfo.mTreeObserver.dispatchOnPreDraw() || !isViewVisible;
    if (!cancelDraw && !newSurface) {
        if (mPendingTransitions != null && mPendingTransitions.size() > 0) {
            for (int i = 0; i < mPendingTransitions.size(); ++i) {
                mPendingTransitions.get(i).startChangingAnimations();
            }
            mPendingTransitions.clear();
        }

        performDraw();
    } else {
        // ..
    }
    mIsInTraversal = false;
}

可以看到mFirst为true时,即准备开始第一次绘制时会调用mHost的dispatchAttachedToWindow函数,经过ViewGroup对各个子View进行dispatchAttachedToWindow事件的层层风发,最终执行到调用post方法的那个view。

其中mHost其实就是在Activity执行setContentView之后经过PhoneWindow最后创建ViewRootImpl并设置进来的DecorView。

具体doTraversal是如何运行的,那就是View本身绘制流程了。要想讲清楚需要挺大篇幅,这里不再展开了。

延伸

与直接创建Handler的不同

仅考虑是在主线程内部创建Handler的情况。

其实通过上面的分析已经可以得出非常明显的结论:那就是,view.post如果在没有绘制第一帧的情况下,所有的任务都不会被执行,并且会缓存在HandlerActionQueue中等待dispatchAttachToWindow时机。而在HandlerActionQueue被执行时,还会再次讲先前的任务post一遍。

而Handler最直接,在你发送任务的时候就会立马进入MainLooper等待下次被调起。这个过程其实同View的绘制流程其实是脱节的。

与ViewTreeObserver的不同

ViewTreeObserver行为发生在View的绘制过程中,并且可以对当前view绘制事件进行拦截。简单来说,当我知道你的view尺寸之后我可以作出改变并且要求你停止此次绘制(见上面performTraversals函数最终的cancelDraw)。

如果想要第一事件获取View的宽高并且及时对自身的UI作出改变,则非常建议使用ViewTreeObserver。使用view.post很有可能是发生在MainLooper执行完绘制第一帧之后,从而导致节目的抖动或者闪烁。

其实究其原因还是ViewTreeObserver同Handler本身完全不是一回事。放在这里提是提醒一下,想在View的绘制周期中干活其实是有更好的选择。

By@hyongbai 共5323个字

本文链接

原文 

http://yourbay.me/all-about-tech/2019/08/27/android-28-view-post/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » View的post函数详析

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址