include、merge、ViewStub与 性能优化

1. <include>：复用布局

用于把一个公共 XML 布局引入当前布局。

<include layout="@layout/title_bar" />

例如多个页面都有相同的标题栏，可以将标题栏单独写成 title_bar.xml，然后通过 include 复用。

一句话：include = 复用已有布局。

---

2. <merge>：减少布局层级

通常与 include 配合使用。

例如原本：

LinearLayout
    └── LinearLayout      ← 多余的一层
        ├── ImageView
        └── TextView

将被 include 的布局根节点改成：

<merge>

    <ImageView ... />

    <TextView ... />

</merge>

最终 View 树变成：

LinearLayout
    ├── ImageView
    └── TextView

merge 自己不会生成 View，而是把内部 View 直接添加到父布局。

一句话：merge = 去掉多余的根 ViewGroup，减少布局层级。

---

3. <ViewStub>：延迟加载布局

适合错误页、空数据页等不一定会显示的布局。

<ViewStub
    android:id="@+id/errorStub"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout="@layout/layout_error" />

页面初始化时，layout_error 中的真实 View 不会被创建。

需要时：

ViewStub stub = findViewById(R.id.errorStub);
View errorView = stub.inflate();

此时才真正加载 layout_error，并用真实布局替换 ViewStub。

注意和 GONE 区别：

visibility = GONE
→ View 已经创建，只是不显示

ViewStub
→ View 一开始根本没有创建，需要时才创建

一句话：ViewStub = 延迟创建不常用布局。

---

三者对性能优化的区别

标签	主要作用	对性能的影响
include	布局复用	主要提高代码复用，本身不直接降低 View 层级
merge	减少布局层级	减少多余 ViewGroup，降低 measure/layout 开销
ViewStub	延迟加载	减少初始化时的 View 创建、内存占用和首屏加载开销

面试直接背

在布局优化中，include、merge 和 ViewStub 经常配合使用。include 主要用于公共布局复用；merge 通常配合 include 使用，去掉多余的根 ViewGroup，从而降低 View 树层级；ViewStub 则用于延迟加载低频布局，只有真正需要显示时才进行 inflate，从而减少初始化阶段的 View 创建和内存开销。

最后记：

include  → 复用
merge    → 减层级
ViewStub → 延迟创建

性能角度：

merge    → 少一层，少一些布局计算
ViewStub → 少创建，降低初始化开销
include  → 主要解决代码复用