How do include, merge, and ViewStub optimize deep layout nesting?

What's really being asked

The interviewer wants to see if you understand the difference between compile-time layout reuse and runtime view inflation costs. Deep nesting hurts performance because each ViewGroup adds a node to the view tree that must be measured, laid out, and drawn. The three tags are solutions to three distinct problems: duplication, wrapper bloat, and conditional visibility. A senior candidate should explain the mechanical effect of each tag on the final view hierarchy, not just recite definitions.

The full answer

First, include is for reuse. It lets you embed one layout XML inside another at compile time, similar to a copy-paste. It does not flatten anything; the root of the included file becomes a child in the host hierarchy. Second, merge is for flattening. When you inflate a layout whose root is merge, the system skips creating that root element and attaches its children directly to the parent specified in the include tag or the inflation call. This removes one level of nesting and is ideal when the included layout does not need its own ViewGroup container. Third, ViewStub is for laziness. It is a lightweight, zero-dimension placeholder that costs almost nothing during the initial measure and draw passes. You call inflate on it only when the view is actually needed, which is perfect for heavy layouts like error states, empty states, or complex onboarding overlays that most users never see.

The mistakes people make

A red flag is saying merge reduces APK size or that it works like a fragment. Another red flag is claiming ViewStub replaces a view at runtime without explaining that the stub itself is removed from the tree after inflation. Some candidates also say include automatically removes the included root; it does not unless you pair it with merge. Finally, describing all three as ways to make XML files shorter misses the point entirely; the goal is to reduce the runtime view object count.

What usually comes next

The interviewer might ask how merge interacts with the tools parent tag in Android Studio preview. They might ask what happens if you try to add a background or padding to a merge root, which is impossible because merge is not a real ViewGroup. They might also ask for the difference between ViewStub inflation and simply setting visibility to GONE, which is that GONE views are still instantiated and attached whereas a stub is not.

A concrete example

Imagine a screen with a complex filter panel that only ten percent of users open. The panel is defined in its own XML and included at the bottom of the main screen. If the panel root is a LinearLayout, using include alone nests that LinearLayout inside the main LinearLayout, adding an extra measure pass. Replacing the panel root with merge and wrapping the include in the main layout removes the nested LinearLayout entirely. Wrapping the include in a ViewStub means the filter panel is not instantiated or measured at all until the user taps the filter button, saving hundreds of views on cold start.