先把结论放在前面：View.post 能拿到宽高，是因为它的 Runnable 被挂到了主线程消息队列的尾部，而 performTraversals（measure → layout → draw）是在当前这一轮消息处理中同步完成的。 换句话说：post 出去的 Runnable 排在"下一帧"执行，而布局是在这一帧内做完的——所以回调里 view.width 已经是最终值。
这题是"看过资料"和"写过代码"的分水岭。前者的回答停在"post 是在消息队列里，下一帧才执行"这句结论；后者的回答里有执行路径、有数据流向、有失败模式——比如为什么 view.post 在子线程调用会崩、为什么未 attach 的 View post 的任务永不执行、为什么 post 里读宽高仍可能是 0。能主动说出失败模式，才算答出深度。
时序：为什么"下一帧"就有宽高
Android 的界面更新走的是请求式遍历——invalidate / requestLayout 只是打标记（mPrivateFlags 上置位并设置 PFLAG_DIRTY），真正的工作由 ViewRootImpl 在下一帧的 doTraversal() → performTraversals() 完成：
Choreographer.doFrame
└─ ViewRootImpl.doTraversal()
├─ performTraversals()
│ ├─ measure() → 递归测量，得出 mMeasuredWidth/Height
│ ├─ layout() → 递归布局，调用 onLayout，得出 mLeft/mTop/mRight/mBottom
│ ├─ setFrame() → 尺寸真正写入 View（width/height 此时才有效）
│ └─ draw() → 绘制
└─ Choreographer 回调（帧内可注册的 doFrame 回调）
而 View.post(Runnable) 的实现分两条路径：
- 已 attach 的 View：走
mAttachInfo.mHandler.post(action)，直接进主线程 MessageQueue 尾部。 - 未 attach 的 View：走
ViewRootImpl.mRunQueue（HandlerActionQueue），把任务挂起，等dispatchAttachedToWindow时再逐个 post 到 Handler。
关键就在这里：post 的任务排在队列尾部，而 performTraversals 是在当前这次消息分发（doFrame）中同步跑完的。所以哪怕这个 Runnable 在"下一次 doFrame 之前"被处理，布局也已经完成。这解释了为什么 onCreate 里 post 之后能读到宽高。
但要注意一个细节：post 的 Runnable 执行完，下一帧的 performTraversals 还没跑。 也就是说 post 回调里读到的是"上一帧测量出的尺寸"——如果这一帧的 requestLayout 改动了尺寸，post 读到的是旧值。这一点是很多"post 里读宽高还是不对"问题的真因。
最常见的坑是
第一层坑：在子线程调 view.post。
mAttachInfo.mHandler 是在主线程的 ViewRootImpl 里创建的，它的 Looper 是主线程的。子线程调 view.post 不会崩（内部有 mAttachInfo 判空，未 attach 时进 mRunQueue），但 attach 之后在子线程 post，任务会进主线程队列，回调在主线程执行——真正的问题是在子线程 post 后立刻 postValue 式地期望同步拿到结果，或者更常见的：有人在子线程里 view.post { view.visibility = ... } 以为绕过了"子线程改 UI"的限制，其实回调虽在主线程，但 post 本身在子线程调用属于误用，且若该 View 尚未 attach，任务会在 attach 时才执行，时机完全不可控。规范是 UI 相关一律在主线程调用 post，并用 Looper.myLooper() == Looper.getMainLooper() 断言校验。
第二层坑：对未 attach 的 View 调 post，任务永不执行。
这是最隐蔽的坑。mRunQueue 的任务只有在 dispatchAttachedToWindow 时才会被 flush。如果这个 View 从未被添加到窗口（比如在 onCreate 里创建了一个 View 但没加进视图树，或者在 onDetachedFromWindow 之后再 post），任务就长期挂在队列里，Runnable 持有的对象也一起泄漏。排查方法很简单：在回调里打一行日志，没打出来就是没 attach。 规范是未 attach 的 View 用 addOnAttachStateChangeListener 或改用 doOnLayout 之类的替代方案。
第三层坑：post 里读宽高，但这一帧刚好触发了二次 requestLayout。
典型场景是 onCreate 里 post 中读取宽高，然后据此做一次 requestLayout 或改 layoutParams。因为 post 读到的是上一帧的结果，二次布局后尺寸变了，后续逻辑全错。 更隐蔽的是父容器在 onLayout 里有"测量后修正"的逻辑（onMeasure 里根据内容改 measuredHeight，再 measure 一次），最终尺寸在同一次 traversals 的第二次测量才定。规范是需要"最终尺寸"时用 addOnLayoutChangeListener 或 doOnLayout，它们保证的是布局完成后的回调。
还有一个更隐蔽的坑：post 之后拿到的宽高被 post 里的操作改变，但代码按旧值继续算。 典型是"根据宽高计算宫格列数 → 设置 LayoutParams → 再次触发布局"，在布局期间自我触发布局可能造成连续两到三次 traversals。规范是尺寸相关的最终计算放到布局之后的回调里，且只做一次。
代码里见真章
先看一个把 post 的时序讲清楚的最小验证：
class TimingActivity : Activity() {
private lateinit var target: View
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val root = FrameLayout(this).apply {
id = ID_ROOT
addView(TextView(this@TimingActivity).apply {
text = "内容"
layoutParams = FrameLayout.LayoutParams(WRAP_CONTENT, WRAP_CONTENT)
}, FrameLayout.LayoutParams(WRAP_CONTENT, WRAP_CONTENT))
}
setContentView(root)
target = root.getChildAt(0)
// 时点 A：onCreate 中直接读，宽高必为 0
Log.d("Timing", "A onCreate 直读: w=${target.width} h=${target.height}")
// 时点 B：onCreate 里 post —— 排在下一帧，布局已完成
target.post {
Log.d("Timing", "B post 回调: w=${target.width} h=${target.height} " +
"left=${target.left} right=${target.right}")
}
// 时点 C：post 里再 post —— 再下一帧
target.post {
Log.d("Timing", "C 二次 post: w=${target.width} h=${target.height}")
target.post {
Log.d("Timing", "D 三次 post: w=${target.width} h=${target.height}")
}
}
}
override fun onAttachedToWindow() {
super.onAttachedToWindow()
// View 尚未 attach 时 post，任务进 mRunQueue，attach 时才 flush
target.post {
Log.d("Timing", "E onAttachedToWindow 中的 post: w=${target.width}")
}
}
companion object {
private const val ID_ROOT = 0x7f0a0001 }
}
这段代码值得盯三处：第一处，时点 A 的宽高必为 0，因为 measure 尚未发生；第二处，post 回调里 width/height/left/right 都有值，说明 setFrame 已执行；第三处，onAttachedToWindow（Activity 的）里 post 能立即执行，因为此时 ViewRootImpl 已经 attach，任务直接进 Handler 队列。
现代写法应该优先用 doOnLayout 与 doOnPreDraw，它们的语义比 post 精确：
// androidx.core.view：布局完成后回调，语义明确
target.doOnLayout {
v ->
// 保证此时 mLeft/mRight/mTop/mBottom 已经写入
Log.d("Layout", "doOnLayout: ${v.width} x ${v.height} at (${v.left}, ${v.top})")
}
// 布局完成、绘制之前：适合"必须在第一帧显示前改属性"的场景
target.doOnPreDraw {
v ->
// 此时可以安全地修改会影响本帧绘制结果的属性
v.alpha = 0.99f
v.animate().alpha(1f).setDuration(120).start()
}
// 通用监听：任意一次布局变化都会回调
target.addOnLayoutChangeListener {
v, left, top, right, bottom, oldLeft, oldTop, oldRight, oldBottom ->
if (left != oldLeft || top != oldTop) {
Log.d("Layout", "位置变化: ($oldLeft,$oldTop) -> ($left,$top)")
}
}
这段代码值得盯三处：第一处，doOnLayout 的一次性语义（内部用 OneShotPreDrawListener 与 addOnLayoutChangeListener 组合，只触发一次）；第二处，doOnPreDraw 在绘制前执行，适合改 alpha、translation 等影响本帧渲染的属性；第三处，addOnLayoutChangeListener 是持续监听，需要自己判断是否是首次布局或尺寸真的变了。
未 attach 的 View 用 post 会失效，必须走另一条路：
// View 尚未 attach：post 进 mRunQueue，永不执行
val detached = MyView(this)
// 方案一：attach 状态回调，一次性
detached.addOnAttachStateChangeListener(object : View.OnAttachStateChangeListener {
override fun onViewAttachedToWindow(v: View) {
Log.d("Attach", "attach 后尺寸=${v.width}")
v.removeOnAttachStateChangeListener(this) // 一次性监听必须移除，否则持有外部引用
}
override fun onViewDetachedFromWindow(v: View) = Unit
})
// 方案二：手动测量（不依赖 attach）
detached.measure(
View.MeasureSpec.makeMeasureSpec(360, View.MeasureSpec.EXACTLY),
View.MeasureSpec.makeMeasureSpec(0, View.MeasureSpec.UNSPECIFIED)
)
val measuredWidth = detached.measuredWidth // 手动测量后读 measuredWidth
// 关键：手动测量不写 width/height，只写 measuredWidth/Height
// 方案三：直接用 measuredWidth 而非 width
Log.d("Measure", "measured=${detached.measuredWidth} vs width=${detached.width}")
这段代码里最容易踩的是方案三的对比——measuredWidth 是测量阶段的产物，width 是布局阶段的产物。post 之所以能拿到 width，正是因为 setFrame 已经执行。理解这一点，整条时序就通了。
post 读到的是"上一帧尺寸"这个坑，要用 doOnLayout 规避：
// 有问题的写法：post 读到的是上一帧尺寸，本帧若改变尺寸则逻辑全错
target.post {
val w = target.width // 可能不是最终值
val cols = if (w > 600) 3 else 2 // 基于不准确的宽度算列数
target.layoutParams = target.layoutParams.apply {
width = w / cols }
// 触发新的一轮布局 → post 里的 w 已经不是最新值
}
// 稳健写法：等布局完成后再算，且只算一次
target.doOnLayout {
v ->
val w = v.width // 此刻的布局结果
if (w <= 0) return@doOnLayout // 兜底：仍为 0 说明还没真正布局
val cols = if (w > 600) 3 else 2
if (cols == lastCols && v.tag == cols) return@doOnLayout // 幂等：避免重复设置触发循环
lastCols = cols
v.tag = cols
v.layoutParams = (v.layoutParams).apply {
width = w / cols }
}
private var lastCols = 0
这段代码的关键是幂等判断——doOnLayout 在每次布局变化时都会触发，若不做"值没变就不设置"的判断，设置 LayoutParams 本身会触发新布局，从而在 doOnLayout 里无限循环。这是"用 doOnLayout 改布局导致卡死"这类问题的真因。
面试中的经典考点
问：View.post 的实现原理是什么？为什么能拿到宽高？
答：分两条路径。已 attach：走 AttachInfo.mHandler.post(action)，Runnable 进入主线程 MessageQueue 尾部；未 attach：走 ViewRootImpl.mRunQueue（HandlerActionQueue），在 dispatchAttachedToWindow 时 flush。能拿到宽高的原因是时序——post 排在下一帧，而 measure/layout/setFrame 在当前帧的 performTraversals 中同步完成，回调执行时尺寸已写入。能主动说出"读到的是上一帧的尺寸"这一点，说明真调试过。
问：post 和 postDelayed 在这里有什么区别？
答：post 读到的是"当前这次布局已完成后的尺寸"；postDelayed 因为延后到 when 时刻，中间可能发生新的布局，读到的是那之后的尺寸。所以post 适合"布局刚完成，读一次尺寸"；postDelayed 绝不适合这类用途——这是"用 postDelayed 读宽高结果不对"的原因。规范是读尺寸一律用 doOnLayout，不要用 postDelayed。
问：除了 post，还有哪些保证"布局后"的回调？
答：四类，各有适用场景。① addOnLayoutChangeListener——布局变化时持续回调，需自己判首次；② doOnLayout（androidx）——一次性布局后回调，语义最清晰；③ doOnPreDraw——绘制前回调，可改影响本帧渲染的属性；④ ViewTreeObserver.OnGlobalLayoutListener——整棵树布局完成时回调，注意它会在每次布局都触发，且在 API 16 以下需要在移除时 removeOnGlobalLayoutListener。能把这四个的语义差别讲清，说明不是"只知道 post"。
问：为什么 onCreate 里直接测量拿到的都是 0？
答：因为 measure 由 ViewRootImpl 在 setContentView 之后、下一帧的 performTraversals 中发起。setContentView 只是把 DecorView 的内容挂上，当次调用栈内没有任何测量发生。所以 onCreate、onStart、onResume 里直接读宽高都是 0——这是"三处都打印宽高"实验的结论。规范是要尺寸就走上面的四种回调之一。
问：post 会被执行吗？存在哪些例外？有什么例外？
答：三种例外必须能说出来。① 未 attach 的 View——进 mRunQueue，若从未 attach 则永不执行；② 已 detach 的 View——mAttachInfo 被置空后再 post 同样进 mRunQueue，需要重新 attach 才会 flush；③ 子线程调用——任务虽最终在主线程执行，但调用时机不可控，且若该 View 此刻未 attach，flush 时机取决于何时 attach。主动补这三条，是这题"深度"的直接体现。
落到项目里怎么做
一条能写进规范的红线：读尺寸一律用 doOnLayout（或 addOnLayoutChangeListener），禁用 post/postDelayed 取宽高。 理由是语义精确、时机明确、不依赖队列推断。
配套实践三条：① 自定义 View 内部对外暴露尺寸时在 onSizeChanged 回调而非 post，因为 onSizeChanged 就是"尺寸变化的官方通知点"；② 在 doOnLayout 里改布局必须加幂等判断（值未变则不设置），否则会陷入"设置 → 布局 → 回调 → 设置"的循环；③ 涉及依赖尺寸的绘制（如自适应宫格、圆角矩形、渐变方向）一律在 onSizeChanged 里重算 Paint/Shader 参数，不要在 onDraw 里现算。
给正在准备面试的你
这题的答法要落到"时序 + 双路径 + 失败模式"这条主线。推荐这条线：先讲 performTraversals 同步完成 measure/layout/setFrame，再讲 post 排到下一帧，于是能读到尺寸 → 补双路径（mHandler vs mRunQueue）→ 讲三个失败模式：未 attach 永不执行、子线程调用、读到的是上一帧尺寸 → 落到"doOnLayout + 幂等判断"这条规范。能被追问到"用 postDelayed 读宽高为什么不对"并答出"中间可能已有新布局"，说明真被这个问题坑过；能主动列出三种 post 不执行的情况，说明对实现细节有实感。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Handler-内存泄漏：为什么匿名内部类最危险
下一篇预告：属性动画与估值器：插值曲线如何驱动画面
有任何问题欢迎在评论区留言交流。
