Lifecycle 深度解析：LifecycleOwner与LifecycleObserver原理，如何自定义LifecycleOwner，在项目中的最佳实践

说实话，Jetpack 全家桶里哪个组件最基础？我肯定会投 Lifecycle 一票。

为什么？因为 Activity 和 Fragment 的生命周期管理，是 Android 开发永恒的痛点。你想想看，多少 bug 是因为在 onStop 之后还更新 UI 导致的？多少内存泄漏是因为忘记在 onDestroy 里解注册？

Lifecycle 这个组件，说白了就是给这些痛点打了一剂强心针。它让组件能够感知生命周期状态的变化，并且自动做出响应。今天我们就把它扒个底朝天。

Lifecycle 的核心思想

Lifecycle 不是一个复杂的东西。它的核心就两个角色：

  • LifecycleOwner：拥有生命周期的一方，比如 Activity、Fragment。
  • LifecycleObserver：观察生命周期的一方，比如你的自定义组件。

它们之间通过 Lifecycle 对象来通信。LifecycleOwner 持有 Lifecycle 对象，LifecycleObserver 注册到这个对象上。当生命周期事件发生时，Lifecycle 会通知所有注册的 Observer。

我刚开始接触这个设计时，觉得它有点像观察者模式的变体。但用久了你会发现，它比普通的观察者模式更聪明——它解决了生命周期回调顺序不一致的问题。

LifecycleOwner 原理

我们先看看 LifecycleOwner 的接口定义：

public interface LifecycleOwner {
    @NonNull
    Lifecycle getLifecycle();
}

就这么简单？对，就一个方法。但背后的实现可不简单。

在 AndroidX 的 ComponentActivity 中，LifecycleOwner 的实现是通过一个叫 ReportFragment 的内部类来完成的。这个 Fragment 没有 UI，它唯一的作用就是感知 Activity 的生命周期回调，然后转发给 Lifecycle 对象。

为什么不用 Activity 本身的回调？嗯，这里有个历史原因。在 Support Library 时代，Activity 的生命周期回调是硬编码的，没法插桩。用个空 Fragment 来监听，反而更灵活。我记得当时看到这个设计时，心里想：这招真妙。

具体流程是这样的：

  1. Activity 的 onCreate 方法里，会创建一个 ReportFragment 并添加到 FragmentManager。
  2. ReportFragment 的 onStart、onResume、onPause、onStop、onDestroy 方法被调用时，会调用 LifecycleRegistry.handleLifecycleEvent()。
  3. LifecycleRegistry 内部维护了一个状态机，它会根据事件更新当前状态，并通知所有 Observer。

LifecycleObserver 原理

LifecycleObserver 是一个空接口：

public interface LifecycleObserver {}

真正的魔法在注解和 DefaultLifecycleObserver 上。在 Java 8 之前，我们用的是 @OnLifecycleEvent 注解：

public class MyObserver implements LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    public void onResume() {
        // 在 onResume 时执行
    }
}

但这种方式有个问题——它依赖反射。每次生命周期事件发生时，都要通过反射找到对应的方法并调用。性能上有点损耗。

所以后来 Google 推荐使用 DefaultLifecycleObserver：

public class MyObserver implements DefaultLifecycleObserver {
    @Override
    public void onResume(@NonNull LifecycleOwner owner) {
        // 在 onResume 时执行
    }
}

这种方式没有反射，直接通过接口回调。我个人习惯在新项目里都用 DefaultLifecycleObserver，除非要兼容 Java 7 的老项目。

如何自定义 LifecycleOwner

有时候，你需要在自定义的 View 或者 Service 里也拥有生命周期感知能力。这时候就需要自己实现 LifecycleOwner 了。

实现起来其实不复杂，核心就是使用 LifecycleRegistry：

public class MyLifecycleOwner implements LifecycleOwner {
    private final LifecycleRegistry lifecycleRegistry = new LifecycleRegistry(this);

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

    // 在合适的时机手动触发生命周期事件
    public void start() {
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
    }

    public void stop() {
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
    }

    public void destroy() {
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);
    }
}

这里有个坑要注意：LifecycleRegistry 的 handleLifecycleEvent 方法必须在主线程调用。我曾经在子线程里调过，结果直接崩溃了。嗯，这个错误我犯过一次就再也没忘过。

另外，如果你想让自定义的 LifecycleOwner 支持多线程，可以考虑用 LifecycleRegistry 的线程安全版本——不过说实话，我还没遇到过这种需求。生命周期事件本身就应该在主线程处理。

项目中的最佳实践

理论说完了，我们来聊聊实战。我在几个项目里总结了一些经验，分享给你：

1. 用 Lifecycle 管理网络请求

最常见的场景就是网络请求的生命周期绑定。比如用 Retrofit + LiveData：

public class MyViewModel extends ViewModel {
    private final MutableLiveData<User> userLiveData = new MutableLiveData<>();

    public LiveData<User> getUser() {
        return userLiveData;
    }

    public void loadUser(String userId) {
        // 发起网络请求
        apiService.getUser(userId).enqueue(new Callback<User>() {
            @Override
            public void onResponse(Call<User> call, Response<User> response) {
                userLiveData.setValue(response.body());
            }

            @Override
            public void onFailure(Call<User> call, Throwable t) {
                // 处理错误
            }
        });
    }
}

这样当 Activity 销毁时，LiveData 会自动清理，不会出现内存泄漏。但如果你不用 LiveData，而是用普通的回调，那就得手动处理了。

2. 自定义 View 的生命周期感知

有时候自定义 View 需要监听生命周期。比如一个视频播放器 View，需要在 onResume 时继续播放，onPause 时暂停。

我建议的做法是让自定义 View 实现 LifecycleObserver：

public class VideoPlayerView extends FrameLayout implements DefaultLifecycleObserver {
    public VideoPlayerView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    public void onResume(@NonNull LifecycleOwner owner) {
        // 继续播放
        if (isPlaying()) {
            resume();
        }
    }

    @Override
    public void onPause(@NonNull LifecycleOwner owner) {
        // 暂停播放
        if (isPlaying()) {
            pause();
        }
    }

    @Override
    public void onDestroy(@NonNull LifecycleOwner owner) {
        // 释放资源
        release();
    }
}

然后在 Activity 里注册：

getLifecycle().addObserver(videoPlayerView);

这样 View 就能自动感知生命周期了，不需要在 Activity 里写一堆回调代码。

3. 避免在 onDestroy 里做耗时操作

这个其实是个常识，但我在 code review 时经常看到有人犯。onDestroy 里不要做网络请求、数据库写入等耗时操作。因为系统可能随时杀掉进程，你的操作可能还没完成就被中断了。

如果你确实需要在 Activity 销毁前保存一些数据，可以考虑用 onStop 而不是 onDestroy。onStop 的调用时机更早，而且系统会保证它被调用（除非进程被强杀）。

4. 使用 Lifecycle 的当前状态做判断

有时候你需要在代码里判断当前是否处于活跃状态。比如弹 Toast 之前，先检查 Activity 是否还在前台：

if (lifecycle.getCurrentState().isAtLeast(Lifecycle.State.STARTED)) {
    // 可以安全地更新 UI
    showToast("操作成功");
}

这个判断比用自定义的 boolean 变量靠谱多了。因为 Lifecycle 的状态是系统维护的，不会出现状态不同步的问题。

避坑指南

最后，我把自己踩过的坑整理一下：

  • 不要重复注册 Observer：同一个 Observer 多次注册会导致多次回调。我建议在 onCreate 里统一注册，不要分散在各处。
  • 注意 Observer 的生命周期：如果 Observer 是一个内部类，它可能持有外部类的引用，导致内存泄漏。建议用静态内部类或者单独的文件。
  • 不要依赖回调顺序：多个 Observer 之间的回调顺序是不确定的。如果你有依赖关系，最好在一个 Observer 里处理。
  • 自定义 LifecycleOwner 时注意线程：handleLifecycleEvent 必须在主线程调用，否则会抛异常。

我曾经在一个项目里，因为自定义 LifecycleOwner 的线程问题，排查了整整两天。最后发现是一个异步任务在子线程里调了 handleLifecycleEvent。从那以后，我每次写自定义 LifecycleOwner 都会加个 Handler 检查。

总结

Lifecycle 这个组件，看似简单，但它的设计思想影响了整个 Jetpack 家族。理解了它，你就能更好地理解 LiveData、ViewModel、Room 这些组件是如何协同工作的。

说白了，Lifecycle 就是 Android 生命周期管理的标准化方案。它让组件不再需要手动管理生命周期，而是让系统来帮你做这件事。你只需要关注业务逻辑，剩下的交给 Lifecycle。

下一章我们会聊 LiveData 的原理和最佳实践。到时候你会发现，LiveData 和 Lifecycle 配合起来，简直是天作之合。

← 上一章 📖 返回目录 下一章 →