LayoutInflater：XML 变为 View 的昂贵过程

XML 布局文件本质上只是静态的文本描述。要将其转换为用户可见的界面，Android 系统必须执行“布局膨胀”（Layout Inflation）过程。这个过程由 `LayoutInflater` 类负责，它包含了解析、实例化、属性应用和视图树构建四个步骤。

其中，“实例化”步骤尤为昂贵。对于 XML 中的每一个标签（如 `<Button>`），系统都需要使用 Java 反射（Reflection）机制来查找并加载对应的 View 类。反射操作在运行时是非常耗时的，尤其是在布局复杂、控件数量众多的页面中，这直接导致了界面加载的延迟。

此外，系统还需要遍历 XML 中的每一个属性，并再次通过反射或查找 setter 方法来应用这些属性。这意味着一个复杂的 XML 布局可能包含成百上千次的反射调用和方法查找，累积起来构成了显著的性能开销。

测量（Measure）与布局（Layout）过程

View 对象创建后，还需要经过测量和布局阶段才能绘制。在测量阶段，父容器会询问子 View 需要多大空间；在布局阶段，父容器决定子 View 的具体位置。

这是一个自顶向下的递归过程。性能问题的核心在于，某些常用的布局容器（特别是 `LinearLayout` 和 `RelativeLayout`）为了确定子 View 的大小，往往需要多次测量同一个子 View。

双重测量 (Double Taxation) 的指数级灾难

以最常见的 `LinearLayout` 配合 `layout_weight` 为例。为了按比例分配剩余空间，`LinearLayout` 必须执行两次测量传递：第一次测量所有无权重的子项，确定它们占用的空间；第二次根据剩余空间和权重比例，重新测量那些带有权重的子项。

这被称为“双重测量”。如果只有一个层级，这还在可接受范围内。但现代 UI 往往非常复杂，导致布局层层嵌套。当一个需要双重测量的布局嵌套在另一个需要双重测量的布局中时，测量次数会呈指数级爆炸。

例如，一个嵌套 3 层的加权 `LinearLayout` 结构，会导致最内层的 View 被测量 $2^3 = 8$ 次！这种“指数级灾难”在 `RecyclerView` 的 Item 布局中尤为致命，因为列表滚动时会频繁触发绑定和测量，直接导致掉帧和卡顿。

尽管 `ConstraintLayout` 通过其扁平化的特性缓解了嵌套问题，但它并不能改变 View 系统本身“允许甚至依赖多重测量”的底层架构。Jetpack Compose 则引入了“固有特性测量”（Intrinsic Measurement）和严格的“单次测量”规则，从架构上根本杜绝了双重测量问题，确保了 UI 复杂度增加时性能的线性（而非指数级）可预测性。