LayoutInflater: The Expensive Process of XML to View

XML layout files are essentially just static text descriptions. To convert them into user-visible interfaces, the Android system must execute "Layout Inflation." This process is handled by the `LayoutInflater` class, comprising four steps: parsing, instantiation, attribute application, and view tree construction.

The "instantiation" step is particularly expensive. For each tag in XML (like `<Button>`), the system needs to use Java Reflection to find and load the corresponding View class. Reflection operations are very time-consuming at runtime, especially in pages with complex layouts and numerous widgets, directly causing interface loading delays.

Additionally, the system must traverse every attribute in XML and apply them again through reflection or setter method lookups. This means a complex XML layout might contain hundreds or thousands of reflection calls and method lookups, accumulating into significant performance overhead.

Measure and Layout Process

After View objects are created, they must go through measure and layout phases before drawing. During measurement, parent containers ask child Views how much space they need; during layout, parent containers determine child Views' specific positions.

This is a top-down recursive process. The core performance issue is that certain commonly used layout containers (especially `LinearLayout` and `RelativeLayout`) often need to measure the same child View multiple times to determine its size.

Double Taxation: Exponential Disaster

Take the most common `LinearLayout` with `layout_weight` as an example. To proportionally allocate remaining space, `LinearLayout` must perform two measurement passes: first measuring all non-weighted items to determine space used; second remeasuring weighted items based on remaining space and weight ratios.

This is called "Double Taxation." If there's only one level, it's still acceptable. But modern UIs are often very complex, leading to layer upon layer of nesting. When a layout requiring double measurement is nested within another layout requiring double measurement, measurement counts explode exponentially.

For example, a 3-layer nested weighted `LinearLayout` structure causes the innermost View to be measured $2^3 = 8$ times! This "exponential disaster" is particularly deadly in `RecyclerView` item layouts, as list scrolling frequently triggers binding and measurement, directly causing dropped frames and stuttering.

Although `ConstraintLayout` mitigates nesting issues through its flattened characteristics, it cannot change the underlying architecture of the View system that "allows and even depends on multiple measurements." Jetpack Compose introduces "Intrinsic Measurement" and strict "single-pass measurement" rules, fundamentally eliminating double taxation at the architectural level, ensuring linear (rather than exponential) predictable performance as UI complexity increases.