LiveData原理剖析：版本号机制与生命周期感知全解析

Jetpack 里的 LiveData 大家天天用，但它可能是被误读最多的一个组件：表面是观察者模式，底层却藏了一套版本号加生命周期状态机的联动机制。上一篇把用法和常见坑整完了，这一篇直接对照源码讲原理，把 setValue、postValue、observe 背后发生的事一次性说清楚。适合已经写过一段时间 LiveData、想从"会用"走向"会排查"的 Android 开发者，也适合准备面试时被问到"LiveData 为什么不会泄漏"这类问题的同学。

1. 从一行observe开始：LiveData内部到底维护了什么东西

很多同学第一天用 LiveData 时，感受是"真香"，但没想过为什么香。我们先回到最常用的一段代码：

private val status = MutableLiveData<Boolean>() status.observe(this, Observer { ready -> updateButton(ready) }) status.value = true

运行结果大家都很熟：setValue(true) 之后观察者被回调；Activity 销毁后不会崩；从后台回来如果值又被改过，页面恢复时也能拿到最新状态。但这段代码背后其实有一条完整的内部链路：setValue把值写进内存并递增一个版本号；观察者对象被包装成新的内部节点，注册到成员变量mObservers里；当数据变化时，LiveData 会遍历所有观察者包装节点，逐个判断"这个观察者当前是否活跃、它上次收到的版本号是否比全局版本号旧"，条件全部满足才会真正回调用户代码。

LiveData 的核心成员变量基本就是下面这些，把它们记熟，后面的原理全都能串起来：

private volatile int mVersion; private final Object mDataLock = new Object(); private volatile Object mData = NOT_SET; private volatile Object mPendingData = NOT_SET; private boolean mDispatchingValue = false; private boolean mDispatchInvalidated = false; private int mActiveCount = 0; private final SafeIterableMap<Observer<? super T>, ObserverWrapper> mObservers = ...

mVersion是全局节拍，每次 setValue 都会自增；mData是当前数据，初始 NOT_SET 表示还没有值；mPendingData是 postValue 在后台线程暂存、等待主线程结算的数据；mDispatchingValue和mDispatchInvalidated组成派发过程中的重入保护；mActiveCount统计活跃观察者数量，用于触发 onActive/onInactive；mObservers则是整个订阅关系的核心容器，保存着"用户观察者到内部包装对象"的映射。

容器选择 SafeIterableMap 而不是 HashMap，这一点特别值得展开。LiveData 在遍历观察者派发数据时，回调里完全可能再次对同一个 LiveData 做removeObserver或observe。普通 Map 在遍历过程中被结构性修改，十有八九要抛ConcurrentModificationException。SafeIterableMap 的实现思路类似一个支持安全边遍历边修改的链表，专门为"遍历中变更"这种场景设计。这也解释了为什么你会看到一些看起来有点怪但合法的用法：在 onChanged 里收到一次值后立刻 removeObserver，把自己从订阅里摘掉，实现"只消费一次"的效果。

理解这套成员变量之后，后面所有源码都只是回答三个问题：数据怎么存、什么时候该通知谁、通知之前要做什么过滤。带着这三个问题去读源码，会比直接看方法调用轻松很多。

2. mVersion：LiveData的版本号机制，粘性事件和重复回调都从这来

先从 setValue 的源码开始：

@MainThread protected void setValue(T value) { assertMainThread("setValue"); mVersion++; mData = value; dispatchingValue(null); }

assertMainThread保证 setValue 只能在主线程调用；mVersion++给数据打上新版本号；mData = value写入内存；dispatchingValue(null)开始派发。注意这里传的是 null，意思是"通知所有观察者"；如果传具体某个包装对象，就只通知那一个观察者。

派发过程中最关键的是considerNotify这个方法：

private void considerNotify(ObserverWrapper observer) { if (!observer.mActive) { return; } if (!observer.shouldBeActive()) { observer.activeStateChanged(false); return; } if (observer.mLastVersion >= mVersion) { return; } observer.mLastVersion = mVersion; observer.mObserver.onChanged((T) mData); }

三个判断分别回答了三个问题：

第一个问题，观察者当前活跃吗？mActive为 false，说明生命周期不在前台，LiveData 不会回调这个观察者。第二个问题，生命周期状态真的适合回调吗？shouldBeActive()返回 false 时，说明主人已经退到后台，LiveData 会顺手把 observer 切到 inactive，避免后续继续无意义派发。第三个问题，这个观察者已经消费到哪个版本了？如果mLastVersion >= mVersion，说明这条数据它已经见过了，不需要再通知。

这个设计带来一个很多新手误解的结论：LiveData 不会因为两次 setValue 的值相同就去重。比如连续执行：

liveData.value = "hello" liveData.value = "hello"

第一次版本从 -1 变 0，第二次从 0 变 1，两次都会触发回调。版本机制保证的是"有序"和"最新"，不是"与旧值不同"。想实现值去重，得自己在 setValue 之前做比较，或者用distinctUntilChanged这类组合操作。

粘性事件也完全源于版本号。新 observer 包装对象的mLastVersion初始值是START_VERSION = -1。如果 LiveData 当前已经 setValue 过若干次，mVersion肯定大于等于 0，那么一旦considerNotify被触发，-1 < 当前版本条件成立，新观察者就会立刻收到一个早于注册时间的数据。这就是"后注册的观察者也会收到注册前的最新值"的底层原因。

同理，Activity 从后台回到前台时，LiveData 会把恢复活跃的那个观察者单独派发一次，代码里对应的是dispatchingValue(this)。如果这个观察者上次消费版本低于当前版本，就会收到最新值。这不是玄学，是版本比对后的"补发"。

实际项目中，粘性事件的坑往往出现在事件型数据上。比如用一个MutableLiveData<Boolean>表示"操作成功"，页面还没创建时就 set 过 true，之后才 observe，观察者一进来就收到 true，导致页面做出一次并非用户触发的弹窗。原理清楚了，你就知道单纯把 value 清空不可靠，还是应该把事件包一层专用结构，或者做版本差异化处理。

3. setValue与postValue：主线程约束、后值覆盖和消息合并

setValue 的第一行代码是assertMainThread("setValue")，它内部通过ArchTaskExecutor.getInstance().isMainThread()判断当前线程。不在主线程，直接抛IllegalStateException: Cannot invoke setValue on a background thread。

为什么 LiveData 要这么强硬？因为它的观察者回调默认跑在主线程，生命周期状态也只允许在主线程变化。如果在子线程直接同步回调，且不经过 Handler 队列，就会出现两个线程同时操作mVersion、mActiveCount、mData这些状态成员的竞态。为了保持实现简单可靠，官方就把 setValue 钉死在主线程，后台线程只能走 postValue。

postValue 的实现看起来短，信息量却很大：

protected void postValue(T value) { boolean postToMainThread; synchronized (mDataLock) { postToMainThread = mPendingData == NOT_SET; mPendingData = value; } if (!postToMainThread) { return; } ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable); }

mPostValueRunnable 内部大概是这样的：

mPostValueRunnable = () -> { Object newValue; synchronized (mDataLock) { newValue = mPendingData; mPendingData = NOT_SET; } setValue((T) newValue); };

mPendingData由mDataLock保护，任何线程都能安全写入。它只保留最后一次 post 进来的值。关键技巧在postToMainThread这个标记上：如果已经有值挂起、正在等待主线程结算，再次 post 只更新 pending 数据，不再重复向主线程投递任务。也就是说，只有第一次 post 会真正往主线程队列里放一个 runnable，后续 post 都只是在"合并"。

这就决定了 postValue 的几个重要行为：

连续多次 postValue，中间值会被后值覆盖。比如主线程繁忙时快速执行postValue(1); postValue(2); postValue(3)，最后观察者很可能只收到 3。postValue 也不能保证后台线程调用顺序和 UI 回调顺序完全一致，因为它只是把"取最后一个待结算值"的任务投递到主线程。如果你在后台线程做了耗时计算，最后把结果 postValue 回来，这是标准做法；但想用 postValue 连续推进进度条，就要斟酌了，它天然会丢中间进度点。

我在真实项目里的做法是：后台线程负责计算，主线程拿到最终结果后直接 setValue。需要展示过程状态时，不要用同一个 LiveData 高频 post 中间值，而是把中间状态合并成一个携带当前进度和阶段的结构，一次 post 出去，UI 层收到后自己处理动画过渡。这样既避开 postValue 的丢值问题，又不牺牲流畅度。

还有一个容易忽略的细节：setValue 因为被钉死主线程，数据写入不需要额外加锁，主线程本身就是天然的串行点。而 postValue 必须加锁，因为它可能从任意一个子线程进来。两者的线程模型完全不同，这也能解释为什么你在子线程调用 setValue 会立刻炸、调用 postValue 却很安静。

4. 观察者的三层封装：observe到底把谁放进了容器

observe 调用之后，第一件事并不是立刻注册，而是做一层很重的封装。看源码：

@MainThread public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) { assertMainThread("observe"); if (owner.getLifecycle().getCurrentState() == DESTROYED) { return; } LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer); ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper); if (existing != null && !existing.isAttachedTo(owner)) { throw new IllegalArgumentException( "Cannot add the same observer with different lifecycles"); } if (existing != null) { return; } owner.getLifecycle().addObserver(wrapper); }

有几个点值得细看。如果 owner 已经处于 DESTROYED，observe 直接返回，因为注册一个已经销毁页面的观察者没有任何意义。之后putIfAbsent保证同一个 observer 对象不会重复放进容器。如果同一个 observer 曾经绑定过另一个 LifecycleOwner，会抛IllegalArgumentException，提示 "Cannot add the same observer with different lifecycles"。这是很多同学在 Fragment 和 Activity 之间混用同一个观察者时踩到的坑。

包装完之后，LiveData 把 LifecycleBoundObserver 作为 LifecycleEventObserver 注册到owner.getLifecycle()。然后生命周期状态机每次变化，都会回调这个内部观察者的onStateChanged。

LifecycleBoundObserver 的shouldBeActive()实现只有一个判断：

boolean shouldBeActive() { return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED); }

也就是说生命周期处于 STARTED 或 RESUMED 时观察者活跃，处于 INITIALIZED 或 CREATED 时不活跃。这样设计是有讲究的：Activity 在 onStart 之后才需要更新 UI，onStop 之后已经不可见，自然没必要再让 LiveData 反复回调 UI。

onStateChanged 的处理更精妙：

@Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) { if (source.getLifecycle().getCurrentState() == DESTROYED) { removeObserver(mObserver); return; } activeStateChanged(shouldBeActive()); }

一旦页面销毁，LiveData 立刻从自己的观察者容器里移除这个内部包装，完成双向解绑。而activeStateChanged负责切换 observer 的 active 状态，并维护 mActiveCount：

void activeStateChanged(boolean newActive) { if (newActive == mActive) { return; } mActive = newActive; boolean wasInactive = mActiveCount == 0; mActiveCount += newActive ? 1 : -1; if (wasInactive && newActive) { onActive(); } if (mActiveCount == 0 && !newActive) { onInactive(); } if (newActive) { dispatchingValue(this); } }

mActiveCount 从 0 变 1 时触发onActive()，从 1 变 0 时触发onInactive()。这两个回调可以用来控制数据源开关。例如自定义 LiveData 时，可以在 onActive 里启动网络监听或定时任务，在 onInactive 时停止，避免页面都退到后台了还在做无谓消耗。由于 LiveData 维护的是"是否还有至少一个活跃观察者"，多个页面同时 observe 同一个 LiveData 时，也不会重复开关上游。

observeForever用的是另一种包装：AlwaysActiveObserver。它的shouldBeActive()恒为 true，不随任何生命周期变化，也不会自己解绑。所以用了observeForever的观察者必须手动removeObserver，否则就是内存泄漏的标准姿势。

5. 生命周期感知的真相：自动移除是如何发生的

很多文章说 LiveData 有生命周期感知能力，但没说清楚感知的机制。其实它几乎没有自己判断生命周期，所有状态变化都来自LifecycleOwner。observe(owner, observer)传入的 owner 本身实现了 LifecycleOwner，它的lifecycle是一台 LifecycleRegistry 状态机。

LiveData 要做的就是往这台状态机上注册一个 LifecycleEventObserver。状态机每次转换，比如 Activity 执行 onStart、onStop、onDestroy，都会通知所有注册的 LifecycleEventObserver。LiveData 在这个通知里只做两件事：非 DESTROYED 时，根据当前状态刷新内部观察者的 active 状态；DESTROYED 时，把自己从观察者容器里移除。

这就说明了为什么 observe 里必须传 LifecycleOwner 而不是直接传 Activity 对象。LifecycleOwner 提供的是一个标准、统一、可被测的状态来源，让 LiveData 不必关心具体是谁在观察。而且这个设计也避免了开发者在 onDestroy 里手动 removeObserver 时最容易出现的遗漏问题：手动解除订阅不是不可以，但很容易漏，漏一次就泄漏一次。

配置变更场景则完全是另一套逻辑。Activity 因为旋转等原因销毁重建时，DESTROYED 照样会触发，LiveData 会把旧页面的观察者移除。但数据本身放在 ViewModel 里，ViewModel 并不随着 Activity 重建而丢弃。所以当新的 Activity 重新 observe 同一个 LiveData 时，mVersion 依然延续旧的进度，新观察者的 mLastVersion 是 -1，会立即拿到当前最新数据。这套配合正是 LiveData 能在页面重建后自动恢复数据、还不用手动恢复的原因。

内存泄漏的根源，本质上是"长生命周期对象持有了短生命周期对象的引用"。LiveData 做对的事情，就是让观察关系不越过生命周期的边界：页面销毁，观察关系解除；页面重建，观察关系重新建立。反观 observeForever，因为绕过了生命周期，等于主动放弃了这条边界，才成为泄漏高发点。

这里可以列一个简单对比表，方便记忆：

如果还是怕泄漏，可以养成一个习惯：在页面 onDestroy 或 onCleared 里统一检查"还有没有没清理的 observeForever"。不过在多数业务场景里，优先用 observe 就够用了。

6. 从原理反推出来的实操法则和扩展思路

最后把这套原理放到真实开发中验证。第一个高频坑：在子线程用同一个 LiveData 连续 postValue 更新 UI 状态。初学时常想当然地认为 postValue 会把每一次数据都按顺序送到主线程，实际它只会保留最后一次。所以正确姿势是把中间过程的好几个状态合并成一个"快照"结构，一次 post 出去，UI 收到后自己处理中间态。

第二个坑：observeForever 用完不清理。源码层面它就是一个永不失效的观察者。我一度在某个工具类里对全局数据做 observeForever，页面退出后仍然收到回调。排查后才发现，那个工具类持有的页面引用虽然是弱引用，但观察者本身一直被 LiveData 容器强持有。后来统一改成在页面 onStop 里主动调用 removeObserver，或者干脆换成带生命周期的 observe。

第三个坑：把事件型数据硬塞进 LiveData。粘性事件不是 bug，是设计。但在登录、弹窗、跳转这类一次性事件上直接用 LiveData，就会频繁遇到"页面刚打开就弹出上一次残留事件"的情况。基于原理，我的做法是：UI 状态用普通 LiveData，一次性事件单独用一个带事件标记的包装数据，消费后手动清空，或者用 MediatorLiveData 做二次分发。

MediatorLiveData 是 LiveData 家族里最有扩展价值的一个类。它内部把多个 LiveData 作为 source，在源数据变化时回调你写的合并逻辑，再通过 setValue 把结果抛给下游。所有 source 的订阅回收都封装在 onActive/onInactive 中，这让组合数据源的开关成本很低。比如：

val result = MediatorLiveData<String>() result.addSource(repoData) { data -> result.value = mapToUiModel(data) }

repoData 每次变化都会经过 map 映射，再给 result 赋值。因为 result 本身也是 LiveData，它的观察者照常走版本号校验，粘性和自动清理机制也一并生效。

还可以基于这套机制自己写扩展。比如一个简单的防抖 LiveData，就是重写 setValue，把真实的 set 延后到去抖窗口结束后再执行：

class DebounceLiveData<T>( private val delayMs: Long ) : MutableLiveData<T>() { private val handler = Handler(Looper.getMainLooper()) private var pendingValue: T? = null private val debounceRunnable = Runnable { pendingValue?.let { super.setValue(it) } pendingValue = null } override fun setValue(value: T) { pendingValue = value handler.removeCallbacks(debounceRunnable) handler.postDelayed(debounceRunnable, delayMs) } }

虽然只有几十行，但因为完全基于 LiveData 的派发模型，它的观察者照旧享受生命周期感知，主线程回调也照旧成立。这就是理解原理带来的自由度：LiveData 并不是一套不能动的黑盒，它把"数据存储、版本过滤、生命周期状态"拆得很开，你在任意一环都可以插入自己的逻辑。

我在项目里试过给 LiveData 加 distinct 去重、加超时清理、加双写合并，核心都只是动版本号和 setValue 时机。你只要把 mVersion、mPendingData、mActiveCount 这几个角色记清楚，遇到 LiveData 行为异常，基本都能在源码里定位到原因。这也正是花时间啃原理最值得的地方。