企业官网建设流程全解析

做Android开发，尤其是做界面优化的时候，心里没底的一个词经常是 ViewRootImpl。它不算一个日常会 new 的类，甚至很多人在三年的开发里都没直接调用过它，但它几乎参与了从布局到屏幕的每一次刷新，也掌控着你点一下屏幕之后事件怎么走到 View。如果只用一个视角去看它，可以理解成它是 WindowManager 和 View 树之间的硬连接：WindowManager 负责把窗口注册给系统，ViewRootImpl 负责在 App 这边把所有 View 的测量、布局、绘制以及输入都调度起来。

这篇我打算把 ViewRootImpl 的原理拆开讲一遍，包括它是怎么被创建出来的、一次 measure/layout/draw 是怎么被驱动的、Vsync 和 Choreographer 在里面扮演什么角色、输入事件是怎么通过它分发的，以及我们日常开发里遇到的那些“拿不到宽高”“掉帧”“requestLayout 被滥用”的问题，本质上都出在哪个环节。适合刚接触 Android 渲染机制的同学，也适合做了几年开发但想系统梳理 View 体系的同学。

1. ViewRootImpl 到底是个什么角色

1.1 为什么平时写代码几乎碰不到它

ViewRootImpl 不是 public API，它藏在android.view包底下，通过 AOSP 源码或者 Android Studio 的反编译工具能看到它的真容。常规开发中，我们接触最多的其实是 Activity 里的 setContentView，但 setContentView 只是把布局文件解析成 View 树，然后挂到 PhoneWindow 内部的 DecorView 上。这一步做完，屏幕上什么都没有，因为还有最后一个关键动作没做：把 DecorView 通过 WindowManager.addView 注册给系统。

一旦调用了 addView，WindowManagerGlobal 会创建 ViewRootImpl 对象，并把它和 DecorView 绑定在一起。从这一刻开始，View 的测量、布局、绘制，以及触摸事件、KeyEvent、Window 焦点变化、Surface 的创建和销毁，全部都由 ViewRootImpl 接管。它名字里的 Root 不是白叫的，它确实就是 View 树的“根节点管理员”。但注意，它不是 View，它实现了 ViewParent 接口，是 View 树逻辑上的父亲，而不是屏幕上的一个 View。

我见过不少同学把 ViewRootImpl 和 DecorView 混在一起说。实际上 DecorView 是 View 树最顶层的那个 FrameLayout，ViewRootImpl 是控制整个树的控制器。你在 ViewRootImpl 里能看到mView，这个 mView 就是 DecorView；你在 DecorView 里也能通过 getViewRootImpl 拿到 ViewRootImpl。两者是互相引用、互相配合的关系。

1.2 它与 Window、View、WindowManager 的关系

Android 的 Window 概念很多人一直搞不清楚。简单说，Window 是一个抽象策略类，PhoneWindow 是它的具体实现，里面装着一个 DecorView。DecorView 本身不直接出现在屏幕上，它必须通过 WindowManager 这个接口被加进 WindowManagerService 的管理范围。WindowManager.addView 走到底层，其实是创建了一个新的窗口，而这个窗口的“代理者”就是 ViewRootImpl。

所以可以画出这么一条链路：PhoneWindow 里有一个 DecorView，WindowManagerGlobal 给这个 DecorView 配一个 ViewRootImpl，ViewRootImpl 通过 WindowSession 与系统进程的 WindowManagerService 通信。WindowManagerService 最终会为这个窗口分配 Surface，并把它加入到系统中负责合成的 SurfaceFlinger 流程里。App 进程能拿到的就是一块用来绘制内容的画布，也就是 Surface。ViewRootImpl 负责把 View 树画到这块 Surface 上。

还要注意一个细节：一个 Activity 一般只有一个 Window、一个 DecorView、一个 ViewRootImpl。但如果是 PopupWindow、Dialog、Toast，它们都是独立 Window，也就都有各自的 ViewRootImpl。也就是说，一个应用进程里可以同时存在多个 ViewRootImpl，它们各自管理自己的 View 树，互不干扰。WindowManagerGlobal 里维护了一个ArrayList<ViewRootImpl> mRoots，专门用来追踪这些根。

2. 一个 View 是怎么被塞进屏幕的：addView 与 setView

2.1 WindowManager.addView 的入口逻辑

我们从 ViewRootImpl 的出生开始聊。WindowManager 的真正实现是 WindowManagerImpl，它的 addView 会转交给 WindowManagerGlobal.addView。WindowManagerGlobal 里做的事情很明确：检查参数合法性、创建 ViewRootImpl、把 View 和布局参数保存起来、调用 root.setView 把窗口加进去。

这里有三个关键对象：

一个是ViewRootImpl，它继承 Handler 并实现 ViewParent 接口，内部持有 Choreographer、WindowSession、Display 等关键对象。另一个是ViewRootHandler，它是 ViewRootImpl 的内部 Handler，主线程所有和窗口相关的消息都通过它派发，比如配置变化、窗口焦点、输入法可见性等。还有一个是WindowSession，它是 App 进程连接 WindowManagerService 的 Binder 代理，所有窗口操作都通过它跨进程完成。

初始化 ViewRootImpl 时，还会创建 ViewRootImpl 的 AttachInfo。AttachInfo 是 View 和 ViewRootImpl 之间传递信息的对象，View 能拿到 ViewRootImpl、Display、WindowToken、Surface 等信息，就是靠 AttachInfo。你写自定义 View 时用到的getAttachInfo()，实际上就是 ViewRootImpl 设置进去的。

2.2 setView 内部做了什么关键初始化

setView 是 ViewRootImpl 一切工作的起点，这一步做的事情非常多，我给你梳理一下核心逻辑。

第一件事是检查线程。ViewRootImpl 要求在创建它的线程上进行窗口操作，通常就是主线程。如果你在子线程里调 WindowManager.addView，或者操作 View 树，就会抛出CalledFromWrongThreadException。这块儿的判断逻辑就在 setView 前段。

第二件事是把mView指向传入的 DecorView，调用mView.assignParent(this)，让 View 树把自己的 parent 指向 ViewRootImpl。这样 View 的 requestLayout、invalidate 请求才能一级一级传到 ViewRootImpl。

第三件事是通过mWindowSession.addToDisplayAsUser把窗口真正添加到 WindowManagerService。这个方法会跨进程走一遍，最后通过 Binder 返回一个 WindowToken，还会为这个窗口创建输入事件用的 InputChannel。WindowManagerService 在为窗口分配 Surface 时，需要知道这个 View 的物理尺寸、布局参数、焦点模式等，这些全部由 ViewRootImpl 在 addToDisplayAsUser 时传过去。

第四件事是建立输入事件通道。setView 里会创建一个 InputEventReceiver，它的底层是 InputChannel 和 C++ 的 InputConsumer。系统 InputDispatcher 检测到屏幕触摸事件后，会根据窗口位置找到对应的 Window，然后通过 InputChannel 把事件发到 App 进程。App 进程这边接收事件的入口，就是这个 InputEventReceiver。

第五件事是调用requestLayout()，触发第一次 measure/layout/draw。这也是为什么你明明只是在 addView 之后啥都没干，屏幕却能把内容刷出来的原因。当然，第一次遍历和后续的遍历略有区别，因为窗口的 Surface 往往是在第一次 performTraversals 过程中才真正创建好的。

2.3 什么时候窗口才真正可见

很多人以为 addView 之后窗口立刻可见，其实不完全对。addView 只是把窗口加入 WindowManagerService，但窗口真正显示出来，要等 ViewRootImpl 完成第一次 performTraversals，且 WindowManagerService 确认这个窗口已经完成绘制。

这里有一个关键点：ViewRootImpl 在第一次遍历的时候，会调用relayoutWindow去向 WindowManagerService 申请 Surface。如果这次 relayout 返回的 Surface 是有效的，ViewRootImpl 才会开始绘制内容。等绘制完成，再通过 SurfaceFlinger 合成到屏幕上，用户才能真正看到。所以从 Activity 启动到第一帧画面，中间隔着一个跨进程往返、一次完整遍历和一个合成周期。

这也是为什么在 onCreate 里调用view.getWidth()会得到 0。因为 ViewRootImpl 的第一次遍历根本没跑完，View 还没被测量和布局，宽度自然是 0。想要在首次布局后拿宽高，最常用的方法是用view.post()，或者注册OnGlobalLayoutListener，本质都是等 performTraversals 执行完后再去读取。

3. 核心循环：performTraversals 如何组织 measure/layout/draw

3.1 从 requestLayout 到 performTraversals 的触发链

ViewRootImpl 最核心的方法就是 performTraversals。整个 View 渲染体系几乎是围绕这个方法转的。我们平时在代码里调用requestLayout()，最后都会进入这个方法，它不是立刻执行的，而是先走一条异步链路，避免一帧之内重复执行多次。

requestLayout 的调用链是这样的：View.requestLayout 先把自己标记为需要布局，然后向上调用 parent 的 requestLayout，一直传到 ViewRootImpl。ViewRootImpl.requestLayout 内部检查线程，然后调用scheduleTraversals()。scheduleTraversals 会往 Choreographer 里 post 一个 TraversalRunnable，同时往主线程 MessageQueue 里发一个同步屏障，保证在下一帧开始之前，遍历任务能被优先执行。

等到 Choreographer 收到 Vsync 信号，会回调我们注册的 TraversalRunnable，此时才真正执行doTraversal()，再调用 performTraversals。这整个机制的目的就是要把多次 requestLayout 合并到一帧里处理，防止每个 View 自己独立刷新导致同一帧被多次遍历。

3.2 测量与布局的约束条件

performTraversals 里面对 measure 和 layout 的处理，比很多人想象中复杂。它不是简简单单调一次 measure 和 layout 就结束了，而是需要考虑窗口尺寸、WindowManager.LayoutParams 的变化、系统栏颜色变化、软键盘弹出等大量场景。

整体流程上，ViewRootImpl 会先拿到 DecorView，然后根据 WindowManager.LayoutParams 计算出 Window 的期望尺寸。这里的核心是 ViewRootImpl 会通过getRootMeasureSpec生成 DecorView 的 MeasureSpec，关键还是和 DecorView 的 LayoutParams 有关。DecorView 的 LayoutParams 一般不是WRAP_CONTENT就是MATCH_PARENT，这些会决定根 MeasureSpec 的精确模式。

接下来是 measure 过程：ViewRootImpl 调用mView.measure(childWidthMeasureSpec, childHeightMeasureSpec)，DecorView 再把自己的 MeasureSpec 分发给子 View，一层层往下传递。这里 Reflect 在 MeasureSpec 里有个经典问题：为什么说 MatchParent 是 EXACTLY，WrapContent 是 AT_MOST，因为 parent 已经确定了自身的尺寸约束，子 View 能做的是在这个约束范围内取值。

layout 过程也是从 DecorView 开始，调用mView.layout(0, 0, mWidth, mHeight)。这里的 mWidth 和 mHeight 是窗口实际宽高，通常通过 relayoutWindow 从 WindowManagerService 拿到的 frame 里计算出来。如果你在自定义 View 的 onLayout 里打日志，看到的坐标就是在这个 mWidth/mHeight 范围内去分配子 View 的位置。

3.3 绘制阶段与 Surface

绘制阶段和 measure/layout 有很大差别。测量和布局是在主线程同步执行的，而绘制从 Android 5.0 引入硬件加速之后，就走到了 RenderThread。ViewRootImpl 会先判断是用软件渲染还是硬件渲染，通常情况下都是硬件渲染。

硬件渲染的核心是 DisplayList 和 RenderNode。View.onDraw 里的 drawText、drawRect 等操作会先被记录到 RenderNode 的 DisplayList 中，而不是立刻画到屏幕上。等到整棵 View 树的 DisplayList 构建完成，ViewRootImpl 会把这些数据提交给 HardwareRenderer，再由 RenderThread 生成 GPU 指令并提交给 SurfaceFlinger 合成。

这里有一个优化点：如果只是某个 View 调用了 invalidate，ViewRootImpl 不会把整棵树重新执行 measure 和 layout，而是只触发一次 draw。通过 ViewRootImpl 内部的mFullRedrawNeeded和 dirty 区域判断，尽可能只重绘变化的区域。所以你在自定义 View 里只有 invalidate 时性能还好，但如果你调用 requestLayout，那就是整个树的重新测量和布局，成本完全不是一个量级。

4. Vsync、Choreographer 与消息屏障：刷新机制背后的调度器

4.1 Choreographer 的 FrameCallback

ViewRootImpl 本身不直接监听硬件 Vsync，它把刷新调度工作交给 Choreographer。Choreographer 是 Android 系统提供的一个统一定时器，专门用来处理 UI 帧。它内部有一个 FrameDisplayEventReceiver，本质是一个 DisplayEventReceiver，会从 SurfaceFlinger 那边接收 Vsync 事件。

Choreographer 按照回调的优先级分成几类：输入事件、动画、View 遍历、绘制提交。这个顺序很重要，因为一帧从输入到布局再到绘制，是有明确的因果关系的。如果你在动画回调里改布局，那这一帧可以立刻去执行遍历；如果你在遍历回调里又请求了一个新动画，那不是这一帧能处理的，要等下一帧动画回调。

ViewRootImpl 的scheduleTraversals()实现里，关键一步就是调用mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null)。也就是说，ViewRootImpl 把“执行遍历”这件事注册到 Choreographer 的遍历阶段。Vsync 一到，Choreographer 按顺序执行回调，最终触发 performTraversals。

4.2 同步屏障与异步消息

这里必须说一个容易忽略的机制：同步屏障。MessageQueue 里有一个postSyncBarrier()方法，插入屏障之后，所有同步消息都不会被执行，只有标记为异步的消息能绕过屏障先执行。

scheduleTraversals 中除了往 Choreographer 注册回调，还会调用mHandler.getLooper().getQueue().postSyncBarrier()插入同步屏障。这样做是为了保证当前 MessageQueue 里哪怕积压了不少同步消息，在 Vsync 到来后也能先执行遍历任务，避免渲染被其他主线程任务拖住。等 doTraversal 执行完后，再移除同步屏障。

这个机制也为 Choreographer 的输入派发提供了保底：即使主线程很忙，只要 Vsync 信号到了，遍历和绘制相关的异步消息仍然能插队执行。这也是为什么我们在排查卡顿的时候，经常能看到主线程消息队列里有大量耗时消息，但 UI 不一定立刻卡死，因为系统会想方设法让关键渲染任务先跑。

4.3 掉帧如何产生

掉帧从原理上很好解释：一帧的预算大约是 16.6ms，如果主线程在 Vsync 到来时还在处理上一个耗时任务，Choreographer 的遍历回调不能及时执行，那么这一帧就会被跳过，等到下一个 Vsync 再刷新。表现就是用户看到的画面卡顿了一下。

具体到 ViewRootImpl 里，掉帧有两个常见来源。第一个是 performTraversals 本身耗时太长，比如布局嵌套太深、measure 有大量重复计算、onDraw 里有昂贵的绘制操作。第二个是遍历回调被主线程其他消息阻塞，比如 IO、锁竞争、Bitmap 解码。不管哪种，最终都会导致 Choreographer 无法在 16.6ms 内完成一帧的工作。

用 Systrace 抓数据时，能看到 Choreographer 的 Frame 标记，以及主线程上各个消息的执行区间。你如果发现界面上某一帧的 Choreographer 回调迟迟没开始，多半是前面的消息占了时间；如果开始了但 performTraversals 内部耗时巨大，那就要回来看 View 树本身的问题。

5. 输入事件从系统到 View 的旅程

5.1 InputEventReceiver 与 InputChannel

ViewRootImpl 不只是负责绘制，它还负责接收系统输入事件。系统侧的 InputDispatcher 会通过 InputChannel 把 MotionEvent 和 KeyEvent 发送到 App 进程，App 进程通过 ViewRootImpl 在 setView 里创建的 InputEventReceiver 接收这些事件。

InputEventReceiver 并不是 ViewRootImpl 内部直接处理事件，它会把收到的 InputEvent 包装成队列里的一个任务，然后调用 InputStage 去处理。ViewRootImpl 里定义了一套 InputStage 链表结构，相当于一个责任链模式：事件从底层的 NativeInputStage 一路向上走，经过 ViewPreImeInputStage、ViewPostImeInputStage 等，最后交付给 DecorView。

这套 Stage 机制的好处是可以在事件真正触达 View 之前做各种预处理，比如焦点调整、触摸模式、坐标转换、长按判断等。每个阶段都有机会消费或修改事件，而不需要直接改 View 的 dispatchTouchEvent。

5.2 事件在 ViewRootImpl 中的分阶段处理

我们以触摸事件为例。当 ViewRootImpl 收到一个 DOWN 事件时，它首先会经过 ViewPreImeInputStage，这个阶段主要处理输入法相关的事件和焦点变化。之后进入 ViewPostImeInputStage，这里会调用mView.dispatchPointerEvent(e)，也就是调用了 DecorView 的 dispatchTouchEvent。

从 DecorView 开始，事件会往 View 树下面按 hit test 结果传递，最终由某个子 View 的 onTouchEvent 消费。这里需要特别提一下：ViewRootImpl 会维护触摸事件的目标 View。一个 DOWN 事件确定了 target 之后，后续的 MOVE 和 UP 事件都会尽量发给同一个 target，除非子 View 树内部自己改变了事件分发逻辑，这是 Android 触摸事件一套比较成熟的分发机制。

输入事件和渲染有个联动：如果用户在触摸后立刻触发了属性动画或者调用了 invalidate，那么这一帧的输入事件回调是排在 Choreographer 回调之前的，这样可以保证触摸反馈能够在同一帧内完成。这也是为什么输入通常有较低的延迟，但一旦主线程忙，输入事件被阻塞，用户会感觉“点上去没反应”，其实事件早就到了，只是主线程没来得及执行。

5.3 输入延迟的排查点

如果碰到屏幕点击响应变慢，可以从 ViewRootImpl 这条链路去排查。第一步是看 InputEventReceiver 有没有及时收到事件，这个可以在 systrace 里确认，会发现输入事件的时间戳和 Choreographer 回调的时间戳有明显差距。

第二步是看主线程消息队列是不是有长任务，因为 InputEventReceiver 收到事件后，最终是通过主线程 Handler 派发的。如果你在主线程里做了大文件读写、DB 查询、JSON 解析，那么事件就算到了 ViewRootImpl，也要排队等这些任务完成。

第三步是看 View 树的分发效率。如果一个 View 的 onInterceptTouchEvent、onTouchEvent 里有耗时逻辑，会导致事件处理本身变慢。这里还有个容易踩的坑：在 onTouchEvent 里调用 requestLayout，每移动一下手指就让整棵树重新布局一遍，卡顿基本是肉眼可见的。

6. 老生常谈的坑：getWidth 为 0、requestLayout 与 invalidate

6.1 为什么 onCreate 里拿不到宽高

这个问题问得最多，其实原理就是 ViewRootImpl 还没有执行遍历。onCreate 只是在 Java 层构建了 View 树，并没有真正进入 measure/layout 阶段。只有在 Activity 的 handleResumeActivity 里，WindowManager.addView 完成之后，ViewRootImpl 才会在下一帧刷新时执行第一次 performTraversals，那时候 View 才有确定的宽高。

有人喜欢用view.post()来拿宽高，这个能奏效是因为 View.post 的 Runnable 被丢到主线程 Handler 的队列里，而请求遍历的消息通常已经在这个 Runnable 之前入队，所以 Runnable 执行时 performTraversals 已经完成。但要注意，这个依赖不一定是百分百保证的，在某些极端情况下仍然可能拿到 0。最稳的做法是用 ViewTreeObserver.OnGlobalLayoutListener，它在布局完成之后回调，专门用来处理这种情况。

6.2 requestLayout、invalidate、postInvalidate 到底差在哪

这三个 API 的区别，本质上就是 ViewRootImpl 这层机制的直接体现。

requestLayout会触发完整的 measure + layout + draw 流程，因为 View 认为自己尺寸可能变了，需要重新测量和布局。invalidate只标记当前 View 的某个区域需要重绘，最终会走到 draw 阶段，不会重新测量和布局。postInvalidate是给子线程用的，它会把刷新动作 post 到主线程再执行 invalidate，避免线程问题。

但从 ViewRootImpl 的实现来看，invalidate 并不会像很多人说的那样“完全不触发 performTraversals”。实际上 invalidate 之后，View 树会通过 invalidateChildInParent 最终调用 ViewRootImpl 的 invalidateRectOnScreen，这个方法内部也会调用 scheduleTraversals，只是在 performTraversals 里根据 mDirty 区域和布局标志位判断出不需要测量和布局，于是只做 draw。所以从能力边界上讲，invalidate 比 requestLayout 轻量很多。

6.3 避免性能坑：不必要 requestLayout 的连锁反应

我之前处理过一个线上卡顿问题，业务方在 View 的 onDraw 里根据一个状态判断调用了 requestLayout。表面看只是改了一点状态，实际上每帧都会调度一次完整测量。因为 onDraw 每帧都会执行，而 requestLayout 又会被塞进 Choreographer，导致那一个页面永远处于“布局完成-又请求布局-再布局”的循环里，CPU 占用直接拉满。

解决办法很简单：把 layout 相关的状态变化放在布局阶段再判断，或者在真正影响尺寸时才 requestLayout，仅仅影响绘制内容的修改用 invalidate 就够了。我们在代码评审时，凡是在 onDraw、onAnimationUpdate、onTouchEvent 里看到 requestLayout，基本都会重点审视，因为这是非常常见的卡顿来源。

另一个容易踩的坑是在用户滑动过程中频繁更新 View 的 LayoutParams，比如动态修改 RecyclerView item 的高度。每次 updateViewLayout 最终都会走 ViewRootImpl 的 relayout 流程，这会引发 Window 级别的重新布局，开销远大于局部 View 的 requestLayout。能用 item 内部状态控制高度的，尽量不要改 LayoutParams。

7. 调试与问题定位经验

7.1 用 Systrace 看 ViewRootImpl 的关键节点

ViewRootImpl 的问题，很多时候必须靠工具才能看明白。我自己定位渲染卡顿时的习惯是先抓 Systrace，重点看 Choreographer 回调的时间点，以及主线程消息的分布。

在 Systrace 里，ViewRootImpl 相关的标记主要有performTraversals、TraversalRunnable、DrawFrame等。你可以在 trace 里看到从 Vsync 到 performTraversals 的时间差，这能帮你区分是渲染调度的问题还是 View 本身太重。比如那一帧里 performTraversals 本身只有 3ms，但从 Vsync 到执行开始用了 40ms，说明大部分时间被主线程其他消息占了，这时候应该去追那段耗时消息，而不是一味优化布局。

如果是 performTraversals 内部 60ms，那就展开看具体是 measure 阶段慢还是 draw 阶段慢。我遇到过不少 LinearLayout 嵌套导致测量爆炸的案例，在 Systrace 里表现为 measure 时间异常高，用 Profile GPU Rendering 或者 GPU 呈现模式分析也能看到绿色条特别长。这时候可以用 ConstraintLayout 或者 reduce nesting 优化，效果立竿见影。

7.2 ViewRootImpl 常见的 Crash 与 ANR

ViewRootImpl 相关的问题，最常见的就是CalledFromWrongThreadException，本质是 View 必须在创建它的线程（通常是主线程）操作。这个异常相当直接，看到它就去找哪里在子线程改了 View 的状态。

另一个高频问题是WindowManager.BadTokenException，比如在 Activity 已经 Finish 之后再弹 Dialog，或者从后台线程直接更新 UI 窗口，WindowManagerService 发现 token 已经无效，就会抛出这个异常。从 ViewRootImpl 的角度看，这是因为 addView 或者 relayoutWindow 的时候，窗口 token 已经失效了。

ANR 方面，ViewRootImpl 参与的主要是输入事件和绘制。如果主线程在 5 秒内没有处理完输入事件，系统会触发“输入无响应”的 ANR。这里的本质就是 InputEventReceiver 收到了事件，但主线程一直忙，没有及时派发到 DecorView。用debuggerd抓主线程栈时，经常能看到主线程堆栈卡在某个业务方法上，后面没有继续走进 ViewRootImpl 的派发逻辑。

7.3 我印象最深的两个线上问题

第一个问题是某个页面首次打开黑屏很久，后来发现是 ViewRootImpl 第一次 performTraversals 前，业务代码在主线程同步执行了一次几百毫秒的本地缓存读取。看似和 View 无关，但它直接阻塞了主线程，导致 Choreographer 的遍历回调迟迟执行不到。这类问题很难从 View 树本身找到答案，必须把主线程整个消息队列拉出来看。

第二个问题是用户反馈部分机型点击按钮偶发无响应，最终追到 InputEventReceiver 的consumePendingInputEvents被耗时任务阻断，而且这个耗时任务又来自一个第三方 SDK 的同步 IPC。这类问题暴露了一个事实：ViewRootImpl 再强壮，也扛不住主线程被无节制占用。它更像一个调度中枢，所有输入和刷新都在等主线程让路。

我个人这些年看 View 相关源码，最大的体会是：“搞懂 ViewRootImpl，很多 Android 疑难杂症自然就通了。”它把 WindowManager、View 树、Choreographer、InputDispatcher、SurfaceFlinger 串在一起，是理解 Android UI 体系最值得花时间啃的一块。如果你也想读源码，不用从头硬啃，先从WindowManagerGlobal.addView和ViewRootImpl.performTraversals两个入口进，后面自然会越看越顺。