18、DataBinding性能优化：Binding执行时机、避免过度绑定、StickyEvent与粘性事件、内存泄漏预防
DataBinding 用起来确实爽，XML 里直接写表达式，省掉一堆 findViewById。但爽归爽，性能问题要是没处理好，后期维护起来就头疼了。我见过不少项目，DataBinding 用得飞起，结果页面卡顿、内存泄漏频发，最后不得不回退到传统写法。
说白了，DataBinding 不是银弹。它帮你省了手写代码的时间，但如果你不了解它的执行机制，很容易埋坑。今天我们就来聊聊 DataBinding 性能优化的几个关键点。
核心要点：Binding 执行时机、避免过度绑定、StickyEvent 与粘性事件、内存泄漏预防。
1. Binding 执行时机：别让 UI 等太久
DataBinding 的绑定不是立即生效的。默认情况下，它会在下一帧绘制前统一执行。这其实是个优化策略——把多次数据变化合并成一次 UI 更新。但有些场景下，我们需要立即看到效果。
举个例子。我在做一个扫码功能时，需要在扫码成功后立即显示结果，同时隐藏扫码框。如果等下一帧才执行绑定，用户会看到明显的闪烁。这时候就需要手动触发立即绑定。
// 立即执行所有待处理的绑定
binding.executePendingBindings()
// 典型使用场景：RecyclerView 的 item 绑定
override fun onBindViewHolder(holder: ViewHolder, position: Int) {
holder.binding.apply {
item = items[position]
executePendingBindings() // 确保 item 立即显示
}
}
我的建议：在 RecyclerView 的 onBindViewHolder 里调用 executePendingBindings()，能避免列表滚动时的闪烁问题。但普通 Activity 里别滥用，默认的延迟绑定性能更好。
2. 避免过度绑定：少即是多
DataBinding 的表达式是在编译时生成代码的。你写的每个表达式，最终都会变成一段 Java 代码。表达式越复杂，生成的代码越多，运行时开销也越大。
我见过有人这么写：
<!-- 反面教材：过度绑定 -->
<TextView
android:text="@{user.name != null ? user.name : (user.nickName != null ? user.nickName : '匿名用户')}"
android:visibility="@{user.isVip ? View.VISIBLE : View.GONE}" />
<!-- 正确做法：在 ViewModel 中预处理 -->
<TextView
android:text="@{viewModel.displayName}"
android:visibility="@{viewModel.vipVisibility}" />
为什么推荐在 ViewModel 里处理？因为 ViewModel 里的逻辑可以单元测试，而 XML 里的表达式没法测。而且 ViewModel 里的计算可以缓存，XML 里每次绑定都会重新计算。
避坑指南：我曾经在一个列表页里用了大量三元表达式，结果列表滑动时明显卡顿。后来把所有复杂逻辑移到 ViewModel 里，用 LiveData 驱动，流畅度提升了一个档次。
另外，避免在 XML 里写方法调用，尤其是那些有副作用的：
<!-- 不要这样写 -->
android:onClick="@{() -> viewModel.saveData()}"
<!-- 应该这样写 -->
android:onClick="@{viewModel::saveData}"
方法引用比 lambda 表达式更高效，因为编译时就能确定调用目标，不需要生成额外的匿名类。
3. StickyEvent 与粘性事件：LiveData 的双刃剑
LiveData 有个特性叫「粘性事件」——当观察者注册时，如果 LiveData 已经有数据，会立即收到这个数据。这在某些场景下很方便，但也容易引发问题。
举个例子。假设你有一个 Snackbar 事件：
// ViewModel
val snackbarEvent = MutableLiveData<String>()
// 触发事件
fun showSnackbar(message: String) {
snackbarEvent.value = message
}
// Activity 中观察
viewModel.snackbarEvent.observe(this) { message ->
showSnackbar(message)
}
问题来了：如果 Activity 重建（比如屏幕旋转），LiveData 会重新发送最后一个值，导致 Snackbar 再次弹出。这就是粘性事件带来的副作用。
怎么解决？我常用的方案有两种：
| 方案 | 原理 | 适用场景 |
|---|---|---|
| SingleLiveEvent | 只发送一次事件，重复订阅不触发 | 导航、Snackbar、Toast 等一次性事件 |
| EventWrapper | 用包装类标记事件是否已消费 | 需要灵活控制消费逻辑的场景 |
// SingleLiveEvent 实现
class SingleLiveEvent<T> : MutableLiveData<T>() {
private val pending = AtomicBoolean(false)
override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
super.observe(owner) { value ->
if (pending.compareAndSet(true, false)) {
observer.onChanged(value)
}
}
}
override fun setValue(value: T?) {
pending.set(true)
super.setValue(value)
}
}
我个人习惯：项目中统一使用 EventWrapper 类，因为 SingleLiveEvent 在多观察者场景下会有问题。EventWrapper 更灵活，每个观察者都能独立判断是否消费。
4. 内存泄漏预防：别让 Binding 成为「僵尸」
DataBinding 的内存泄漏，说白了就是 Binding 对象持有了 Activity 或 Fragment 的引用，而 Activity/Fragment 已经销毁了，但 Binding 还被其他地方引用着。
最常见的坑有两个：
- LifecycleOwner 传错——把 Activity 传给了 Fragment 的 Binding
- Binding 对象被静态变量持有——比如放在 Application 类里
// 错误示例：Fragment 中传入了 Activity 的 LifecycleOwner
class MyFragment : Fragment() {
private lateinit var binding: FragmentMyBinding
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
binding = FragmentMyBinding.inflate(inflater, container, false)
// 错误！应该传 viewLifecycleOwner
binding.lifecycleOwner = activity
return binding.root
}
}
// 正确做法
binding.lifecycleOwner = viewLifecycleOwner
为什么必须用 viewLifecycleOwner？因为 Fragment 的生命周期和它的 View 生命周期不完全一致。Fragment 可能还活着，但 View 已经被销毁了。用 viewLifecycleOwner 能确保在 View 销毁时自动解绑。
我曾经踩过的坑：在 Fragment 里用了 activity 作为 LifecycleOwner，结果 Fragment 切到后台再回来，界面不更新了。查了半天才发现是 LifecycleOwner 传错了，导致 LiveData 的观察者没有被正确清理。
另外，Binding 对象一定要在 onDestroyView 中置空：
override fun onDestroyView() {
super.onDestroyView()
binding.unbind() // 解绑所有监听器
binding = null // 释放引用
}
对于 ViewModel 中持有 LiveData 的情况，也要注意：
// ViewModel 中不要持有 View 的引用
class MyViewModel : ViewModel() {
// 正确：只持有数据
val userName = MutableLiveData<String>()
// 错误：持有 View 引用会导致内存泄漏
// val textView = MutableLiveData<TextView>()
}
总结一下：DataBinding 性能优化其实就四个字——「知根知底」。知道它什么时候执行，知道哪些操作开销大，知道粘性事件的特性，知道怎么避免泄漏。把这些搞明白了，DataBinding 用起来就顺手多了。
嗯，最后说一句。性能优化不是一蹴而就的，我建议你在项目初期就建立规范，比如统一使用 EventWrapper、强制在 onDestroyView 中 unbind、禁止在 XML 中写复杂表达式。这样后期就不会有太多性能债要还。