从源码角度理解如何获取 View 的宽高

最新推荐文章于 2022-07-08 22:45:00 发布

Android技术之家

最新推荐文章于 2022-07-08 22:45:00 发布

阅读量155

点赞数

Joseph_L的博客地址：

https://www.jianshu.com/u/6b51f840977d

前言

之前的文章里写到过，我们在 onCreate() 和 onResume() 方法中无法获取 View 的宽高信息，但在平时开发中，我们经常会用到 View#post 来进行 View 宽高信息的获取。

那么问题就来了，为什么 View#post 就可以获取到宽高信息？里边那个 run() 是在什么时候执行的？具体实现原理又是什么？

带着这些疑问，我最近研究了一下 View#post 的源码。本来以为挺简单的一个东西，但是没想到坑越挖越深，最过分的是，不同的版本源码还不相同，实现原理也有细微的差别。集中攻克了一个周末以后，感觉大概理解了，索性写下篇博客进行记录备忘。

正文

View#post 基本使用

具体代码如下：

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    View view = findViewById(R.id.test);
    view.post(new Runnable() {
        @Override
        public void run() {
            // 可以正常获取到 View 的宽高信息
            Log.e("Test", "view.post ---- > " + view.getHeight());
        }
    });
}

这里我们以 API 26 为例，来尝试解答一下这个问题。

实际上，Android 系统以 API 24 为界，之前之后的版本，对此处的实现有细微的差别，具体的改动以及原因在后文会一一给出分析。

post() 执行过程以及源码分析

View#post 入口

先来看 View#post 源码，重点注意注释：

/**
 * Causes the Runnable to be added to the message queue.
 * The runnable will be run on the user interface thread.
 * 将 Runnable 添加到执行队列中，其最终会在 UI 线程中执行
 */
public boolean post(Runnable action) {
    // AttachInfo 是 View 的内部类，用来存储一些基本信息
    // 此处可以暂时认为 mAttachInfo 为 null
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        // attachInfo 不为空时，转而使用其内部的 Handler 对象操作
        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.
    // 在我们确定当前 Runnable 的目标运行线程之前，先将其推迟执行
    // 假设在 attach 完成之后，此 Runnable 对象会被成功的「placed」（暂且翻译成「放置」）
    // 好好理解一下这个注释，我们继续往下走
    getRunQueue().post(action);
    return true;
}

首先，明确一点：Runnable 会在 UI 线程中执行；然后，我们来看一下这个看上去很重要的 mAttachInfo 是在哪里赋值的：

void dispatchAttachedToWindow(AttachInfo info, int visibility) {
    mAttachInfo = info;
    // Transfer all pending runnables. 转移所有待办任务
    if (mRunQueue != null) {
        mRunQueue.executeActions(info.mHandler);
        mRunQueue = null;
    }
    // 回调方法
    onAttachedToWindow();
}

先不在意除了赋值以外的其他操作，我们继续追踪 dispatchAttachedToWindow 方法，发现其最初调用是在 ViewRootImpl#performTraversals 方法。好了，记住这个结论，我们先把它放在一旁。

接下来，我们来看一看这个 getRunQueue().post() 又做了什么：

/**
 * 获取一个 RunQueue 对象，用来进行 post 操作
 * Returns the queue of runnable for this view.
 * 注释是：为当前 View 对象返回一个执行队列，记住这个「当前 View 对象」
 */
private HandlerActionQueue getRunQueue() {
    if (mRunQueue == null) {
        mRunQueue = new HandlerActionQueue();
    }
    return mRunQueue;
}

HandlerActionQueue 又是个啥

很明显，执行 post 方法的是 HandlerActionQueue 对象，那这又是个什么东西：

/**
 * Class used to enqueue pending work from Views when no Handler is attached.
 * 此类用于在当前 View 没有 Handler 依附的时候，将其待完成的任务入队
 */
public class HandlerActionQueue {
    private HandlerAction[] mActions;
    private int mCount;

    // 这个就是我们在外边调用的 post 方法，最终会调用到 postDelayed 方法
    public void post(Runnable action) {
        postDelayed(action, 0);
    }

    // 将传入的 Runnable 对象存入数组中，等待调用
    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++;
        }
    }

    // 这里才是真的执行方法
    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;
        }
    }
}

通过查看 HandlerActionQueue 的源码，我们发现了一个问题：不同于在 onCreate() 直接获取 View 的宽高，我们调用 post 方法，其中的 run 方法并没有被马上执行。

这样就不难解释为什么用这种方式可以获取到宽高了。那我们可以猜测一下，这种情况下，一定是 View 完成测量后才执行了这个方法，所以我们才可以拿到宽高信息。

事实上也正是这样的，那么这个方法到底是在什么时候执行的呢？很明显，HandlerActionQueue#executeActions 才是真正完成调用的方法，那这个方法又做了些什么工作呢？

根据代码可知，该方法接收一个 Handler，然后使用这个 Handler 对当前队列中的所有 Runnable 进行处理，即 post 到该 Handler 的线程中，按照优先级对这些 Runnable 依次进行处理。

简单来说，就是传入的 Handler 决定着这些 Runnable 的执行线程。

接下来，我们来追踪这个方法的调用情况。

640?wx_fmt=png

我们注意到，对于该方法出现了两次调用，一次在 View#dispatchAttachToWindow（就是我们最开始找到的那个方法），另一次是在 ViewRootImpl#performTraversals。

万恶之源 performTraversals()

很明显，所有的证据都指向了 performTraversals ，那么下面我们就来重点分析一下这个方法。如果你了解过 View 的测绘流程，那你对这个方法一定不会陌生，因为这个方法就是 View 绘制流程的起点。

private void performTraversals() {

    // 此处的 host 是根布局 DecorView，用递归的方式一层一层的调用 dispatchAttachedToWindow
    // mAttachInfo 是不是很眼熟，就是最开始 View#post 的第一层判断
    // 这个 mAttachInfo 在 ViewRootImpl 的构造器中初始化的，其持有 ViewRootImpl 的 Handler 对象
    host.dispatchAttachedToWindow(mAttachInfo, 0);
    getRunQueue().executeActions(mAttachInfo.mHandler);

    // 绘制流程就从这里开始
    performMeasure();
    performLayout();
    performDraw();
}

我们先从 dispatchAttachedToWindow 开始，我们之前已经看过这个方法的源码了：

void dispatchAttachedToWindow(AttachInfo info, int visibility) {
    mAttachInfo = info;
    // Transfer all pending runnables. 转移所有待办任务
    if (mRunQueue != null) {
        mRunQueue.executeActions(info.mHandler);
        mRunQueue = null;
    }
    // 回调方法
    onAttachedToWindow();
}

现在来进行分析：

我们已经知道了此方法是从根视图开始递归向下调用的，那么递归到最深处，就会轮到最开始我们调用 post 方法的 View 对象来执行该方法，也就是该方法内的所有属性，都是我们 findViewById 获得的那个 View 对象的属性；
而且我们也知道，第一个参数 AttachInfo 就是 ViewRootImpl 中初始化的 AttachInfo，它持有当前 ViewRootImpl 的 Handler 对象引用，并将该引用传给了 executeActions()。此时，我们再来回顾一下 executeActions() 方法的作用，传入的 Handler 决定着队列里这些 Runnable 的执行线程。

很明显，此处的 mRunQueue 就是我们最开始调用 post() 时，调用 View#getRunQueue 返回的那个对象，这个对象中有准备获取View高度的 Runnable 对象，也就是说 mRunQueue 通过调用 executeActions() 将当前 View 的所有 Runnable ，都会转由 ViewRootImpl 的 Handler 来处理！而在完成这个工作之后，当前 View 也显示地将 mRunQueue 置空，因为所有的待办任务都已经交给 ViewRootImpl 去处理了。

现在再回过头看代码的注释，就差不多可以理解了：

// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
// 所有的 Runnable 都会在 attach 之后被正确的放到其应该运行的线程上去
getRunQueue().post(action);

// Transfer all pending runnables.
// 转移所有待办任务(到 ViewRootImpl 中进行处理)
if (mRunQueue != null) {
    mRunQueue.executeActions(info.mHandler);
    mRunQueue = null;
}

dispatch 方法执行完了，我们继续回来走 performTraversals() ，接下来一句是：

// 有之前的经验，我们知道这句话的意思是
// 使用 mAttachInfo.mHandler 来处理 getRunQueue() 中的 Runnable 任务
getRunQueue().executeActions(mAttachInfo.mHandler);

要明确的一点是，此时我们处在 ViewRootImpl 类中，此处的 getRunQueue() 方法有别于 View#post：

// ViewRootImpl#getRunQueue
// 使用 ThreadLocal 来存储每个线程自身的执行队列 HandlerActionQueue
static HandlerActionQueue getRunQueue() {
    // sRunQueues 是 ThreadLocal<HandlerActionQueue> 对象
    HandlerActionQueue rq = sRunQueues.get();
    if (rq != null) {
        return rq;
    }
    rq = new HandlerActionQueue();
    sRunQueues.set(rq);
    return rq;
}

// View#post
// 为当前 View 返回一个执行队列，但是在 dispatchAttachToWindow 时转到 UI 线程去
private HandlerActionQueue getRunQueue() {
    if (mRunQueue == null) {
        mRunQueue = new HandlerActionQueue();
    }
    return mRunQueue;
}

说回 performTraversals() ，很明显 getRunQueue() 是 UI 线程执行队列的第一次初始化，也就是说当前这个任务队列里并没有待执行任务！

但是需要注意的是，当前没有执行任务（HandlerActionQueue），不代表 Handler 消息队列中没有消息，这是两个概念，需要注意区分开。

总结一下：

View#post 方法调用时，会为当前 View 对象初始化一个 HandlerActionQueue ，并将 Runnable 入队存储；
等在 ViewRootImpl#performTraversals 中递归调用到 View#dispatchAttachedToWindow 时，会将 ViewRootImpl 的 Handler 对象传下来，然后通过这个 Handler 将最初的 Runnable 发送到 UI 线程（消息队列中）等待执行，并将 View 的 HandlerActionQueue 对象置空，方便回收；
ViewRootImpl#performTraversals 继续执行，才会为 UI 线程首次初始化 HandlerActionQueue 对象，并通过 ThreadLocal 进行存储，方便之后的复用，但需要注意的是，此处初始化的队列中是没有任何 Runnable 对象的；
然后 ViewRootImpl#performTraversals 继续执行，开始 View 的测量流程。

View#post 中 Runnable#run 执行的时机

但现在的问题是，无论怎么说，HandlerActionQueue#executeActions 都是先于 View 测绘流程的，为什么在还没有完成测量的时候，就可以拿到宽高信息？

我们都知道，Android 系统是基于消息机制运行的，所有的事件、行为，都是基于 Handler 消息机制在运行的。所以，当 ViewRootImpl#performTraversals 在执行的时候，也一定是基于某个消息的。而且，HandlerActionQueue#executeActions 执行的时候，也只是通过 Handler 将 Runnable post 到了 UI 线程等待执行（还记得 View#post 的注释吗？）。

不出意外的话，此时 UI 线程正忙着执行 ViewRootImpl#performTraversal ，等该方法执行完毕，View 已经完成了测量流程，此时再去执行 Runnable#run ，也就自然可以获取到 View 的宽高信息了。下面用具体的实例佐证一下我们的猜想。

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    final ViewGroup viewGroup = (ViewGroup) getWindow().getDecorView();

    // 等待 Add 到父布局中
    view = new View(this) {
        @Override
        protected void onLayout( ... ... ) {
            super.onLayout(changed, left, top, right, bottom);
            Log.e("Test", "执行了onLayout()");
        }
    };

    // 自己声明的 Handler 
    mHandler.post(new Runnable() {
        @Override
        public void run() {
            Log.e("Test", "mHandler.post ---- > " + view.getHeight());
        }
    });

    // onCreate() 中 mAttachInfo 还未被赋值，这里会交给 ViewRootImpl 的 Handler 来处理
    // 即加入消息队列，等待执行
    view.post(new Runnable() {
        @Override
        public void run() {
            Log.e("Test", "view.post ---- > " + view.getHeight());
        }
    });

    viewGroup.addView(view);
}

最终打印日志如下：

640?wx_fmt=png

也就是说：

Handler#post 首先执行，其 post 的时间点在 onCreate() 方法内，在消息队列中的位置一定比 performTraversals() 靠前；
ViewRootImpl#performTraversal 执行，过程中执行了 View#dispatchAttachedToWindow 方法，将最初的 Runnable 入队后进行测量流程，完成了 layout 过程；
之后才执行了最初的 View#post 方法，也就说明了，在 View#dispatchAttachedToWindow 中使用 ViewRootImpl 的 Handler postDelay 的 Runnable 对象，在主线程消息队列中，确实是排在 ViewRootImpl#performTraversal 之后的

View#post 整体流程的简单总结

最后大概总结一下：

当我们使用 View#post 时，会有两种情况：

在当前 View attach 到 Window 之前，会自己先维护一个 HandlerActionQueue 对象，用来存储当前的 Runnable 对象，然后等到 Attach 到 Window 的时候 (也就是 ViewRootImpl 执行到 performTraversal 方法时) ，会统一将 Runnable 转交给 ViewRootImpl 处理；
而在 View#dispatchAttachedToWindow 时，也会为当前 View 初始化一个 AttachInfo 对象，该对象持有 ViewRootImpl 的引用，当 View 有此对象后，后续的所有 Runnable 都将直接交给 ViewRootImpl 处理；
而 ViewRootImpl 也会在执行 performTraversal 方法，也会调用 ViewRootImpl#getRunQueue ，利用 ThreadLocal 来为主线程维护一个 HandlerActionQueue 对象，至此，ViewRootImpl 内部都将使用该队列来进行 Runnable 任务的短期维护；
但需要注意的是，各个 View 调用的 post 方法，仍然是由各自的 HandlerActionQueue 对象来入队任务的，然后在 View#dispatchAttachedToWindow 的时候转移给 ViewRootImpl 去处理。

Android 7.0 里 View#post 的变动以及原因

View#post 说到这里大概就差不多了，文章开篇的时候说到：

Android 系统以 API 24 为界，之前之后的版本，对此处的实现有细微的差别

下面来简单对比一下具体的差别，顺便分析一下具体为什么要这样改动。

实际上这个方法的改动主要是为了解决一个 bug，这个 bug 就是：在 View 被 attach 到 window 之前，从子线程调用的 View#post ，永远无法得到执行。

具体原因，我们来看一下 API23 版本的 View#post，就大概都明白了：

// Android API23 View#post
public boolean post(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        return attachInfo.mHandler.post(action);
    }
    // Assume that post will succeed later
    // 注意此处，不同于我们之前介绍的，这里是直接使用 ViewRootImpl#getRunQueue 来入队任务的
    ViewRootImpl.getRunQueue().post(action);
    return true;
}

我们可以看到，不同于我们之前介绍的，API23 版本中，View#post 在没有 attach 到 window 之前，也就是 mAttachInfo 是 null 的时候，不是自己维护任务队列，而是直接使用 ViewRootImpl#getRunQueue 来入队任务的。

再来看一下 ViewRootImpl#getRunQueue 方法，我们就会发现问题出在哪里了：

static final ThreadLocal<RunQueue> sRunQueues = new ThreadLocal<RunQueue>();
static RunQueue getRunQueue() {
    RunQueue rq = sRunQueues.get();
    if (rq != null) {
        return rq;
    }
    rq = new RunQueue();
    sRunQueues.set(rq);
    return rq;
}

没错，这个队列的保存与获取，是通过以线程为 key 值来存取对象 ThreadLocal 来维护的。而在这个版本的源码中，executeActions() 方法的执行，只有一次调用，那就是 ViewRootImpl#performTraversal 中（感兴趣的可以去 23 版本的源码中查看，这里就不贴图了），与此同时，该方法肯定是执行在主线程中的。

现在的问题就变成了：我在子线程中 post 了一个 runnable，并且系统以该子线程为 key 将队列存了起来等待执行；但是在具体执行的时候，系统却是去主线程中寻找待执行的 Runnable，那么当然是永远都得不到执行的了。

而在具体 attach 到 window 之后，View 的 mAttachInfo 持有 ViewRootImpl 引用，会直接将所有的 Runnable 转交给 ViewRootImpl 的 Handler 处理，也就都能得到妥善处理，就与线程无关了。

除此以外，ViewRootImpl 使用 ThreadLocal 来存储队列信息，在某些情境下，还会导致内存泄漏。详细信息可以参考：

https://blog.csdn.net/a740169405/article/details/69668957

所以，Google 工程师为了解决这两个问题（内存泄漏的问题更严重一些），就在 View#post 方法中使用 View 对象来进行队列的存储，然后在 attach 到 window 的时候，通过持有 ViewRootImpl 引用的 AttachInfo 对象直接将 View 对象的 Runnable 处理掉，就完美解决了这些问题。

总结