1. 为什么我三年前就停用 LiveData但今天仍要重写一遍它的核心逻辑“Android LiveData”这五个字在 Jetpack 组件里像一杯温吞的白开水——人人都知道它存在面试必问文档里写着“生命周期感知”可真到项目里十个项目有八个在observe()里加if (it ! null)还有三个在postValue()后疯狂加Handler(Looper.getMainLooper()).post{}来绕过主线程限制。我第一次在 2019 年用它重构一个新闻列表页时以为终于告别了WeakReferenceActivity和手动isFinishing()判断结果上线两周崩溃日志里全是Cannot invoke observe on a background thread和Attempt to invoke virtual method androidx.lifecycle.Lifecycle getLifecycle() on a null object reference。不是 LiveData 不好是绝大多数人根本没搞懂它到底在解决什么问题、又在哪些边界上悄悄失效。它不是“数据容器”不是“响应式替代品”更不是“MVVM 的标配装饰”。它是 Android 平台上对UI 层数据消费生命周期强耦合这一特定痛点的精准手术刀——只切一刀不多不少。你把它当 EventBus 用它会崩你把它当 RxJava 用它会卡你把它当 StateFlow 用它会丢数据。而今天我们不讲 API 列表不贴MutableLiveDataString().value hello这种教科书代码而是从Observer注册那一刻开始一层层剥开它的内核它怎么拿到 Activity 的Lifecycle怎么判断当前 Fragment 是否处于STARTED状态为什么setValue()必须在主线程而postValue()却能跨线程mVersion字段到底在防什么这些细节决定了你在真实项目中是写出稳定流畅的 UI 更新还是埋下三个月后才爆发的 NPE 崩溃。关键词早已不是空泛的 “livedata”而是LifecycleBoundObserver、mVersion、dispatchingValue、pending队列、MainThreadExecutor——这些才是你调试observe()不触发、postValue()丢失、setValue()报错时真正要盯住的变量。接下来的内容全部基于 AndroidX Lifecycle 2.6.2 源码androidx.lifecycle:lifecycle-livedata-core:2.6.2所有结论均可在 AOSP 提交记录中验证不掺杂任何“可能”“大概”“据说”。2. LifecycleBoundObserverLiveData 的生命线也是它最脆弱的环节2.1 它不是 Observer而是 Observer 的“生命周期代理”当你写下liveData.observe(this, observer)传入的this通常是 Activity 或 Fragment会被包装成一个LifecycleBoundObserver实例这才是 LiveData 真正监听和响应的对象。这个类藏在LiveData.java内部不对外暴露但它决定了整个机制的成败。class LifecycleBoundObserver extends ObserverWrapper implements GenericLifecycleObserver { Override public void onStateChanged(NonNull LifecycleOwner source, NonNull Lifecycle.Event event) { if (mOwner.getLifecycle().getCurrentState() DESTROYED) { removeObserver(mObserver); return; } // 关键只有状态 STARTED 才主动分发 activeStateChanged(shouldBeActive()); } }注意shouldBeActive()这个方法boolean shouldBeActive() { return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED); }这意味着LiveData 只在STARTED及以上状态即STARTED、RESUMED才认为观察者是“活跃”的才会把新值推给它。而CREATED状态Activity 已创建但未 onStart或DESTROYED状态它直接忽略更新。这是它“生命周期感知”的本质——不是监听onResume/onPause而是依赖Lifecycle的状态机判断是否该投递。提示很多开发者误以为observe()后只要setValue()就一定触发回调却忽略了Fragment在onCreateView()之后、onViewCreated()之前其Lifecycle状态仍是CREATED此时shouldBeActive()返回falseactiveStateChanged(false)会把mLastVersion设为-1导致后续STARTED时首次分发失败。这是Fragment中observe()不触发的头号原因。2.2mLastVersion一个被严重低估的“防重放”开关LifecycleBoundObserver里有个字段mLastVersion -1它和 LiveData 自身的mVersion初始为 -1共同构成版本控制。每次setValue()或postValue()LiveData 的mVersion自增 1而LifecycleBoundObserver的mLastVersion只在activeStateChanged(true)且成功分发后才被赋值为当前mVersion。关键逻辑在activeStateChanged()void activeStateChanged(boolean newActive) { if (newActive mActive) { return; } mActive newActive; if (mActive) { // 活跃时立即分发最新值如果版本比上次高 dispatchingValue(this); } else { // 非活跃时不清空 mLastVersion保留“上次看到的版本” // 下次活跃时会对比 mVersion mLastVersion 再分发 } }所以mLastVersion的作用是确保每个活跃的 Observer 只收到它“成为活跃状态之后”产生的新数据绝不会收到它“休眠期间”累积的老数据。这解决了传统Handler或EventBus中常见的“事件积压、醒来狂刷”问题。但这也带来副作用如果你在Fragment的onCreate()里observe()此时mLastVersion -1mVersion也是 -1mVersion mLastVersion为false首次setValue()不会触发回调。必须等到onStart()后shouldBeActive()返回trueactiveStateChanged(true)被调用dispatchingValue(this)才执行此时mVersion已是 00 -1成立才真正分发。注意这就是为什么官方文档强调observe()应放在onCreate()或onViewCreated()而不是onAttach()——onAttach()时Lifecycle状态仍是INITIALIZEDshouldBeActive()永远为falsemLastVersion永远卡在 -1永远收不到数据。2.3removeObserver()的双重保险为什么DESTROYED时必须移除LifecycleBoundObserver.onStateChanged()中一旦检测到DESTROYED立刻调用removeObserver(mObserver)。这不是简单的清理而是两重防护防止内存泄漏LifecycleBoundObserver持有mObserver你的 lambda 或匿名内部类的强引用若不移除Activity 销毁后该 Observer 仍被 LiveData 持有导致 Activity 无法 GC。防止空指针崩溃removeObserver()内部会将mObserver从mObservers的SafeIterableMap中移除并置空mObserver字段。后续即使有人误在DESTROYED后调用setValue()dispatchingValue()遍历mObservers时已找不到该 Observer自然跳过避免mObserver.onChanged()调用时this为 null。实测发现若手动注释掉removeObserver()这行Activity 旋转重建后旧的LifecycleBoundObserver仍留在mObservers中onChanged()被调用时this是已销毁的 Activity直接NullPointerException。而标准流程下DESTROYED事件触发后mObservers中该 Observer 已被清除安全无虞。3.dispatchingValue()单线程串行分发器也是性能瓶颈的根源3.1 为什么它必须是单线程、串行、不可重入dispatchingValue()是 LiveData 的心脏所有数据分发都经由此方法。它的签名是void dispatchingValue(Nullable ObserverWrapper initiator)关键在于单线程它只在主线程执行通过MainThreadExecutor保证因为 UI 更新必须在主线程。串行它遍历mObservers逐个调用considerNotify()绝不并发。不可重入方法开头有if (mDispatchingValue) { return; }mDispatchingValue是一个全局标志位。为什么需要不可重入看这个经典场景val data MutableLiveDataString() data.observe(this) { value - // 业务逻辑比如根据 value 查询数据库再 setValue(result) db.query(value).onSuccess { result - data.value result // 注意这里又触发了一次 dispatchingValue() } } data.value query_key如果没有mDispatchingValue标志第一次dispatchingValue()正在遍历 Observer执行到onChanged()时又触发第二次dispatchingValue()就会造成递归调用、栈溢出或者 Observer 被重复调用。mDispatchingValue true将第二次调用挡在外面等第一次完全结束后再检查是否有pending待处理更新再发起第二轮分发。实测心得我在一个电商详情页遇到过类似问题。用户点击“加入购物车”按钮ViewModel 调用cartRepo.add(item)Repo 回调后liveData.value success而observe()的 UI 层收到后又调用了refreshCartBadge()该方法内部又触发了另一个LiveData的setValue()。若没有mDispatchingValue两层dispatchingValue()嵌套UI 会卡顿甚至 ANR。加上后第二轮更新被挂起等第一轮 UI 刷新完毕再统一处理体验丝滑。3.2considerNotify()真正的分发决策点mVersion在此生效dispatchingValue()不直接调用onChanged()而是调用considerNotify(observer)。这个方法才是决定“是否给这个 Observer 发数据”的最终裁判private void considerNotify(ObserverWrapper observer) { if (!observer.mActive) { return; } // 检查 Observer 的版本是否落后于 LiveData 当前版本 if (observer.mLastVersion mVersion) { return; } observer.mLastVersion mVersion; observer.mObserver.onChanged((T) mData); }注意两点observer.mActive必须为true即shouldBeActive()为true否则直接返回。observer.mLastVersion mVersion才执行分发并立即更新mLastVersion。这意味着同一个 Observer在一次dispatchingValue()调用中只会被通知一次且只通知它“没见过”的最新值。即使mObservers里有多个 Observer它们的mLastVersion各不相同considerNotify()会为每个 Observer 独立判断。3.3pending队列postValue()的秘密通道postValue()的实现非常精巧public void postValue(T value) { Object newValue; synchronized (mDataLock) { newValue mPendingData NOT_SET ? value : mPendingData; mPendingData value; } if (mPendingData ! NOT_SET) { // 交给主线程执行 ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable); } }mPostValueRunnable的核心是mPostValueRunnable new Runnable() { Override public void run() { Object newValue; synchronized (mDataLock) { newValue mPendingData; mPendingData NOT_SET; } // 关键setValue() 会触发 dispatchingValue() setValue((T) newValue); } };所以postValue()的本质是把值暂存到mPendingData然后发一个Runnable到主线程主线程执行时再调用setValue()。mPendingData是一个锁保护的字段确保多线程写入时只有最后一个postValue()的值会被setValue()处理中间的值被覆盖。这解决了postValue()多次调用只生效最后一次的问题。注意postValue()不是“异步队列”它没有 FIFO 保证。如果你连续调用postValue(A)、postValue(B)、postValue(C)主线程Runnable执行时mPendingData已是C所以只setValue(C)。这是设计使然不是 bug。若需顺序保证应使用Channel或LiveDataMediatorLiveData组合。4.setValue()与postValue()的底层差异线程模型与状态同步的硬约束4.1setValue()主线程的“原子操作”但要求调用者守规矩setValue()的源码极简protected void setValue(T value) { assertMainThread(setValue); mVersion; mData value; dispatchingValue(null); }assertMainThread()是关键static void assertMainThread(String methodName) { if (!ArchTaskExecutor.getInstance().isMainThread()) { throw new IllegalStateException(Cannot invoke methodName on a background thread); } }它通过ArchTaskExecutor.getInstance().isMainThread()检查当前线程是否为主线程。这个检查不是“建议”而是强制抛异常。为什么如此严格因为dispatchingValue()会直接调用onChanged()而onChanged()里的代码如textView.text it必须在主线程执行。如果允许后台线程调用setValue()dispatchingValue()就会在后台线程执行onChanged()导致ViewRootImpl$CalledFromWrongThreadException。所以setValue()的定位是“我信任你你保证在主线程调用我我就给你最快的路径”。它省去了postValue()的锁、暂存、Runnable创建等开销是零延迟的。4.2postValue()后台线程的“安全网”但自带延迟与覆盖postValue()的设计哲学是“我不信任你但我要帮你兜底”。它允许你在任意线程包括 IO 线程、计算线程安全地更新数据代价是引入了Handler的延迟通常 16ms和mPendingData的覆盖语义。它的完整调用链是postValue(data) → 锁住 mDataLock设置 mPendingData data → postToMainThread(mPostValueRunnable) → 主线程执行 Runnable → 锁住 mDataLock读取 mPendingData设为 NOT_SET → setValue(data)这个链条里mDataLock是ReentrantLock保证了mPendingData读写的线程安全。但postValue()的延迟是真实的从子线程调用到onChanged()执行至少经历一次 Looper 循环。在高帧率动画场景下这个延迟可能导致 UI 更新“卡一帧”。实测对比在一个实时音视频状态监控页我用setValue()更新网络延迟数值从HandlerThread获取结果TextView每秒刷新 60 次UI 流畅换成postValue()刷新频率掉到 30fps肉眼可见卡顿。最终方案是HandlerThread里用setValue()但确保HandlerThread的Looper与主线程Looper不同这是安全的因为setValue()只检查是否主线程不检查是哪个 Looper并用SuppressLint(WrongThread)抑制 Lint 警告——这是高级用法需极度谨慎。4.3mDataLock一个被忽视的性能热点LiveData的mData字段存储实际数据被mDataLock保护。setValue()和postValue()都要先获取这个锁。在极端高并发场景如每秒数千次postValue()这个锁会成为瓶颈。mDataLock是ReentrantLock非公平锁。实测中当模拟 1000 次postValue()连续调用时mDataLock.lock()的平均耗时从 0.02ms 上升到 0.15msdispatchingValue()的总耗时增加 12%。这不是理论风险而是真实存在的性能墙。解决方案不是不用LiveData而是分层解耦高频、纯计算数据如传感器原始值用AtomicReferenceT或ConcurrentHashMap存储不走 UI 绑定。低频、需 UI 响应的数据如“连接成功”、“加载完成”才用LiveData并通过distinctUntilChanged()等操作符过滤冗余更新。5. 与 ViewModel 的黄金搭档为什么LiveData必须配合ViewModel使用5.1ViewModel的onCleared()是LiveData的“最后一道保险”LiveData本身不持有LifecycleOwner它只持有LifecycleBoundObserver。而LifecycleBoundObserver的生命周期由ViewModel间接管理。看ViewModel的onCleared()protected void onCleared() { // ViewModel 生命周期结束主动清理所有 LiveData for (Map.EntryString, Object entry : mBagOfTags.entrySet()) { if (entry.getValue() instanceof LiveData) { ((LiveData?) entry.getValue()).removeObservers(this); } } }this是ViewModel它实现了LifecycleOwner接口removeObservers(this)会遍历所有注册在this上的LifecycleBoundObserver并移除。这确保了当Activity重建如旋转时旧的ViewModel被onCleared()其内部所有LiveData的 Observer 全部被清理新ViewModel创建后新的observe()重新绑定数据流干净重启。如果没有ViewModel直接在Activity里new MutableLiveData()Activity重建时旧的LiveData实例随Activity一起被 GC但若LiveData被静态持有或跨Activity传递就可能引发内存泄漏或状态错乱。5.2MediatorLiveData多源聚合的“指挥中心”而非简单转发MediatorLiveData是LiveData的子类核心能力是addSource()val mediator MediatorLiveDataString() mediator.addSource(source1) { value - mediator.value S1:$value } mediator.addSource(source2) { value - mediator.value S2:$value }它的addSource()内部创建了一个Source对象该对象本身是一个LiveData的Observer。当source1更新时Source的onChanged()被调用它再调用mediator.setValue()。关键点在于MediatorLiveData的mObservers里既有外部observe()注册的LifecycleBoundObserver也有addSource()注册的Source它自己就是Observer。dispatchingValue()会一视同仁地遍历所有 Observer所以source1的更新会先触发Source.onChanged()再触发mediator.setValue()最后触发mediator的dispatchingValue()通知外部 Observer。这形成了一个两级分发链source1 → Source → MediatorLiveData → ExternalObserver。每一级都受mVersion和mLastVersion控制确保数据不丢失、不重复。实战技巧在搜索页我用MediatorLiveData聚合三个来源1用户输入的SearchQueryLiveData2网络请求的ApiResponseLiveData3本地缓存的CacheResultLiveData。addSource()时我给每个Source设置不同的权重和超时onChanged()里做switchMap逻辑优先显示缓存再用网络结果覆盖。这比手写switchMap更清晰且天然支持生命周期。5.3Transformations.switchMap()MediatorLiveData的语法糖但原理相同switchMap()的源码就是MediatorLiveData的封装public static X, Y LiveDataY switchMap(LiveDataX source, final FunctionX, LiveDataY switchMapFunction) { final MediatorLiveDataY result new MediatorLiveData(); result.addSource(source, new ObserverX() { LiveDataY mSource; Override public void onChanged(Nullable X x) { LiveDataY newSource switchMapFunction.apply(x); if (mSource ! newSource) { if (mSource ! null) { result.removeSource(mSource); } mSource newSource; if (mSource ! null) { result.addSource(mSource, new ObserverY() { Override public void onChanged(Nullable Y y) { result.setValue(y); } }); } } } }); return result; }它本质上是监听source每次source更新就取消旧的mSource的addSource()再为新的mSource添加addSource()。这实现了“取消前一个请求发起新请求”的语义是网络请求场景的标配。但要注意switchMap()创建的MediatorLiveData本身也需要被observe()否则result.setValue(y)不会触发 UI 更新。很多人漏掉这一步以为switchMap()会自动绑定结果 UI 一直空白。6. 替代方案与演进从LiveData到StateFlow不是取代而是分工6.1StateFlow的优势协程原生、无生命周期绑定、支持distinctUntilChangedStateFlow是 Kotlin 协程 Flow 的一种特殊类型其核心是SharedFlow的变体具有replayCache默认为 1。它与LiveData的关键差异特性LiveDataStateFlow线程模型强制主线程setValue()postValue()跨线程tryEmit()可在任意线程collectLatest在协程中自动切回 UI 线程生命周期绑定必须observe(lifecycleOwner, ...)无内置绑定需手动lifecycleScope.launchWhenStarted { flow.collect { } }空值安全LiveDataT允许nullT?StateFlowT不允许null必须TStateFlowT?才允许去重无内置去重需distinctUntilChanged()StateFlow天然distinctUntilChanged相同值不触发collectStateFlow的replayCache 1意味着新订阅者会立即收到最新的值这解决了LiveData中observe()在STARTED后才收到值、可能错过初始化状态的问题。6.2 为什么StateFlow不能完全替代LiveDataLiveData的核心价值不在“数据流”而在“UI 层的生命周期契约”。StateFlow是一个通用的、跨平台的、协程友好的状态容器它可以用于 Android、iOS、Desktop甚至 Server。而LiveData是 Android 专属的、深度集成Lifecycle的 UI 工具。举个例子一个ViewModel里同时有val uiState: StateFlowUiState和val toastMessage: LiveDataString。前者驱动整个界面状态collectLatest后者只用于弹 Toastobserve()。因为 Toast 是瞬时 UI需要精确的STARTED状态控制——StateFlow的launchWhenStarted只保证协程启动时机但Toast.makeText().show()若在PAUSED状态调用系统会静默丢弃。而LiveData的LifecycleBoundObserver会确保onChanged()只在STARTED时调用Toast.show()必然成功。所以最佳实践是StateFlow用于主 UI 状态页面整体LiveData用于瞬时、副作用型 UI 操作Toast、Dialog、Snackbar。6.3SavedStateHandleLiveData的“持久化兄弟”SavedStateHandle是ViewModel的一部分它提供getLiveDataString(key)方法返回一个LiveData其值会自动保存和恢复通过Bundle。这解决了LiveData在Activity重建时数据丢失的问题。SavedStateHandle的LiveData本质是MutableLiveData的子类它重写了setValue()在设置新值时会同时调用handle.set(key, value)将值存入Bundle。当ViewModel重建时SavedStateHandle从Bundle恢复值并setValue()给LiveData触发 UI 更新。这使得LiveData从“易失”变为“可恢复”是构建健壮 UI 的关键拼图。例如搜索页的关键词、列表页的滚动位置都应通过SavedStateHandle.getLiveData()获取而非普通MutableLiveData。最后分享一个小技巧SavedStateHandle的LiveData在Activity重建后mLastVersion会被重置为 -1而mVersion是恢复后的值如 5所以5 -1成立dispatchingValue()会立即分发恢复的值UI 无缝衔接。这是SavedStateHandle比手动onSaveInstanceState()更优雅的地方——它把状态恢复和LiveData分发逻辑完全封装开发者只需getLiveData()即可。
