Android Layout Internals: RelativeLayout vs ConstraintLayout

Problem Explain the internal workings of RelativeLayout and ConstraintLayout in Android — not just how to use them, but how each performs its measurement and layout passes.

Be ready to discuss

• RelativeLayout internals: positions are resolved against sibling views or the parent via a dependency graph, sorted into horizontal and vertical chains before measurement.
• The double measure pass: because a view's position can depend on a sibling measured later, RelativeLayout may measure children twice — and nesting them compounds this exponentially down the tree.
• ConstraintLayout internals: constraints are handed to a Cassowary-based linear constraint solver that resolves all positions largely in a single pass, so cost scales with constraint count rather than nesting depth.
• The real win: ConstraintLayout is designed to flatten hierarchies — one flat layout instead of nested LinearLayout/RelativeLayout — and the flattening, more than the solver, is what usually buys the performance.
• Honest nuance: for a genuinely simple layout, ConstraintLayout's solver can be slower than a plain LinearLayout; the advantage appears as complexity grows.
• ConstraintLayout features that replace nesting: chains, guidelines, barriers, groups, and percentage-based dimensions.
• Measurement fundamentals: how MeasureSpec (EXACTLY, AT_MOST, UNSPECIFIED) propagates down, why match_parent is unsupported on a constrained dimension (use 0dp / MATCH_CONSTRAINT), and how to measure real cost with the Layout Inspector or systrace.