接上篇: Android获取View的宽和高(一)
其实除了ViewTreeObserver这个观察者类,还可以通过View.Post()获取到View宽高margin值的信息,代码如下:
btn02.post(new Runnable() {
@Override
public void run() {
//可以正常获取到View宽高 margin
LogUtil.d(" btn02.post" + btn02.getWidth()+btn02.getTop());
}
});
看log日志输出的时候发现run方法是在ViewTreeObserver的OnGlobalLayoutListener,OnPreDrawListener,OnDrawListener之后执行的,那么它到底什么时候调用的呢,点开view的post方法,查看源码代码如下:
/**
* Causes the Runnable to be added to the message queue.
* The runnable will be run on the user interface thread.
*//把该runnable加入到 mq里,最终在ui线程执行
*
*/
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;
}
/**
* Returns the queue of runnable for this view.
*/
private HandlerActionQueue getRunQueue() {
if (mRunQueue == null) {
mRunQueue = new HandlerActionQueue();
}
return mRunQueue;
}
代码里包含了一个attachInfo和 HandlerActionQueue,attachInfo是View在添加到window上的描述信息,HandlerActionQueue姑且看作一个Handler去发送通知的,继续查看AttachInfo的赋值过程,代码如下:
/**
* @param info the {@link android.view.View.AttachInfo} to associated with
* this view
*/
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
if (mOverlay != null) {
mOverlay.getOverlayView().dispatchAttachedToWindow(info, visibility);
}
registerPendingFrameMetricsObservers();
performCollectViewAttributes(mAttachInfo, visibility);
onAttachedToWindow();
ListenerInfo li = mListenerInfo;
final CopyOnWriteArrayList listeners =
li != null ? li.mOnAttachStateChangeListeners : null;
if (listeners != null && listeners.size() > 0) {
for (View.OnAttachStateChangeListener listener : listeners) {
listener.onViewAttachedToWindow(this);
}
}
needGlobalAttributesUpdate(false);
notifyEnterOrExitForAutoFillIfNeeded(true);
}
mAttachInfo在 dispatchAttachedToWindow中被赋值,它其实是在ViewRootImpl中构造的,(ViewRootImpl 可以理解是一个 Activity 的 ViewTree 的根节点的实例,它是用来管理 DecorView 和 ViewTree)。在ViewRootImpl构造方法为:
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,context);
而dispatchAttachedToWindow只会在两种情况下被调用:
- ViewRootImpl 第一次 performTraversal()时会将整个view tree里所有有view的 dispatchAttachedToWindow() DFS 调用一遍.
- ViewGroup的 addViewInner(View child, int index, LayoutParams params, boolean preventRequestLayout);
这时我们应该是第一种情况下的调用,我们在去查看ViewRootImpl中的 performTraversal()方法:
private void performTraversals () {
// cache mView since it is used so much below...
final View host = mView
host.dispatchAttachedToWindow(mAttachInfo, 0);
//viewTreeObserver也在这个方法中调用
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);
//对每次遍历操作进行排队
getRunQueue().executeActions(mAttachInfo.mHandler);
// Ask host how big it wants to be//测量过程
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
int width = host.getMeasuredWidth();
int height = host.getMeasuredHeight();
//onLayout执行
performLayout(lp, mWidth, mHeight);
//开始绘制
performDraw();
}
该方法是View整个绘制过程;其中 getRunQueue()方法如下:
static HandlerActionQueue getRunQueue() {
// sRunQueues是 ThreadLocal 对象
HandlerActionQueue rq = sRunQueues.get();
if (rq != null) {
return rq;
}
rq = new HandlerActionQueue();
sRunQueues.set(rq);
return rq;
}
忽然找到了亲人,这不就是post里的HandlerActionQueue那个对象么,到目前他们之间到关系貌似也渐渐清晰起来了。
总结一下:
- 1.View在attachtoWindow之前,会维护一个HandlerActionQueue对象,储存当前的runnable 对象,当attach to window(ViewRootImpl 执行到 performTraversal 方法)的时候交给ViewRootImpl处理。
- 2.View的dispatchAttachedToWindow方法也会为当前view创建一个attachInfo对象,该对象持有 ViewRootImpl 的引用,当 View 有此对象后,后续的所有 Runnable 都将直接交给 ViewRootImpl 处理。
- 3.ViewRootImpl在执行performTraversal方法是通过getRunQueue() 方法在 ThreadLocal中维护一个HandlerActionQueue对象,ViewRootImpl使用该对象对runnable进行短期维护。
- 4.但需要注意的是,各个 View 调用的 post 方法,仍然是由各自的 HandlerActionQueue 对象来入队任务的,然后在 View#dispatchAttachedToWindow 的时候转移给 ViewRootImpl 去处理。
另外,View.post也有不靠谱的地方,API24和23的post方法是有区别的,23的代码如下:
// 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;
}
再来看一下 HandlerActionQueue#executeActions方法:
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;
}
}
post方法不靠谱的原因根本上是executeActions() 方法的调用时机不同,导致 View 在没有 mAttachInfo 对象的时候,表现不一样了。具体可参考这篇日志。
https://juejin.im/post/59ae9366518825243a78f9b6
除此以外,ViewRootImpl 使用 ThreadLocal 来存储队列信息,在某些情境下,还会导致内存泄漏。详细信息可以参考:
https://blog.csdn.net/a740169405/article/details/69668957