先把结论放在前面：一次 View 的完整绘制要过三关——measure（定大小）、layout（定位置）、draw（画像素），由 ViewRootImpl 驱动，Choreographer 决定时机。 三个必须张口就来的判定：requestLayout 走三关全流程、invalidate 只走 draw 一关、postInvalidate 支持子线程。这三句话答完，后面所有细节都是挂在这条主线上的。
View 绘制流程看起来简单，追问起来全是细节。这篇把它掰开揉碎，从概念到坑点过一遍。
一次帧的完整时间线
从手指抬起（或动画推进）到像素上屏，顺序是这样的：
Choreographer.doFrame()
├─ performTraversals() // ViewRootImpl 内部
│ ├─ requestLayout() 被标记？→ 走 measure + layout
│ ├─ 计算下一帧目标时间（vsync 对齐）
│ └─ scheduleTraversals() → 下一帧执行
│
├─ performMeasure() // 三关之一：定大小
├─ performLayout() // 三关之二：定位置
└─ performDraw() // 三关之三：画像素
└─ draw() → onDraw() + 绘制子 View
关键点：measure 与 layout 遍历的是同一棵树，但 draw 有裁剪优化——ViewGroup.draw 会先 clipChildren 判断哪些子 View 需要画，若某个子 View 完全在裁剪区外且 setWillNotDraw(false)，就直接跳过它的 onDraw。这也是为什么"自定义 View 放容器里不显示"要查 clipChildren。
Choreographer 的作用要说清：它把一帧的时间切成 input / animation / traversal / commit 四个阶段，并把"计算耗时"反馈到 FrameMetrics，让系统能统计卡顿率。"一帧 16.6ms"的说法并不完整——正确表述是"目标 vsync 间隔内要完成遍历、绘制、合成并上屏，超时就掉帧"。
最常见的坑是
在 onLayout 里改尺寸却不调 requestLayout，布局与实际状态不一致。
onLayout 的语义是"给子 View 定位"，在父 View 的 onLayout 里调用 child.layout() 去改子 View 尺寸，在很多情况下不会触发新的 measure/layout 流程，结果是父 View 记录的尺寸与子 View 实际占用的不一致，下一次布局时又被打回，表现为界面偶发错位或滚动范围算错。
规范做法是分清两种场景：
// 场景一：需要尺寸变化引发重新布局 → 主动 requestLayout
override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
val w = MeasureSpec.getSize(widthMeasureSpec)
// 依赖可用宽度的场景：算出高度后要重算
val h = computeHeightByWidth(w)
setMeasuredDimension(w, h) // 写回，避免被 EXACTLY 覆盖
}
// 场景二：只是轻微偏移、不影响尺寸 → 不需要重新布局
override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {
child.layout(l + offset, t, r + offset, b + offset) // 手工定位
}
还有一个更隐蔽的坑：围绕 View 绘制流程协作时最有效的一条约定，是把适用前提显式写在代码旁，让 review 有据可依。落到具体就是"刷新 API 使用约定"：
| 需求 | 用什么 | 常见误用 |
|---|---|---|
| 尺寸/位置要变 | requestLayout() |
用 invalidate 后手工改尺寸，布局系统不知情 |
| 只重画内容（颜色、文字、图片） | invalidate() |
用 requestLayout 造成整树重新遍历 |
| 子线程刷新 UI | postInvalidate()（内部切主线程） |
直接在子线程调 invalidate()，抛 CalledFromWrongThreadException |
| 布局发生改变时做联动 | addOnLayoutChangeListener 或自定义 onLayout |
在 onMeasure 里改兄弟 View 的属性 |
再加一条高频误用：invalidate 频繁调用但内容没变。 典型场景是进度条每秒更新一次、动画每帧都调 invalidate，而内容其实一致。修法是先判断值是否真的变了再刷新——这也是 StateFlow 配 distinctUntilChanged 的价值所在。用数据层的去重挡住无效刷新，比在 View 层优化更彻底。
三条高频追问
问：requestLayout、invalidate、postInvalidate 三者区别？
requestLayout 标记"布局需要重算"，会走 measure + layout + draw 三关（ViewRootImpl 下一次 performTraversals 统一处理）；invalidate 只标记"需要重画"，跳过 measure/layout 直接进 draw；postInvalidate 内部把请求投递到主线程的 ViewRootImpl.Handler，因此可以在子线程调用。延伸问题：会死循环吗？ 不会——requestLayout 在同一帧内只会被处理一次（有个"布局请求已消费"的标记），所以"onLayout 里 requestLayout"虽不推荐但不会无限循环，只是会把下一帧也占掉。
问：为什么 measure 可能被调用多次？
因为 onMeasure 内部调 measureChildWithMargins 时可能触发子 View 再 measure，而 LinearLayout 的 weight、RelativeLayout 的依赖链（layout_above 等）会引发二次测量（measure 阶段就要用 measureChildBeforeLayout 推算位置）。更深一层：LinearLayout 的 weight 重测会把 useLargestChild 的策略触发成二次完整 measure。优化手段是用 ConstraintLayout 替代嵌套权重布局——它用一次求解代替多轮测量，这也是它性能优势的真实来源。
问：自定义 View 的 onDraw 没被调用？
四种情况：① 没调 setWillNotDraw(false)——ViewGroup 默认 willNotDraw = true 会跳过自身 onDraw；② View 是不可见的（GONE/透明/尺寸 0）；③ 父容器 clipChildren 把它裁掉了；④ 被 ViewGroup 的绘制优化跳过（子 View 完全在裁剪区外）。排查顺序按这个列表走，几乎都能命中。
问：帧率与流畅度的关系？
60Hz 屏幕每帧预算约 16.6ms，120Hz 约 8.3ms。但卡顿的真正瓶颈通常不在 onDraw 本身，而在"measure/layout 的重复测量"与"主线程被非绘制工作占用"（比如在主线程做 JSON 解析、布局里做 I/O）。所以定位卡顿要先分清是"绘制耗时"还是"布局耗时"还是"业务耗时"——FrameMetrics 与 Choreographer 的 trace 都能给出答案。
落到项目里怎么做
一条能直接落地的规则：状态变更 → 选对刷新 API → 用数据层去重挡无效刷新。 三步走完，View 层的性能问题基本消失。
配套实践三条：① 统一刷新入口：所有 UI 更新经过一个 render(state) 方法，内部先 if (newState == oldState) return；② 布局层面用 ConstraintLayout 减少嵌套层级与 weight 重测；③ 接 FrameMetrics 采集卡顿数据，把"掉帧率"纳入性能看板——没有数据的性能优化是猜。
给正在准备面试的你
这题要答成"一张地图 + 三个判定 + 四类排查"。推荐这条线：先画一遍 Choreographer → performTraversals → measure/layout/draw 的时间线 → 立起三个判定（requestLayout 全流程 / invalidate 只重绘 / postInvalidate 可子线程）→ 讲为什么 measure 会多次（weight 重测、ConstraintLayout 一次求解）→ 落到 onDraw 不被调用的四种情况排查 → 最后用"刷新 API 约定表 + 主线程纪律"收尾。能被追问到帧率与 FrameMetrics 还不慌，这题就稳了。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：进程优先级与进程回收：ADJ-与查杀顺序
下一篇预告：MeasureSpec-与测量模式：三种模式的取舍
有任何问题欢迎在评论区留言交流。
