ViewBinding实战：替代findViewById，搭配ViewModel与LiveData

1. 为什么还要学 ViewBinding？—— findViewById 时代遗留的问题

做 Android 开发的人都知道，早期写界面代码，最烦的就是findViewById这一行行样板代码。项目小的时候还能忍，一旦页面多了、控件复杂了，Activity 里动辄几十上百行绑定代码，又丑又容易出错。我记得刚入行那会儿，最怕的就是从Bundle里取参数、从布局里找控件、再强转类型这三件事连着来，稍不留神就给你抛个ClassCastException，整个界面直接白屏。

后来谷歌推出了 ViewBinding，算是把这个老问题从根上解决了一半。注意我说的是"一半"，因为不少人对它的理解还停留在"替代 findViewById"这个层面，实际用下来你会发现，它真正的好处是把视图绑定这件事提升到了编译期检查的高度——布局里没有那个 id，代码里直接编译不过去，而不是等到运行的时候才崩溃。这一点对新手极其友好，因为报错越早，定位成本越低。

这篇博文我会用 Java 语言完整讲一遍 ViewBinding 的用法，包括它在 Activity、Fragment、Adapter 里的差异，后面再叠加 ViewModel 和 LiveData，做一个真正能跑的实战项目。适合刚学 Android 两三个月、已经能写基础布局和 Intent 跳转的读者；如果你已经在用 Kotlin 写项目，也可以看看 Java 版的处理方式，思维是相通的。

1.1 findViewById 的三大痛点：类型转换、空指针、性能损耗

先说类型转换。findViewById返回的是View，所以拿到手必须强转。布局里的TextView写成TextView没问题，但如果你改控件类型时只改了布局、忘了改代码里的强转，编译期完全不会报错，运行到那一行才崩。很多新手查这个 bug 能查一下午。

再说空指针。布局里没有这个 id、或者当前加载的不是你写的那个布局时，findViewById返回null，你继续调用.setText()就直接NullPointerException。这类崩溃在 Fragment 场景下尤其常见——布局还没加载完就急着访问控件，或者onDestroyView()之后还持有旧视图。

最后是性能。findViewById本质上是在 View 树里做一次深度遍历，虽然单次损耗微乎其微，但一个复杂页面里几十个控件就是几十次遍历，再加上列表项滚动时频繁创建 ViewHolder，累积起来的开销就不能忽略了。ViewBinding 在编译期就帮你生成了直接访问控件的代码，运行时不需要遍历，这是它性能更好的根本原因。

1.2 ViewBinding 能做什么、不能做什么

ViewBinding 的核心机制说穿了非常简单：它会在编译时为每个 XML 布局文件生成一个绑定类，类名按照布局文件名转驼峰后加 Binding 后缀。比如activity_main.xml生成ActivityMainBinding，item_user.xml生成ItemUserBinding。这个类里有两个关键东西：一个是根视图，另一个是布局里所有带 id 的控件引用。

它能做的是：消除 findViewById、消除类型转换、保证空安全、提供编译期检查。它不能做的是：像 DataBinding 那样在 XML 里直接写表达式、给控件赋值、做双向绑定。换句话说，ViewBinding 是一个"轻量级、纯粹为了解决视图绑定问题"的工具，它不试图改变你写界面的方式，只是把绑定这步变得更安全、更干净。

理解了它的边界，你就知道什么时候该用它、什么时候该考虑 DataBinding 了。我的建议是：90% 的项目直接用 ViewBinding 就够了，等真的需要 XML 驱动 UI 更新、或者团队对 MVVM 表达式绑定有硬需求时，再升级到 DataBinding 不迟。

2. 开启开关与基础用法：三步让 ViewBinding 跑起来

ViewBinding 从 Android Studio 3.6 开始支持，到 4.0 之后基本稳定。它不需要引入额外的依赖库，只需在模块的build.gradle里开启开关即可。

2.1 Gradle 配置与生成规则

android { buildFeatures { viewBinding true } }

如果你用的是比较老的 Gradle 插件版本，也可以写成：

android { viewBinding { enabled = true } }

新旧写法只是配置入口不同，效果完全一样。开启后，Android Studio 会在你同步项目时自动扫描res/layout目录下的所有 XML 文件，生成对应的绑定类。生成位置在build/generated/data_binding_base_class_source_out/下面，你不需要手动去翻，但要记住这个路径，后面排查编译问题会用得上。

生成规则我再强调一遍：activity_main.xml->ActivityMainBinding，item_student_list.xml->ItemStudentListBinding，layout_common_header.xml->LayoutCommonHeaderBinding。简单说就是去掉下划线，每个下划线后的首字母大写，最后拼上Binding。如果 XML 文件名里有数字，比如layout_2_column.xml，生成的类名是Layout2ColumnBinding，数字后面直接跟大写字母。

2.2 Activity 中绑定：Inflate 与 onCreate 的关系

Activity 里的用法是 ViewBinding 中最简单的场景，代码长这样：

public class MainActivity extends AppCompatActivity { private ActivityMainBinding binding; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); binding = ActivityMainBinding.inflate(getLayoutInflater()); setContentView(binding.getRoot()); binding.tvTitle.setText("Hello ViewBinding"); binding.btnSubmit.setOnClickListener(v -> { // do something }); } @Override protected void onDestroy() { super.onDestroy(); binding = null; } }

注意三个关键点：

第一，inflate负责把布局文件变成 View 对象，也就是替代了原本setContentView(R.layout.activity_main)里的加载工作。binding.getRoot()就是加载出来的根视图，传给setContentView即可。

第二，绑定类的inflate有好几个重载方法，最常用的是inflate(LayoutInflater)和inflate(LayoutInflater, ViewGroup, boolean)。后者用在把布局作为子布局添加到父容器时，比如后面 Adapter 场景里就会用它。

第三，onDestroy里把binding置空这个操作，在 Activity 场景下其实可有可无，因为 Activity 销毁后整个对象都要被回收。但 Fragment 场景完全不同，这是后文要重点讲的生命周期陷阱。

2.3 Fragment 中绑定：生命周期陷阱与正确姿势

Fragment 里的 ViewBinding 用法比 Activity 复杂得多，原因在于Fragment 的 View 生命周期和 Fragment 本身的生命周期是分离的。onCreateView里创建的 View，在onDestroyView时就被销毁了，但 Fragment 对象还活着。

错误的写法是：

public class HomeFragment extends Fragment { private FragmentHomeBinding binding; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { binding = FragmentHomeBinding.inflate(inflater, container, false); return binding.getRoot(); } @Override public void onDestroyView() { super.onDestroyView(); // 这里如果不清空 binding，Fragment 销毁后 binding 仍持有已销毁的 View， // 导致内存泄漏 } }

正确写法是onDestroyView()里必须把binding置空：

@Override public void onDestroyView() { super.onDestroyView(); binding = null; }

为什么要这么做？因为 ViewBinding 的绑定对象内部持有着整个 View 树的强引用。Fragment 虽然onDestroyView后视图已经销毁，但如果你在onDestroyView里不解除引用，这个 View 树就永远无法被 GC 回收。在 ViewPager2 配合 Fragment 频繁切换的场景下，一个页面进出十几次就可能积累几十 M 的内存垃圾。

还有一个更隐蔽的坑：Fragment 的布局加载时机和 viewBinding 调用时机。如果你在onCreateView之前就访问binding，或者在onDestroyView之后访问binding，前者直接空指针，后者因为已经置空所以也空指针。正确做法是所有访问控件代码都写在onViewCreated里，这是 Fragment 已获取 View 的明确时机。

2.4 Adapter 中绑定：ViewHolder 的新写法

RecyclerView 的 Adapter 里用 ViewBinding 同样很爽，主要解决了 ViewHolder 内 findViewById 的问题：

public class StudentAdapter extends RecyclerView.Adapter<StudentAdapter.StudentHolder> { private List<Student> studentList = new ArrayList<>(); @NonNull @Override public StudentHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) { ItemStudentBinding binding = ItemStudentBinding.inflate( LayoutInflater.from(parent.getContext()), parent, false); return new StudentHolder(binding); } @Override public void onBindViewHolder(@NonNull StudentHolder holder, int position) { Student student = studentList.get(position); holder.binding.tvName.setText(student.getName()); holder.binding.tvScore.setText(String.valueOf(student.getScore())); } @Override public int getItemCount() { return studentList.size(); } static class StudentHolder extends RecyclerView.ViewHolder { private final ItemStudentBinding binding; public StudentHolder(ItemStudentBinding binding) { super(binding.getRoot()); this.binding = binding; } } }

这里有个小技巧：ViewHolder的构造器接收的是ItemStudentBinding而不是根 View，因为binding.getRoot()内部就是那个根 View。这样在onBindViewHolder里可以直接用holder.binding.tvName访问控件，不用再写holder.itemView.findViewById。整个过程类型安全、零强转、编译期就能发现拼写错误。

我在实际项目中还习惯给 ViewHolder 写一个bind(Student student)方法，把赋值逻辑收敛到 ViewHolder 里，Adapter 的onBindViewHolder就只剩一行调用。这个小重构对代码可读性提升非常大，尤其当列表项有七八个控件要赋值时。

3. 选型对比：ViewBinding、findViewById、ButterKnife、DataBinding 到底怎么选

学 ViewBinding 之前你肯定纠结过：这不就是当年的 ButterKnife 吗？和 DataBinding 有什么区别？我在弄清楚这几个方案的边界之前也走过弯路，这里直接用表格把差异讲透。

3.1 四个方案的横向对比

看完这个表格你应该能感觉到，ButterKnife 是典型的"过渡期产物"，它解决了 findViewById 的样板代码问题，但没解决空安全和性能问题，而且已经被谷歌停止维护了。新项目再用 ButterKnife 等于给自己埋雷。

3.2 ViewBinding 和 DataBinding 的本质差异

很多人被名字迷惑，以为 ViewBinding 是 DataBinding 的简化版，用了 ViewBinding 就等于用了 DataBinding。这是完全错误的认知。

DataBinding 的核心能力是"XML 表达式"：你可以在布局里写@{viewModel.userName}、@{viewModel.isVisible ? View.VISIBLE : View.GONE}，由框架在数据变化时自动更新界面。比如：

<layout> <data> <variable name="viewModel" type="com.example.MyViewModel" /> </data> <LinearLayout> <TextView android:text="@{viewModel.userName}" ... /> </LinearLayout> </layout>

ViewBinding 完全没有这些能力，它只做一件事：给你生成一个类型安全的控件引用对象。所以两者的关系不是"简化版 vs 完整版"，而是"纯视图绑定工具 vs 数据驱动 UI 框架"。

那什么时候用 DataBinding？我的标准是：当你的项目里 UI 状态和数据的映射关系复杂到写 findViewById/ViewBinding 代码会显得冗长时，比如一个页面有十几个控件的显示/隐藏/文案由不同数据源控制。这种情况下 DataBinding 的表达式写法能把 UI 更新逻辑从代码里移走，代码量会少很多。但如果你的页面只是简单展示数据、监听点击事件，ViewBinding 加手写代码完全够用，没必要为了用 DataBinding 而用。

3.3 我的选型建议

新人时期我曾经迷信"最新的就是最好的"，一上来就直接用 DataBinding，结果被 XML 表达式语法、@BindingAdapter自定义属性、双向绑定这些概念绕晕，调一个EditText的监听就花了一下午。后来老老实实退回 ViewBinding，先把界面逻辑用常规 Java 代码写清楚，再回头看 DataBinding，才真正理解它解决的是什么问题。

所以我的建议很明确：

• 新项目，默认用 ViewBinding，零成本、零风险、官方维护。
• 团队里有人已经熟练 DataBinding，且页面确实大量需要数据驱动 UI，才上 DataBinding。
• 老项目如果还在用 findViewById，逐步迁移到 ViewBinding，不需要一次性改完，改一个页面提交一次。
• Kotlin 项目如果还依赖 Kotlin Synthetics（已废弃），尽快迁到 ViewBinding。

4. ViewModel + LiveData：ViewBinding 的最佳搭档

ViewBinding 解决的是"视图怎么拿"，但真正让 Android 界面代码变清爽的，是它和 ViewModel、LiveData 的组合。这三者一起用，才算是摸到了现代 Android 架构的门边。这一节我来讲清楚 ViewModel 和 LiveData 各自解决的问题，以及它们和 ViewBinding 的协作原理。

4.1 配置依赖与基础概念

ViewModel 和 LiveData 属于 AndroidX 的 Lifecycle 组件，需要在build.gradle中添加依赖：

dependencies { implementation 'androidx.appcompat:appcompat:1.6.1' implementation 'androidx.lifecycle:lifecycle-viewmodel:2.6.2' implementation 'androidx.lifecycle:lifecycle-livedata:2.6.2' }

如果用viewModel()扩展函数或ViewModelProvider，还需要 activity 和 fragment 相关的扩展库，不过 Java 项目里直接用new ViewModelProvider(this).get(XxxViewModel.class)即可，不需要额外扩展依赖。

ViewModel 是什么？一句话概括：一个专门用来存界面数据的类，生命周期比 Activity 长。手机旋转屏幕时 Activity 会被销毁重建，但 ViewModel 不会，它会在新 Activity 创建时原封不动地返回给你。这样你在旋转前编辑了一半的输入框内容、列表滚动位置，都不会丢。

LiveData 又是什么？它是 ViewModel 暴露数据的一种载体，一个能感知生命周期的数据容器。你往里面setValue一个数据，只有处于活跃状态的界面（比如 Activity 在 STARTED 状态）才会收到更新通知。这个特性天然解决了"界面销毁后还在更新 UI 导致崩溃"的老大难问题。

4.2 为什么 ViewBinding 要配合 ViewModel

单独用 ViewBinding 时，你仍然需要在 Activity 里维护一堆 UI 更新的代码：

binding.tvName.setText(user.getName()); binding.tvAge.setText(String.valueOf(user.getAge())); binding.ivAvatar.setImageURI(user.getAvatarUrl());

这些代码本身没问题，但都写在 Activity 里，随着逻辑变多，Activity 会膨胀到几百行。ViewModel 的作用就是把这些"数据从哪里来""数据变化后要做什么"的逻辑从 Activity 里挪出去。

配合 ViewModel 之后，Activity 只负责两件事：拿到 Binding、监听 LiveData 更新 UI。所有数据加载、业务判断、状态更新都放到 ViewModel 里，职责边界一下子就清晰了。

很多人刚开始不理解"把数据放 ViewModel 里"和"直接在 Activity 里写个成员变量"有什么区别。区别就在旋转屏幕那一刻：成员变量跟着 Activity 一起销毁了，数据全丢；ViewModel 的成员变量留着，界面重建后数据原样还在。这就是 ViewModel 存在的全部意义——让数据生命周期独立于界面生命周期。

4.3 LiveData 和 ViewBinding 的协作方式

ViewBinding 和 LiveData 的协作逻辑其实很简单：

1. ViewModel 暴露一个LiveData<T>，持有界面要展示的数据。
2. Activity 在onCreate里observe这个 LiveData，收到数据后用 binding 去更新控件。
3. 数据在 ViewModel 里改变 -> LiveData 通知 -> Activity 用 binding 更新 UI。

完整链条跑起来，Activity 里的"数据管理"都被抽走了，只剩"数据消费"。

这里有一个值得注意的细节：LiveData 的observe回调是在主线程执行的，而且默认情况下，粘性事件会把最新的数据立刻派发给新注册的观察者。什么意思？比如你的 ViewModel 里已经有name = "张三"这个值，Activity 重建后再次observe，会立刻收到"张三"。这个特性在某些场景（比如一次性事件、Toast 提示）会造成重复消费，后文实战里我会给出处理方案。

5. 实战：结合 ViewModel + LiveData 的完整项目

理论说多了都是虚的，现在我把三个东西串起来，做一个非常经典的小项目：计数器。功能就两个：界面上显示一个数字，点按钮加一或减一；同时用一个EditText输入昵称，实时显示"你好，XXX"。这个项目虽小，但足够覆盖 ViewBinding、ViewModel、LiveData 的全部核心用法。

5.1 项目结构设计

app/src/main/java/com/example/counter/ ├── MainActivity.java └── CounterViewModel.java app/src/main/res/layout/ └── activity_main.xml

我要强调一下包结构：把 ViewModel 单独放到一个包（或者至少和 Activity 平级），不要什么都堆在默认包里。等项目大了之后，清晰的包结构比代码本身更值钱。

5.2 布局文件设计：注意根标签

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="24dp"> <EditText android:id="@+id/etNickname" android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入昵称" /> <TextView android:id="@+id/tvGreeting" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="你好，游客" android:textSize="18sp" /> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="horizontal" android:layout_marginTop="24dp"> <Button android:id="@+id/btnMinus" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="减一" /> <TextView android:id="@+id/tvCount" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center_vertical" android:layout_marginStart="24dp" android:layout_marginEnd="24dp" android:text="0" android:textSize="24sp" /> <Button android:id="@+id/btnPlus" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="加一" /> </LinearLayout> </LinearLayout>

注意一点：这里我用了普通的LinearLayout作为根标签。如果你要用 DataBinding，根标签必须改成<layout>；但 ViewBinding 对布局文件的根标签没有任何额外要求，普通布局直接就能生成绑定类，这是两者在接入成本上的重要差异。

编译之后，Android Studio 会生成ActivityMainBinding类，里面会有etNickname、tvGreeting、btnMinus、tvCount、btnPlus这些字段，类型分别是EditText、TextView、Button、TextView、Button。

5.3 ViewModel 编写：Java 版

public class CounterViewModel extends ViewModel { private MutableLiveData<Integer> count = new MutableLiveData<>(0); private MutableLiveData<String> nickname = new MutableLiveData<>(""); public LiveData<Integer> getCount() { return count; } public LiveData<String> getNickname() { return nickname; } public void plus() { count.setValue(count.getValue() + 1); } public void minus() { count.setValue(count.getValue() - 1); } public void onNicknameChanged(String input) { nickname.setValue(input); } }

这里有几个细节你需要特别注意：

第一个细节：对外暴露LiveData，对内持有MutableLiveData。这是 ViewModel 封装的黄金法则。外部观察者只能订阅数据变化，不能修改数据；只有 ViewModel 自己能通过setValue改值。如果直接把MutableLiveData暴露出去，Activity 里就有人能偷偷改数据，数据源就乱了。

第二个细节：MutableLiveData构造时可以传初始值。new MutableLiveData<>(0)表示计数器初始值是 0，这样观察者注册后立刻就会收到 0，界面不会出现"先空白再变 0"的闪烁。

第三个细节：LiveData 的setValue只接受非空值。虽然 Java 里你可以写count.setValue(null)，运行也不会立刻报错，但观察者拿到 null 后的空指针风险由你自己承担。所以更稳妥的做法是用Integer包装类型并自行判断，或者干脆约定 LiveData 里永远不放 null。

5.4 MainActivity 完整实现

public class MainActivity extends AppCompatActivity { private ActivityMainBinding binding; private CounterViewModel viewModel; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); binding = ActivityMainBinding.inflate(getLayoutInflater()); setContentView(binding.getRoot()); viewModel = new ViewModelProvider(this).get(CounterViewModel.class); // 观察计数器变化，更新 TextView viewModel.getCount().observe(this, new Observer<Integer>() { @Override public void onChanged(Integer value) { binding.tvCount.setText(String.valueOf(value)); } }); // 观察昵称变化，更新问候语 viewModel.getNickname().observe(this, new Observer<String>() { @Override public void onChanged(String nickname) { if (nickname == null || nickname.trim().isEmpty()) { binding.tvGreeting.setText("你好，游客"); } else { binding.tvGreeting.setText("你好，" + nickname); } } }); // 按钮点击去更新 ViewModel 中的数据 binding.btnPlus.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { viewModel.plus(); } }); binding.btnMinus.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { viewModel.minus(); } }); // EditText 输入监听 binding.etNickname.addTextChangedListener(new TextWatcher() { @Override public void beforeTextChanged(CharSequence s, int start, int count, int after) { } @Override public void onTextChanged(CharSequence s, int start, int before, int count) { viewModel.onNicknameChanged(s.toString()); } @Override public void afterTextChanged(Editable s) { } }); } @Override protected void onDestroy() { super.onDestroy(); binding = null; } }

这段代码的核心逻辑已经完整呈现了"三件套"的协作流程：

• ViewBinding 负责拿控件、挂监听。
• ViewModel 负责存计数和昵称、处理加减逻辑。
• LiveData 负责把数据变化通知给界面。

你把 Activity 读一遍，能看到"界面怎么初始化、按钮点了之后数据怎么流动、数据变化后界面怎么更新"的完整链路，而且没有一块逻辑是多余的。如果这是用 findViewById 写的，光控件获取就得四五行，再加类型转换、空判断，代码量至少翻一倍。

5.5 运行效果与知识点回顾

安装运行后你会看到：点击"加一"按钮，数字变成 1、2、3……点击"减一"，数字递减；在输入框里打字，下面问候语实时变。现在把手机横过来旋转屏幕，你会发现数字没有归零，输入框里的字也还在。

这就是组合拳的意义：ViewModel 保住了数据，LiveData 恢复了界面，ViewBinding 让恢复操作写得简洁安全。这三个东西缺一个，旋转屏幕的场景都会出问题——没用 ViewModel 数据就丢了；用了 ViewModel 但没用 LiveData，你得自己在onCreate里重新拉数据再手动 set 到控件；没有 ViewBinding，你就要写一堆 findViewById。

6. 我踩过的坑：ViewBinding 实战中的常见问题与排查思路

最后一个部分，我把自己在真实项目中踩过的坑和排查思路整理一下。这些坑你在官方文档里几乎看不到，但每一个都是实际运行时会出现的。

6.1 Fragment 空指针：根因不是 ViewBinding，而是生命周期

如果你用 Fragment 加 ViewBinding，在onCreateView里给 binding 赋值、在onDestroyView里置空，按理说不会出问题。但新手常犯的错误是：在异步回调里访问 binding。

典型的场景是这样的：

viewModel.getData().observe(getViewLifecycleOwner(), data -> { binding.tvResult.setText(data.getTitle()); });

这段代码本身没问题，observe用的是getViewLifecycleOwner()而不是getOwner()，已经是正确写法。但如果你是这么写的：

// 错误示例：使用 this 作为生命周期所有者 viewModel.getData().observe(this, data -> { binding.tvResult.setText(data.getTitle()); });

问题就来了。this代表 Fragment 实例，Fragment 在onDestroyView之后仍活着，此时 LiveData 如果发来新数据，回调会执行，但binding在onDestroyView里已经被置空，于是空指针。

排查思路很简单：崩在更新 UI 的回调里，先看两件事——生命周期所有者是不是getViewLifecycleOwner()，binding 是不是在onDestroyView里置空了。这两点都做到，这个坑基本就不会踩到。

6.2 修改了布局文件但绑定类没更新

ViewBinding 的绑定类是编译期生成的，你改完 XML 后如果没重新编译，代码里引用新加的 id 就会报"找不到符号"。

这个现象在 Android Studio 里有时候很迷惑，因为增量编译偶尔不会触发绑定类的重新生成。我遇到过的处理步骤是：

1. 先点一次 Build -> Rebuild Project，强制全量编译。
2. 如果还不行，File -> Invalidate Caches / Restart，清掉缓存。
3. 检查 build.gradle 对应模块里viewBinding true是否还在。

绝大多数情况第一招就能解决，遇到第二招基本是 Android Studio 自己的索引出了问题。

6.3 Include 标签和 ViewStub 的处理差异

布局里的<include>如果带 id，ViewBinding 会直接生成 include 根布局的所有控件引用，访问方式是binding.includeRoot.tvInner。这里有一个前提：被 include 的布局里的控件必须有专门的 id，include 标签本身也要有 id，否则 ViewBinding 不会展开 include 内容。

ViewStub 更特殊。ViewStub 在 ViewBinding 里生成的是ViewStubProxy对象，你需要先设置setOnInflateListener才能拿到 ViewStub inflate 后的子视图。逻辑大概是这样：

binding.viewStubProxy.setOnInflateListener((stub, inflatedId) -> { // ViewStub 展开后，通过 binding.viewStubProxy.binding 拿到子布局的绑定类 binding.viewStubProxy.binding.tvContent.setText("展开成功"); }); binding.viewStubProxy.getViewStub().inflate();

这个设计是为了保证：在 ViewStub 没有真正 inflate 之前，子布局的控件引用还不存在，不能直接访问。

6.4 一个关于性能的实话

ViewBinding 之所以快，不是因为它用了什么黑魔法，而是它把本该在运行时做的事挪到了编译期。但需要说明的是，对于普通页面，ViewBinding 和 findViewById 的性能差距用户根本感知不到——一次遍历几毫秒内就结束了。真正有价值的是它消除的类型转换和空指针隐患。

我自己使用过程中的体会是，不要神话任何技术，但也不要低估工具带来的开发效率提升。ViewBinding 最大的价值在维护阶段：重构布局时，编译器会在第一时间告诉你哪些引用失效了；团队协作时，同事不会因为控件类型标错留下一颗定时炸弹。作为 Java 版 Android 开发的老兵，我可以负责任地说，ViewBinding 是这些年谷歌推出的少有的"零学习成本、零迁移风险、立刻见效"的基础组件。

最后分享一个我自己的小习惯：项目里我通常会把 Activity 的onDestroy置空 binding 和 Fragment 的onDestroyView置空 binding 作为代码规范写进团队的开发文档，配合编译期报错，基本上半年下来整个团队不会再有人写 findViewById。新手照着这个思路去做，早期踩坑的数量会大幅度减少，你会比同龄人多出很多时间真正去研究业务逻辑，而不是在和空指针搏斗。