这个问题,可以换成“为什么在onCreate里面修改一些子View不生效,错位,乱”等问题。
本质原因肯定是在没有把整个ViewGroup渲染完成之前,操作了部分子View,导致了位置偏移等。
解决办法也很简单,通过调用View.post(), 注意是View的post。
这样就延迟了我们执行的动作,到了渲染完成之后,才进行操作,避免的错乱的产生。
流程分析
渲染完成,换成代码上是什么意思?
就是三大流程走完成。
在没完成之前,调用任何的translation等操作,就可能导致测量显示错误,错位。
Activity:
- handleResumeActivity(该方法内使用Context.getWindowManager创建WindowManager对象)
WindowManager: - addView(该方法内WindowManager委托代理给一个WindowManagerGLobal对象)
WindowManagerGLobal: - addView(该方法内创建了ViewRootImpl对象)
ViewRootImpl:setView→requestLayout→scheduleTraversals→doTraversal→performTraversals(最终到达绘制的入口)
3.1 performTraversals里面会往所有子View dispatchAttachedToWindow, 并设定mAttachInfo,即有了handler。
其中从WindowManager.addView开始就是Activity创建Window的过程,最终在ViewRootImpl对象的performTraversals中完成View的绘制(一个Window对象对应了一个ViewViewRootImpl对象也对应了一个View对象,即DecorView)
performTraversals()是绘制的入口,
它依次调用 - performMeasure()、performLayout()和 performDraw()三个方法,
三个方法内部分别调用了DecorView的measure()、layout()和draw方法。 - 最后,传导到我们每一个View的mesaure(),onMeasure()(可能多次调用), layout(),onLayout(), draw() onDraw()函数。
为什么post就能确保是渲染之后呢?
1. Handler的由来
在dispatchAttachedToWindow(无法继承)被回调之前,拿不到handler,就往RunQueue里存储。
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;
}
直到:
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
...
// Transfer all pending runnables.
if (mRunQueue != null) {
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
才把我们的消息post出去,执行。
2. post的消息,又是如何保证在三大流程之后执行呢?
阅读系统源码:
scheduleTraversals {
postRunnable { //发送消息执行的
doTraversal{
performTraversals { 2510 ~ 3333行
2613 dispatchAttachedToWindow
2677 2717 3706 measureHierarchy | 3082 3108 performMeasure
3140 performLayout
3306 performDraw
}
}
}
}
另外,也有其他情况,会导致多次执行scheduleTraversals:
if (!cancelDraw) {
xxx
performDraw();
} else {
if (isViewVisible) {
// Try again
scheduleTraversals();
} else {
xxxx
即变成了
scheduleTraversals {
postRunnable { //发送消息执行的
performTraversals { 2510 ~ 3333行
2613 dispatchAttachedToWindow
追加:post我们的任务
2677 2717 3706 measureHierarchy | 3082 3108 performMeasure
3140 performLayout
3306 performDraw
追加:scheduleTraversals 先发送屏障;又通过mChoreographer.postCallback 发送一个异步消息。
}
这里看出,三大流程,其实是跑在一个函数里面!
- 我们知道,函数又是跑在handler里面,所以一般情况,我们的post的任务,在handler MessageQueue需要等待下一个next取出消息再执行,自然而然在三个流程之后。
- 即使有额外逻辑导致了触发二次scheduleTraversals ,
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
内部是post(异步消息) setAsynchronous(true);
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
它会通过消息屏障和异步消息,framework通过handler这个机制,当下次next取出msg的时候,保证取出渲染的消息优先完成。