JetPack全家桶（二）之LifeCycle生命周期感知组件

一、Lifecycle 解决了什么问题

在 MVP/MVVM 架构普及之前，Presenter 或业务组件需要手动感知 Activity/Fragment 的生命周期。典型场景：一个位置管理器需要在 onResume 时启动定位、onPause 时停止定位，但 Presenter 并不知道宿主的生命周期变化，于是只能在每个生命周期回调里逐一调用 Presenter 的对应方法——这就是经典的”生命周期回调地狱”。

Lifecycle 组件的核心思想是让任何对象都能成为 LifecycleObserver（生命周期观察者），由 LifecycleOwner（生命周期持有者，如 Activity/Fragment）主动分发事件。这样业务组件只需用注解或接口声明对哪些生命周期事件感兴趣，而无需让宿主 Activity/Fragment 逐一手动转发。

二、核心接口与设计

Lifecycle 库定义了两个核心枚举：Event（ON_CREATE、ON_START、ON_RESUME、ON_PAUSE、ON_STOP、ON_DESTROY、ON_ANY）和 State（DESTROYED、INITIALIZED、CREATED、STARTED、RESUMED）。Event 代表生命周期事件的发生，State 则代表当前状态——State 是 Event 累积的结果。

LifecycleOwner 是一个只有一个方法 getLifecycle() 的接口，AppCompatActivity 和 Fragment 都已默认实现。LifecycleObserver 是标记接口，其子接口 DefaultLifecycleObserver 提供了 default 实现的回调方法，更方便使用。

2.1 State 与 Event 的关系图

Lifecycle 的状态机模型可以用以下状态转换图表示：

                ON_CREATE
INITIALIZED ───────────────► CREATED
                                │
                          ON_START
                                │
                                ▼
                            STARTED
                                │
                          ON_RESUME
                                │
                                ▼
                            RESUMED
                                │
                          ON_PAUSE
                                │
                                ▼
                            STARTED
                                │
                           ON_STOP
                                │
                                ▼
                            CREATED
                                │
                        ON_DESTROY
                                │
                                ▼
                          DESTROYED

关键点：State 是单调向前的，只能沿 INITIALIZED -> CREATED -> STARTED -> RESUMED 方向前进，不可逆（但可以通过 Event 让 State 降级，例如 ON_PAUSE 让 State 从 RESUMED 变为 STARTED）。

2.2 核心类图

┌─────────────────────┐
│   LifecycleOwner    │  (接口)
│  +getLifecycle()    │
└──────────┬──────────┘
           │ implements
    ┌──────┴──────────────────────┐
    │  ComponentActivity          │
    │  Fragment                   │
    │  (通过 ReportFragment)       │
    └─────────────────────────────┘
           │ 持有
    ┌──────▼──────────┐
    │   Lifecycle     │  (抽象类)
    │  +addObserver()  │
    │  +removeObserver()│
    │  +getCurrentState()│
    └──────┬──────────┘
           │ extends
    ┌──────▼──────────────┐
    │  LifecycleRegistry  │  (核心实现)
    │  -mState: State     │
    │  -mObserverMap      │
    │  +handleLifecycleEvent()│
    │  +moveToState()     │
    └─────────────────────┘
           │ 管理
    ┌──────▼──────────┐
    │ LifecycleObserver│  (标记接口)
    └──────┬──────────┘
           │ extends
    ┌──────▼──────────────────┐
    │DefaultLifecycleObserver │  (推荐使用)
    │+onCreate(owner)         │
    │+onStart(owner)          │
    │+onResume(owner)         │
    │+onPause(owner)          │
    │+onStop(owner)           │
    │+onDestroy(owner)        │
    └─────────────────────────┘

三、源码解析：事件如何传播

3.1 ReportFragment —— 生命周期的”窃听器”

在 AppCompatActivity 中（AOSP 路径：/frameworks/support/compat/ 下的 SupportActivity 或 ComponentActivity），ReportFragment 被注入到 Activity 中。这是一个没有 UI 的 Fragment，唯一的作用就是监听宿主的生命周期事件并上报给 LifecycleRegistry。

源码路径：lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java

// ReportFragment.java (简化版核心逻辑)
public class ReportFragment extends Fragment {

    public static void injectIfNeededIn(Activity activity) {
        if (Build.VERSION.SDK_INT >= 29) {
            // Android 10+ 使用 registerActivityLifecycleCallbacks
            LifecycleCallbacks.registerIn(activity);
        } else {
            // Android 9 及以下：注入无 UI 的 Fragment
            FragmentManager manager = activity.getFragmentManager();
            if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
                manager.beginTransaction()
                    .add(new ReportFragment(), REPORT_FRAGMENT_TAG)
                    .commit();
                manager.executePendingTransactions();
            }
        }
    }

    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
        dispatch(Lifecycle.Event.ON_CREATE);
    }

    @Override
    public void onStart() {
        super.onStart();
        dispatch(Lifecycle.Event.ON_START);
    }

    @Override
    public void onResume() {
        super.onResume();
        dispatch(Lifecycle.Event.ON_RESUME);
    }

    @Override
    public void onPause() {
        super.onPause();
        dispatch(Lifecycle.Event.ON_PAUSE);
    }

    @Override
    public void onStop() {
        super.onStop();
        dispatch(Lifecycle.Event.ON_STOP);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        dispatch(Lifecycle.Event.ON_DESTROY);
    }

    private void dispatch(Lifecycle.Event event) {
        Activity activity = getActivity();
        if (activity instanceof LifecycleRegistryOwner) {
            ((LifecycleRegistryOwner) activity).getLifecycle()
                .handleLifecycleEvent(event);
        }
    }
}

在 Android 10（API 29）及以上版本，Google 改用 Activity.registerActivityLifecycleCallbacks() 来替代 Fragment 方式，因为 Fragment 的注入和提交有事务开销，在高频场景（如屏幕旋转）下可能导致时序问题。

3.2 LifecycleRegistry —— 状态机核心

LifecycleRegistry 是整个 Lifecycle 组件的核心实现类。它内部维护了一个状态机，确保 State 只能前进不能后退，且会在状态变化时遍历所有已注册的 Observer 并调用对应回调。

源码路径：lifecycle/lifecycle-common/src/main/java/androidx/lifecycle/LifecycleRegistry.java

// LifecycleRegistry.java 核心结构
public class LifecycleRegistry extends Lifecycle {

    private State mState = INITIALIZED;

    // 使用 FastSafeIterableMap 存储所有 Observer
    // key: LifecycleObserver, value: ObserverWithState
    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
        new FastSafeIterableMap<>();

    // 处理生命周期事件的核心方法
    public void handleLifecycleEvent(Lifecycle.Event event) {
        State next = getStateAfter(event);  // 计算事件后的新状态
        moveToState(next);
    }

    // 计算事件后的状态
    static State getStateAfter(Event event) {
        switch (event) {
            case ON_CREATE:
            case ON_STOP:
                return CREATED;
            case ON_START:
            case ON_PAUSE:
                return STARTED;
            case ON_RESUME:
                return RESUMED;
            case ON_DESTROY:
                return DESTROYED;
            case ON_ANY:
                break;
        }
        throw new IllegalArgumentException("Unexpected event value " + event);
    }

    // 状态变迁核心逻辑
    private void moveToState(State next) {
        if (mState == next) {
            return;  // 状态未变，无需处理
        }
        mState = next;

        if (mHandlingEvent || mAddingObserverCounter != 0) {
            mNewEventOccurred = true;
            // 如果在事件处理过程中发生新的事件，先标记，稍后处理
            return;
        }
        mHandlingEvent = true;
        sync();  // 同步所有 Observer 到最新状态
        mHandlingEvent = false;
    }
}

3.3 sync() —— Observer 状态同步机制

sync() 是 LifecycleRegistry 中最精细的方法，它确保所有 Observer 的状态与宿主 LifecycleOwner 保持一致。

// LifecycleRegistry.sync() 的实现逻辑
private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is "
            + "already garbage collected.");
    }

    // 判断同步方向：向前（promote）还是向后（demote）
    while (!isSynced()) {
        mNewEventOccurred = false;

        // 如果最老的 Observer 状态落后于当前状态，向前推进
        // mObserverMap 中元素的顺序 == 添加顺序
        if (mState.compareTo(
                mObserverMap.eldest().getValue().mState) < 0) {
            backwardPass(lifecycleOwner);
        }

        // 如果最新的 Observer 状态领先于当前状态，向后倒退
        Map.Entry<LifecycleObserver, ObserverWithState> newest =
            mObserverMap.newest();
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            forwardPass(lifecycleOwner);
        }
    }

    mNewEventOccurred = false;
}

// 判断是否已同步：所有 Observer 的状态 == 当前 mState
private boolean isSynced() {
    if (mObserverMap.size() == 0) {
        return true;
    }
    State eldestObserverState = mObserverMap.eldest().getValue().mState;
    State newestObserverState = mObserverMap.newest().getValue().mState;
    return eldestObserverState == newestObserverState && mState == newestObserverState;
}

向前推进（forwardPass）：从最新的 Observer 向最老的遍历，将状态落后的 Observer 依次提升到当前 mState。

向后倒退（backwardPass）：从最老的 Observer 向最新的遍历，将状态超前的 Observer 依次降低到当前 mState。这在 Activity 生命周期调用出错（例如 onPause 被调用但 onResume 未完整执行）时作为防御性措施。

3.4 ObserverWithState —— Observer 的包装器

// LifecycleRegistry.java 内部类
static class ObserverWithState {
    State mState;                          // 当前 Observer 的状态
    LifecycleEventObserver mLifecycleObserver;  // 实际的 Observer

    ObserverWithState(LifecycleObserver observer, State initialState) {
        // 将 LifecycleObserver 适配为 LifecycleEventObserver
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
        mState = initialState;
    }

    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = getStateAfter(event);
        mState = min(mState, newState);  // 更新 Observer 状态
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

3.5 Lifecycling —— Observer 适配层

Lifecycling 类负责将不同类型的 Observer（注解方式 vs 接口方式）适配为统一的 LifecycleEventObserver：

// Lifecycling.java
@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
    // 1. 如果已经是 LifecycleEventObserver，直接使用
    boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
    // 2. 如果是 FullLifecycleObserver（DefaultLifecycleObserver），使用 FullLifecycleObserverAdapter
    boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
    if (isLifecycleEventObserver && isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter(
            (FullLifecycleObserver) object, (LifecycleEventObserver) object);
    }
    if (isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
    }
    if (isLifecycleEventObserver) {
        return (LifecycleEventObserver) object;
    }
    // 3. 如果使用注解（@OnLifecycleEvent），通过反射生成适配器
    final Class<?> klass = object.getClass();
    int type = getObserverConstructorType(klass);
    if (type == GENERATED_CALLBACK) {
        // 使用编译期生成的代码（通过 lifecycle-compiler APT）
        List<Constructor<? extends GeneratedAdapter>> constructors =
            sClassToAdapters.get(klass);
        if (constructors.size() == 1) {
            return new SingleGeneratedAdapterObserver(
                createGeneratedAdapter(constructors.get(0), object));
        }
        GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];
        for (int i = 0; i < constructors.size(); i++) {
            adapters[i] = createGeneratedAdapter(constructors.get(i), object);
        }
        return new CompositeGeneratedAdaptersObserver(adapters);
    }
    // 4. 最后的 fallback：使用反射解析注解
    return new ReflectiveGenericLifecycleObserver(object);
}

注解方式 vs 接口方式：

• 注解方式（@OnLifecycleEvent）：早期方案，通过 APT（lifecycle-compiler）在编译期生成适配器类，避免运行时反射。但由于注解需要额外的注解处理器依赖，且不如接口方式直观，现在已逐渐被 DefaultLifecycleObserver 取代。
• 接口方式（DefaultLifecycleObserver/LifecycleEventObserver）：更直接、无反射、类型安全，是当前推荐的方式。

3.6 ComponentActivity 中的初始化流程

// ComponentActivity.java (androidx.activity)
public class ComponentActivity extends Activity
        implements LifecycleOwner, ViewModelStoreOwner, ... {

    private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // 注入 ReportFragment（API < 29）或注册 ActivityLifecycleCallbacks（API >= 29）
        ReportFragment.injectIfNeededIn(this);
        // 触发 ON_CREATE 事件
        // ...
    }

    @NonNull
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
}

3.7 Fragment 中的 Lifecycle 实现

Fragment 的 Lifecycle 实现与 Activity 类似，但其生命周期事件由 Fragment 内部直接分发，不需要 ReportFragment 中间层：

// Fragment.java (androidx.fragment)
public class Fragment implements LifecycleOwner, ... {
    LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

    void performCreate(Bundle savedInstanceState) {
        // ...
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
    }

    void performStart() {
        // ...
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
    }

    void performResume() {
        // ...
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
    }

    // ... 其他生命周期方法同理
}

四、实践示例

4.1 基本用法：DefaultLifecycleObserver

class LocationManager : DefaultLifecycleObserver {
    override fun onResume(owner: LifecycleOwner) {
        startLocationUpdates()
    }
    override fun onPause(owner: LifecycleOwner) {
        stopLocationUpdates()
    }
}

// 在 Activity 中使用
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycle.addObserver(LocationManager())
        // LocationManager 自动响应生命周期，无需在 Activity 中手动管理
    }
}

4.2 高级用法：LifecycleEventObserver

当需要处理 ON_ANY 事件或对多个事件做统一处理时，可以使用 LifecycleEventObserver：

class AnalyticsTracker : LifecycleEventObserver {
    override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
        when (event) {
            Lifecycle.Event.ON_RESUME -> trackScreenView(source.javaClass.simpleName)
            Lifecycle.Event.ON_PAUSE -> trackScreenExit(source.javaClass.simpleName)
            else -> { /* 忽略其他事件 */ }
        }
    }
}

4.3 LifecycleOwner 的自定义实现

有时我们需要在一个非 Activity/Fragment 的类中实现 LifecycleOwner，例如自定义 UI 组件或 Service：

class MyMediaPlayer : LifecycleOwner {
    private val lifecycleRegistry = LifecycleRegistry(this)

    init {
        lifecycleRegistry.currentState = Lifecycle.State.INITIALIZED
    }

    fun prepare() {
        lifecycleRegistry.currentState = Lifecycle.State.CREATED
        lifecycleRegistry.currentState = Lifecycle.State.STARTED
    }

    fun play() {
        lifecycleRegistry.currentState = Lifecycle.State.RESUMED
    }

    fun stop() {
        lifecycleRegistry.currentState = Lifecycle.State.CREATED
    }

    fun release() {
        lifecycleRegistry.currentState = Lifecycle.State.DESTROYED
    }

    override fun getLifecycle(): Lifecycle = lifecycleRegistry
}

4.4 ProcessLifecycleOwner —— 应用前后台感知

Lifecycle 库还提供了 ProcessLifecycleOwner，用于监听整个应用进程的前后台状态变化：

// 在 Application.onCreate() 中注册
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        ProcessLifecycleOwner.get().lifecycle.addObserver(AppLifecycleTracker())
    }
}

class AppLifecycleTracker : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // 应用进入前台（第一个 Activity 变为可见时触发一次）
        Log.d("AppLifecycle", "App came to foreground")
    }

    override fun onStop(owner: LifecycleOwner) {
        // 应用进入后台（最后一个 Activity 变为不可见时触发一次）
        Log.d("AppLifecycle", "App went to background")
    }
}

ProcessLifecycleOwner 内部原理：

1. 通过 ActivityLifecycleCallbacks 注册到 Application，监控所有 Activity 的生命周期。
2. 使用一个计数器追踪前台 Activity 的数量。当第一个 Activity 的 onStart 被调用时，计数从 0 变为 1，触发 ON_START 事件。当最后一个 Activity 的 onStop 被调用时，计数从 1 变为 0，延迟 700ms 后触发 ON_STOP 事件（延迟是为了处理快速切换 Activity 的情况，避免误判）。
3. ON_RESUME 和 ON_PAUSE 同理。

4.5 lifecycleScope 与协程的配合

lifecycle-runtime-ktx 提供了 lifecycleScope 扩展，它是一个绑定到 Lifecycle 的 CoroutineScope：

class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // 当 Lifecycle 变为 DESTROYED 时自动取消协程
        lifecycleScope.launch {
            // 这里的代码在 lifecycle 销毁时自动取消
            while (isActive) {
                val data = fetchData()
                updateUI(data)
                delay(1000)
            }
        }

        // 更精细的控制：只在特定状态下执行
        lifecycleScope.launchWhenStarted {
            // 仅在 STARTED 及以上状态执行
            // 暂停在 STARTED 以下时协程挂起，回到 STARTED 时恢复
        }

        // Android lifecycle-runtime-ktx 2.4+ 推荐的 API
        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                // 进入 STARTED 状态时启动，离开 STARTED 时取消
                // 每次重新进入 STARTED 时重新启动（与 launchWhenStarted 不同，
                // launchWhenStarted 只是挂起/恢复，不会重新启动）
                viewModel.data.collect { data ->
                    updateUI(data)
                }
            }
        }
    }
}

4.6 SavedStateHandle 与 Lifecycle 的集成

SavedStateHandle 是 ViewModel 的一个扩展，它利用 Lifecycle 来判断何时应该恢复保存的状态：

class MyViewModel(savedStateHandle: SavedStateHandle) : ViewModel() {
    val query: LiveData<String> = savedStateHandle.getLiveData("query", "")

    fun search(newQuery: String) {
        savedStateHandle["query"] = newQuery
        // 当进程被系统杀掉时，SavedStateHandle 中的数据会通过
        // onSaveInstanceState 机制被保存，恢复时自动填充回 ViewModel
    }
}

五、Lifecycle 与 JetPack 其他组件的集成

Lifecycle 是整个 JetPack 生态的基础设施，几乎所有其他组件都依赖它：

                     ┌─────────────────┐
                     │    Lifecycle     │
                     └────────┬────────┘
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
┌──────▼──────┐      ┌───────▼───────┐      ┌───────▼───────┐
│  LiveData   │      │   ViewModel   │      │ lifecycle-    │
│  (自动取消   │      │ (onCleared    │      │ viewmodel     │
│   订阅)     │      │  时机由       │      │ -ktx          │
│            │      │  Lifecycle    │      │ (viewModel    │
│            │      │  决定)        │      │  Scope)       │
└─────────────┘      └───────────────┘      └───────────────┘
       │                      │                      │
       └──────────────────────┼──────────────────────┘
                              │
                 ┌────────────▼────────────┐
                 │  Room (Invalidation     │
                 │  Tracker 感知           │
                 │  Lifecycle 状态决定      │
                 │  是否推送数据给 UI)       │
                 └─────────────────────────┘

六、常见陷阱与最佳实践

6.1 不要在 LifecycleObserver 中做耗时操作

LifecycleRegistry.moveToState() 和 sync() 方法是在主线程同步执行的。如果在 Observer 的回调中执行耗时操作（如网络请求、数据库查询），会阻塞主线程，导致 UI 卡顿甚至 ANR。

// 错误做法
class SlowObserver : DefaultLifecycleObserver {
    override fun onResume(owner: LifecycleOwner) {
        // 这会阻塞主线程！
        Thread.sleep(5000)
    }
}

// 正确做法
class FastObserver(private val scope: CoroutineScope) : DefaultLifecycleObserver {
    override fun onResume(owner: LifecycleOwner) {
        scope.launch(Dispatchers.IO) {
            // 耗时操作在后台线程执行
            val data = loadDataFromDisk()
            withContext(Dispatchers.Main) {
                updateUI(data)
            }
        }
    }
}

6.2 addObserver 时的初始状态分发

当向 LifecycleRegistry 添加新的 Observer 时，它会立即收到当前状态的同步回调。这意味着如果你在 onResume 中添加一个 Observer，它会立即收到 ON_CREATE、ON_START、ON_RESUME 的连续回调（取决于当前的状态）：

class MyActivity : AppCompatActivity() {
    override fun onResume() {
        super.onResume()
        lifecycle.addObserver(object : DefaultLifecycleObserver {
            override fun onResume(owner: LifecycleOwner) {
                // 这个回调会立即被调用！
                Log.d("Lifecycle", "Observer's onResume called immediately")
            }
        })
    }
}

这个特性使得 ViewModel 可以在补获（late-observe）时仍然能得到最新数据。

6.3 LifecycleOwner 的内存管理

LifecycleRegistry 使用 WeakReference 持有 LifecycleOwner：

// LifecycleRegistry.java
private final WeakReference<LifecycleOwner> mLifecycleOwner;

public LifecycleRegistry(@NonNull LifecycleOwner provider) {
    mLifecycleOwner = new WeakReference<>(provider);
    mState = INITIALIZED;
}

这意味着即使 LifecycleOwner（如 Activity）被 GC 回收，LifecycleRegistry 仍然能存活直到所有 Observer 的引用也被释放。这个设计避免了循环引用导致的内存泄漏。

七、Android 不同版本的适配

7.1 API 29+ 的变化

// ReportFragment.java
if (Build.VERSION.SDK_INT >= 29) {
    // 使用 registerActivityLifecycleCallbacks 替代 Fragment 注入
    LifecycleCallbacks.registerIn(activity);
}

API 29+ 通过 registerActivityLifecycleCallbacks 直接监听生命周期，避免了 Fragment 事务的开销和可能的时序问题。

7.2 API 24+ 的优化

从 Android 7.0 开始，ART 对反射方法进行了性能优化。Lifecycle 的 Lifecycling 类在不同 API 级别采用不同的 Observer 适配策略：

• **API 29+**：使用 ActivityLifecycleCallbacks，性能最优
• API 24 - 28：使用 Fragment 注入（通过 android.app.Fragment）
• API < 24：使用 Fragment 注入 + 反射回调

面试常考问题

Q1: Lifecycle 如何避免内存泄漏？

A: 当 LifecycleOwner 的 State 变为 DESTROYED 时，LifecycleRegistry 会自动移除所有 Observer 的引用，Observer 持有的任何资源也会随之释放。无需像手动方案那样在 onDestroy 中调用取消订阅。源码中 LifecycleRegistry.addObserver() 方法会在添加 Observer 后检查当前 State，如果已是 DESTROYED 则立即移除新加入的 Observer。具体实现上：

1. moveToState(DESTROYED) 会遍历 mObserverMap，将每个 Observer 的状态同步到 DESTROYED。
2. sync() 中的 backwardPass 在同步完成后，所有 Observer 的 State 都等于 mState(DESTROYED)。
3. 下次 sync() 时，会检测并清理无效的 Observer。
4. LifecycleRegistry 本身通过 WeakReference 持有 LifecycleOwner，不会阻止 Owner 的 GC。

这种机制的核心优势在于：取消订阅的逻辑内聚在 Lifecycle 框架中，而非散落在各个组件的手动 onDestroy 调用中。

Q2: Event 和 State 的关系是什么？getStateAfter(Event) 的设计原理是什么？

A: State 是组件当前所处的状态点（如 RESUMED），Event 是触发状态迁移的动作（如 ON_PAUSE 事件导致从 RESUMED 变为 STARTED）。LifecycleRegistry 内部维护了一个状态机，通过 getStateAfter(Event) 来计算事件发生后的新状态，同时确保状态只能沿 DESTROYED -> INITIALIZED -> CREATED -> STARTED -> RESUMED 的方向前进（不可逆）。

getStateAfter 的实现非常简洁：

ON_CREATE    -> CREATED
ON_START     -> STARTED
ON_RESUME    -> RESUMED
ON_PAUSE     -> STARTED
ON_STOP      -> CREATED
ON_DESTROY   -> DESTROYED

注意：ON_CREATE 和 ON_STOP 都映射到 CREATED 状态。当一个 Activity 从 RESUMED 经历 ON_PAUSE -> ON_STOP 后，最终 State 是 CREATED，而不是 DESTROYED。只有当经历完整的销毁流程（ON_STOP -> ON_DESTROY）后，State 才会变为 DESTROYED。

Q3: 如果我在 ON_STOP 事件中启动协程操作，协程未完成 Activity 就销毁了怎么办？

A: 这正是 Lifecycle 需要搭配 lifecycleScope（Lifecycle KTX 扩展）的原因。lifecycleScope 在 Lifecycle 销毁时自动取消所有启动的协程，避免了无效操作继续执行。相比之下，纯 Lifecycle Observer 只提供回调，不负责任务取消，所以更推荐在协程场景下使用 lifecycleScope.launchWhenStarted {} 或 repeatOnLifecycle。

lifecycleScope 的源码实现：

// lifecycle-runtime-ktx 中的扩展属性
val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
    get() = lifecycle.coroutineScope

// LifecycleCoroutineScope 在 Lifecycle 变为 DESTROYED 时自动取消
// 内部通过 LifecycleEventObserver 监听 DESTROYED 事件

repeatOnLifecycle vs launchWhenStarted 的区别：

• launchWhenStarted：协程在 STARTED 以下状态挂起（suspend），恢复到 STARTED 以上时继续。这意味着如果数据在挂起期间变化了 N 次，协程恢复后会依次处理这些变化。
• repeatOnLifecycle：每次进入目标状态时重新启动协程 lambda，离开时取消。这保证了每次观察（collect）都是”新鲜”的，不会有积压的数据。

Q4: ReportFragment 为什么在 API 29+ 被替换？有什么缺陷？

A: 在 API 29 之前，Lifecycle 通过在 Activity 中注入一个无 UI 的 ReportFragment 来感知生命周期。这个方案有以下缺陷：

1. Fragment 事务开销：Fragment 的 commit() 不是立即执行的，需要 executePendingTransactions() 来确保 Fragment 已添加。这在某些时序敏感的场景下可能导致问题。
2. 嵌套 Fragment 问题：如果 Activity 本身使用了 Fragment，ReportFragment 的注入可能与用户的 Fragment 事务发生冲突。
3. 生命周期回调顺序：Fragment 的 onActivityCreated 回调可能在 Activity 的 onCreate 之后才调用，导致 ON_CREATE 事件延迟分发。
4. AndroidX Fragment 版本兼容性：不同版本的 Fragment 库对 commit() 实现有差异，可能导致行为不一致。

API 29+ 改用 ActivityLifecycleCallbacks 的优势：

• 直接通过系统回调，无 Fragment 事务开销
• 时序精确，与 Activity 生命周期完全同步
• 不需要注入任何 UI 元素

Q5: 如何自己实现一个 LifecycleOwner？需要注意什么？

A: 实现自定义 LifecycleOwner 的关键步骤：

1. 持有 LifecycleRegistry 实例，在构造函数中传入 this。
2. 在合适的时机调用 lifecycleRegistry.handleLifecycleEvent() 分发事件。
3. 实现 getLifecycle() 方法返回 LifecycleRegistry。

注意事项：

• LifecycleRegistry 只能被一个线程访问——所有 handleLifecycleEvent 调用必须在同一个线程（通常是主线程）进行。
• 状态必须是单调向前的——不要跳过中间状态（例如不能直接从 INITIALIZED 跳到 RESUMED）。每个中间状态都需要经历：INITIALIZED -> CREATED -> STARTED -> RESUMED。
• 如果在 onDestroy（即 State == DESTROYED）之后还有 Observer 尝试添加，LifecycleRegistry 会直接将其忽略并抛出异常或警告。
• 对于销毁状态后不应再有事件分发。

核心参考 AOSP 路径：

• lifecycle/lifecycle-common/src/main/java/androidx/lifecycle/LifecycleRegistry.java — 状态机核心
• lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java — Fragment 注入
• lifecycle/lifecycle-common/src/main/java/androidx/lifecycle/Lifecycling.java — Observer 适配
• lifecycle/lifecycle-process/src/main/java/androidx/lifecycle/ProcessLifecycleOwner.java — 应用前后台感知
• lifecycle/lifecycle-runtime-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt — 协程集成
• activity/activity/src/main/java/androidx/activity/ComponentActivity.java — Activity 集成入口
• fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java — Fragment Lifecycle 实现