Jetpack 生命周期组件 Lifecycle 的设计思想和使用

李斯维2026-05-19 10:33

早在 2017 年的时候，Google 就推出了一系列架构组件，称为 Architecture Components，并于 2018 年在 Google I/O 大会上提出 Jetpack，且将 Architecture Components 纳入其中，时至今日，越来越多的组件如 Room、Paging3 也被纳入其中。

Jetpack 主要分为基础、架构组件、行为、页面这四个模块：

关于 Android Jetpack 的更多信息，可以看这篇内容：Android Jetpack 简介：由来和演进 - 掘金

在开发模式中，最为重要的就是架构组件部分，用好架构组件可以帮助我们写出更加优雅的代码。 本文将讲解 Jetpack 的第一个组件 ------ Lifecycle。

Lifecycle 是 Jetpack 中最为重要的库，也是整个 Jetpack 的基石 ------ ViewModel、LiveData、Room、Paging，几乎所有 Jetpack 组件都直接或间接依赖 LifecycleOwner。它的核心价值是把 Activity / Fragment 那套回调式的生命周期（onCreate→onStart→onResume→...→onDestroy）变成了可观察的状态机，让组件能自行感知、自行响应，而不是在每个回调里手动处理。

本文将从实际项目需求触发，演示如何使用 Lifecycle 感知生命周期的功能，并分离业务代码。

从计时器的需求说起

我们先假定一个计时器的需求：在页面中显示一个 TextView, 其内容是不断更新的秒数。

为了实现此需求，我们写了如下的一个秒级计时器：

kotlin 复制代码 
package com.example.evolution

import android.os.Handler
import android.os.Looper

/**
 * 计时器，计时精度为秒
 */
class SecondLevelTimer {

    enum class State {
        IDLE,
        TIMING,
        PAUSED
    }

    private var currentTime = 0L
    private var currentState = State.IDLE
    private lateinit var handler: Handler
    private lateinit var runnable: Runnable
    private lateinit var listenerList: MutableList<OnTimeListener>

    fun initialize() {
        handler = Handler(Looper.getMainLooper())
        runnable = object : Runnable {
            override fun run() {
                if (currentState == State.TIMING) {
                    currentTime++
                    listenerList.forEach { it.onTick(currentTime) }
                    handler.postDelayed(this, 1000)
                }
            }
        }
        listenerList = mutableListOf()
    }

    fun start() {
        currentTime = 0
        currentState = State.TIMING
        handler.postDelayed(runnable, 1000)
    }

    fun stop() {
        currentState = State.IDLE
    }

    fun pause() {
        if (currentState == State.TIMING)
            currentState = State.PAUSED
    }

    fun resume() {
        if (currentState == State.PAUSED) {
            currentState = State.TIMING
            handler.postDelayed(runnable, 1000)
        }
    }

    fun destroy() {
        listenerList.clear()
        handler.removeCallbacksAndMessages(null)
    }

    fun addOnTimeListener(listener: OnTimeListener) {
        listenerList.add(listener)
    }

    fun removeOnTimeListener(listener: OnTimeListener) {
        listenerList.remove(listener)
    }

    interface OnTimeListener {
        fun onTick(second: Long)
    }
}

注意这个秒级计时器为了演示没有 Lifecycle 时带来的影响，添加了 initialize 和 destroy 方法，其实这两个方法是没有必要的，但是为了表示一个具有生命周期的类，添加了这两个方法。

在实际工作中，各位最好将这个计时器对象想象为各种需要进行注册或销毁，监听或移除监听的 Manager，这样你更能带入到实际的工作情况，在 Android 中这样情况非常常见，例如需要在 Activity 中对某个广播进行注册监听和反注册等。

下面我们先不使用 Lifecycle 来实现这个功能。

不使用 Lifecycle 的实现方式

在早期的 Android 开发中，我们肯定会使用如下方式来使用这个计时器。

kotlin 复制代码 
class MainActivity : Activity() {

    private val timer: SecondLevelTimer = SecondLevelTimer()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val textView = findViewById<TextView>(R.id.text_view)

        timer.initialize()
        timer.addOnTimeListener(object: SecondLevelTimer.OnTimeListener{
            override fun onTick(second: Long) {
                textView.setText("当前时间：$second 秒")
            }
        })
    }

    override fun onStart() {
        super.onStart()
        timer.start()
    }

    override fun onResume() {
        super.onResume()
        timer.resume()
    }

    override fun onPause() {
        super.onPause()
        timer.pause()
    }

    override fun onStop() {
        super.onStop()
        timer.stop()
    }

    override fun onDestroy() {
        super.onDestroy()
        timer.destroy()
    }
}

结果代码运行正常，代码也看似完美，这样就实现了计时器的需求。

不过这种实现方式肯定是不够优雅的，因为开发者需要在 Activity 对应声明周期的方法中主动执行相关的方法。当与生命周期相关联的方法越来越多时，业务的改动就会导致 Activity 层的处理逻辑难以维护。

那么我们先来探讨一下这种不使用 Lifecycle 会出现的问题。

问题一：生命周期逻辑耦合在 Activity / Fragment 里，导致它们膨胀

通过上面代码可以看到，所有跟生命周期相关的逻辑都堆在 Activity 的回调里，而这只是添加了一个计时器，如果有多个类似这样的对象，那么每加一个组件，就得在 onStart、onStop、onDestroy 里各加一行。就像下面这样：

kotlin 复制代码 
class MainActivity : Activity() {
 private lateinit var locationManager: LocationManager
 private lateinit var sensorManager: SensorManager
 private lateinit var videoPlayer: VideoPlayer

 override fun onStart() {
   super.onStart()
   locationManager.start() // 位置监听
   sensorManager.register() // 传感器
   videoPlayer.play() // 播放器
 }

 override fun onStop() {
   super.onStop()
   locationManager.stop()
   sensorManager.unregister()
   videoPlayer.pause()
 }

 override fun onDestroy() {
   super.onDestroy()
   videoPlayer.release()
   // 每加一个组件就得多写几行
 }
}

这会导致 Activity 跟具体业务完全耦合，代码繁琐不说，更重要的是 Activity 被设计其实是用来处理界面的，而非管理其他组件的生命周期。

问题二：在错误的生命周期状态执行操作会导致崩溃或内存泄漏

这个问题最典型的场景就是：网络请求回来时 Activity 已经在后台或者销毁了。例如下面的这个方法，如果在服务器返回时被调用，而此时用户已经退出了这个页面，那么就会造成内存泄漏或崩溃：

kotlin 复制代码 
fun onNetworkResponse(data: String) {
     textView.text = data             // 如果此时 Activity 已经销毁，有内存泄漏和崩溃的风险
}

既然看到了有两个问题，那么我们就看看 Lifecycle 是如何解决这些问题的。那第一步自然就是将 Lifecycle 引入到项目中了。

引入 Lifecycle 库

由于现在的 Android Studio 都已经使用 toml 进行依赖配置了，这里就给出 toml 的引入方式：

gradle/libs.versions.toml 文件中添加如下依赖：

ini 复制代码 
[versions]
lifecycle = "2.10.0"

[libraries]
lifecycle-runtime = { group = "androidx.lifecycle", name = "lifecycle-runtime", version.ref = "lifecycle" }

注意，这是 Lifecycle 的最小依赖，只包含 Lifecycle 核心类型（Lifecycle、LifecycleOwner、LifecycleObserver）。我们将从这里开始讲，后续讲会引入其他依赖。

然后，在模块级的 build.gradle.kts 中添加如下配置：

groovy 复制代码 
dependencies {
 implementation(libs.lifecycle.runtime)
}

在 sync 之后，你会发现项目中添加如如下的依赖库：

接下来我们就看如何使用 Lifecycle 实现这个计时器的功能。

Lifecycle 基础

lifecycle-runtime 这个库中，有三个重要的东西：

  • Lifecycle（状态机）
  • LifecycleObserver（观察者）：对应会被 Activity 这种具有生命周期的对象使用的，且需要响应生命周期的类。
  • LifecycleOwner（持有者）：对应具有生命周期的类，典型的如 Activity、Fragment，你也可以自己定义一个具有生命周期的类。

对于这三个，我们来一一说明。

状态机 Lifecycle

准确的说，这里说的这个 Lifecycle 文件来自于 androidx.lifecycle:lifecycle-common-jvm 库中的 androidx.lifecycle.Lifecycle。

它定义了两个重要的方法，以及与生命周期有关的事件和状态：

  • 两个方法：addObserver(observer: LifecycleObserver) 和 removeObserver(observer: LifecycleObserver)
  • 生命周期事件 Event：ON_CREATE、ON_START、ON_RESUME、ON_PAUSE、ON_STOP、ON_DESTROY、ON_ANY
  • 生命周期状态 State：INITIALIZED、CREATED、STARTED、RESUMED、DESTROYED 甚至我们可以将这个文件简化成如下的形式：
kotlin 复制代码 
package androidx.lifecycle

public abstract class Lifecycle {
    
    @MainThread public abstract fun addObserver(observer: LifecycleObserver)
    @MainThread public abstract fun removeObserver(observer: LifecycleObserver)
    
    public enum class Event {
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY;
    }

    public enum class State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;    
    }
}

这里说的事件和状态，就是 Activity 的生命周期方法和状态，其状态转换图如下，熟悉 Activity 生命周期的对此图应该非常熟悉：

生命周期持有者：LifecycleOwner

LifecycleOwner 来自于 androidx.lifecycle:lifecycle-common-jvm 库中，全类名为 androidx.lifecycle.LifecycleOwner。它所代表的，是一个具有生命周期的类。而上面说到，生命周期状态机是由 Lifecycle 表示的，因此 LifecycleOwner 这个接口的内容很简单，就是包含了一个 Lifecycle 实例。

kotlin 复制代码 
public interface LifecycleOwner {
    public val lifecycle: Lifecycle
}

最典型的 LifecycleOwner 就是 Activity 和 Fragment 了，从 Lifecycle 的状态和事件就可以看出，这个 Lifecycle 的设计就是针对 Activity 的，而 Fragment 的生命周期更加复杂，但从实际使用情况考虑，也被收敛到了与 Activity 相同的生命周期。

在本文的后面，你将会依赖 android.activity:activity-ktx 这个依赖库，其中就提供了 ComponentActivity：一个已经实现了 LifecycleOwner 的 Activity。

生命周期观察者：LifecycleObserver

Lifecycle 这个库本质上是基于观察者模式，前面已经说了生命周期状态机，和生命周期持有者，那现在就差生命周期观察者了，而这个观察者，就是 LifecycleObserver。在实际工作中，这个观察者就是对应那些需要在 Activity 中需要跟随生命周期方法产生变动的对象。除了本文的需求的这个计时器，还有各种 Manager、监听器等等，它们都需要在 onCreate 中初始化，并在 onDestroy 中销毁以释放资源。

LifecycleObserver 是一个标记接口，它来自于 androidx.lifecycle:lifecycle-common-jvm 依赖库，全类名为 androidx.lifecycle.LifecycleObserver。作为标记接口，它是没有任何内容的：

kotlin 复制代码 
public interface LifecycleObserver

我们不应该直接使用这个接口，而是使用 DefaultLifecycleObserver 或 LifecycleEventObserver。

DefaultLifecycleObserver

它来自于 androidx.lifecycle:lifecycle-common-jvm 依赖库，全类名为 androidx.lifecycle.DefaultLifecycleObserver。它其实就是把 Activity 的6个生命周期方法拿了过来，但都是空方法，使用时，只需要实现需要的方法即可。其内容为：

kotlin 复制代码 
public interface DefaultLifecycleObserver : LifecycleObserver {
    public fun onCreate(owner: LifecycleOwner) {}
    public fun onStart(owner: LifecycleOwner) {}
    public fun onResume(owner: LifecycleOwner) {}
    public fun onPause(owner: LifecycleOwner) {}
    public fun onStop(owner: LifecycleOwner) {}
    public fun onDestroy(owner: LifecycleOwner) {}
}

LifecycleEventObserver

它同样来自于 androidx.lifecycle:lifecycle-common-jvm 依赖库，全类名为 androidx.lifecycle.LifecycleEventObserver。相比于 DefaultLifecycleObserver，它更为简单，其内部仅仅提供了一个方法，此方法将在状态发证改变时调用：

kotlin 复制代码 
public fun interface LifecycleEventObserver : LifecycleObserver {
    public fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event)
}

另外，这里有一点需要注意，一个类是可以同时实现多个接口的。但一个类同时实现了 DefaultLifecycleObserver 和 LifecycleEventObserver。那么当这个 LifecyleOwner 的状态发生变化时，这两个接口的方法都会回调，且 DefaultLifecycleObserver 的方法在前，LifecycleEventObserver 的方法在后。

使用 Lifecycle 的实现方式

有了前面的基础内容铺垫，现在我们就要使用 Lifecycle 来完整我们的计时器需求了。

我们现在使用的 Activity 是 android.app.Activity，它是由 Android Framework 提供的最原始的平台相关的 Activity。我们的计时器要跟随这个 Activity 的生命周期发生变动，那就是意味着，Activity 是生命周期持有者，而计时器则是观察者。因此，我们要改造的第一步就是：将 Activity 改造为 LifecycleOwner。

将 Activity 改造为 LifecycleOwner

前面说了，LifecycleOwner 只是要求实现方提供一个类型为 Lifecycle 的成员变量，那么 Activity 可以先这么写：

kotlin 复制代码 
class MainActivity : Activity(), LifecycleOwner {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        //......
    }

    private val myLifecycleImpl = MyLifecycleImpl(this)
    override val lifecycle: Lifecycle
        get() = myLifecycleImpl
}

这里我们提供了一个 Lifecycle 类型的成员变量，为了提供这个 Lifecycle，我们就需要写一个这样的 Lifecycle 的实现，这里就是 MyLifecycleImpl 了。

实现 Lifecycle，写一个自己的 LifecycleRegistry

实现这个 Lifecycle 挺麻烦的，我这里写了一个简单的 MyLifecycleImpl，如下。后续，我们会替换这个类，并使用官方提供的 LifecycleRegistry。

kotlin 复制代码 
class MyLifecycleImpl(lifecycleOwner: LifecycleOwner) : Lifecycle() {

    private var innerCurrentState = State.INITIALIZED
    override val currentState: State
        get() = innerCurrentState

    private val lifecycleOwnerWrapper = WeakReference(lifecycleOwner)

    private val observerList = mutableListOf<LifecycleObserver>()

    override fun addObserver(observer: LifecycleObserver) {
        observerList.add(observer)

        // 将这个新加入的 Observer 追赶到当前状态
        val owner = lifecycleOwnerWrapper.get() ?: return
        if (observer is DefaultLifecycleObserver) {
            when (innerCurrentState) {
                State.CREATED -> {
                    observer.onCreate(owner)
                }
                State.STARTED -> {
                    observer.onCreate(owner)
                    observer.onStart(owner)
                }
                State.RESUMED -> {
                    observer.onCreate(owner)
                    observer.onStart(owner)
                    observer.onResume(owner)
                }
                State.DESTROYED -> {
                    observer.onCreate(owner)
                    observer.onDestroy(owner)
                }
                else -> {
                    // do nothing
                }
            }
        }
        if(observer is LifecycleEventObserver) {
            when (innerCurrentState) {
                State.CREATED -> {
                    observer.onStateChanged(owner, Event.ON_CREATE)
                }
                State.STARTED -> {
                    observer.onStateChanged(owner, Event.ON_CREATE)
                    observer.onStateChanged(owner, Event.ON_START)
                }
                State.RESUMED -> {
                    observer.onStateChanged(owner, Event.ON_CREATE)
                    observer.onStateChanged(owner, Event.ON_START)
                    observer.onStateChanged(owner, Event.ON_RESUME)
                }
                State.DESTROYED -> {
                    observer.onStateChanged(owner, Event.ON_CREATE)
                    observer.onStateChanged(owner, Event.ON_DESTROY)
                }
                else -> {
                    // do nothing
                }
            }
        }
    }

    override fun removeObserver(observer: LifecycleObserver) {
        observerList.remove(observer)
    }

    fun handleLifecycleEvent(event: Event) {
        val lifecycleOwner = lifecycleOwnerWrapper.get() ?: return
        when (event) {
            Event.ON_CREATE -> {
                innerCurrentState = State.CREATED
                observerList.forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onCreate(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_CREATE)
                }
            }
            Event.ON_START -> {
                innerCurrentState = State.STARTED
                observerList.forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onStart(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_START)
                }
            }
            Event.ON_RESUME -> {
                innerCurrentState = State.RESUMED
                observerList.forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onResume(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_RESUME)
                }
            }
            Event.ON_PAUSE -> {
                innerCurrentState = State.STARTED
                observerList.reversed().forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onPause(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_PAUSE)
                }
            }
            Event.ON_STOP -> {
                innerCurrentState = State.CREATED
                observerList.reversed().forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onStop(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_STOP)
                }
            }
            Event.ON_DESTROY -> {
                innerCurrentState = State.DESTROYED
                observerList.reversed().forEach {
                    if (it is DefaultLifecycleObserver)
                        it.onDestroy(lifecycleOwner)
                    if (it is LifecycleEventObserver)
                        it.onStateChanged(lifecycleOwner, Event.ON_DESTROY)
                }
            }
            Event.ON_ANY -> {
                // do nothing
            }
        }
    }
}

在这里得说一下这个 Lifecycle 实现类所做的事情，基本可以概括为以下几点：

  • 管理当前状态，处理状态转换，即 currentState。这个需要 LifecycleOwner 在相关方法中调用；
  • 管理观察者的增删；
  • 在对应事件到来的时候，通知观察者；
  • 将新观察者追赶到当前状态；

不仅我们这个 Lifecyle 实现是这样的，官方的 LifecycleRegistry 也是做这几件事情。只不过我们自定义的这个 Lifecycle 实现简单，不过也算是达到了好歹能用的地步，在这里演示 Lifecycle 的用法已经足够了。 既然能用，那我们就将这个 MyLifecycleImpl 用到 MainActivity 中，以使这个 Activity 成为一个真正的 LifecycleOwner，使用也很简单，就是在对应的生命周期方法中调用对应的事件，仅此而已：

kotlin 复制代码 
class MainActivity : Activity(), LifecycleOwner {
    private val myLifecycleImpl = MyLifecycleImpl(this)

    override val lifecycle: Lifecycle
        get() = myLifecycleImpl

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        myLifecycleImpl.handleLifecycleEvent(Event.ON_CREATE)
    }

    override fun onStart() {
        super.onStart()
        myLifecycleImpl.handleLifecycleEvent(Event.ON_START)
    }
    
    override fun onResume() {
        super.onResume()
        myLifecycleImpl.handleLifecycleEvent(Event.ON_RESUME)
    }

    override fun onPause() {
        super.onPause()
        myLifecycleImpl.handleLifecycleEvent(Event.ON_PAUSE)
    }

    override fun onStop() {
        super.onStop()
        myLifecycleImpl.handleLifecycleEvent(Event.ON_STOP)
    }

    override fun onDestroy() {
        super.onDestroy()
        myLifecycleImpl.handleLifecycleEvent(Event.ON_DESTROY)
    }
}

这样，我们的 LifecycleOwner 就准备好了，现在需要的是，改造计时器，将其变成一个生命周期观察者，这样才能构建一个完整的观察者模式。而改造计时器则简单得多，毕竟使用 Lifecycle，就是要将各种类改造为生命周期观察者，太麻烦的话，这个库也没人用。

改造计时器为 LifecycleObserver

将一个类改造成为 LifecycleObserver 有两种方式：实现 DefaultLifecycleObserver 或 LifecycleEventObserver，甚至你可以直接实现这两个接口。如果实现两个接口，那么这两个接口中的方法都会被调用，这其实并不是我们想要的。

这里我选择实现 LifecycleEventObserver 接口，因为如果要实现 DefaultLifecycleObserver，那要实现的方法就太多了。

改造计时器只需要在 SecondLevelTimer 中添加如下代码：

kotlin 复制代码 
class SecondLevelTimer(): LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        when(event) {
            Lifecycle.Event.ON_CREATE -> initialize()
            Lifecycle.Event.ON_START -> start()
            Lifecycle.Event.ON_RESUME -> resume()
            Lifecycle.Event.ON_PAUSE -> pause()
            Lifecycle.Event.ON_STOP -> stop()
            Lifecycle.Event.ON_DESTROY -> destroy()
            Lifecycle.Event.ON_ANY -> {}
        }
    }
    
    // 其他代码保持不变
}

在 LifecycleOwner 中添加观察者

现在各个部分都已经完成了，最后一步就是在 Activity 中添加这个观察者了：

kotlin 复制代码 
class MainActivity : Activity(), LifecycleOwner {

    private val timer: SecondLevelTimer = SecondLevelTimer()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val textView = findViewById<TextView>(R.id.text_view)

        myLifecycleImpl.handleLifecycleEvent(Event.ON_CREATE)
        
        myLifecycleImpl.addObserver(timer)        // 添加观察者
        timer.addOnTimeListener(object : SecondLevelTimer.OnTimeListener {
            override fun onTick(second: Long) {
                textView.text = "当前时间 $second"
            }
        })
    }
    
    // 其他代码保持不变
 }

这样，我们的计时器就能够跟随 Activity 的生命周期而改变自身状态，这个计时器的需求也完成得很完美。

这也是 Lifecycle 这个库要实现目标：生命周期解耦，组件自己响应生命周期，Activity 只负责注册观察者，不再关心具体逻辑。

使用官方组件的最佳实践

前面我们的实现方式用了太多的自定义实现，现在，我们要使用官方的组件来替换自己自定义的类，用官方推荐的最佳实践来完成这个需求。

通过前面我们自定义的代码就能看到，自己实现一个 LifecycleOwner 实在是太麻烦了，主要是要实现一个 Lifecycle 的对象。其实这里 Google 提供了 Lifecycle 的实现类，那就是 LifecycleRegistry。

LifecycleRegistry

这个类来自于 androidx.lifecycle:lifecycle-runtime-android 这个依赖库，注意这里就与前面的 Lifecycle、LifecycleOwner、LifecycleObserver 是不同的依赖库，其全类名为：androidx.lifecycle.LifecycleRegistry。

这里我不讨论其内部实现方式，不过其本质上也与我们自己写的 MyLifecycleImpl 类似，我们将目光放到这个类的使用上。使用这个类也简单，在前面我们的 Activity 中，只需要将 MyLifecycleImpl 换成这个类就可以了。

以下是 Activity 使用 LifecycleRegistry 的代码：

kotlin 复制代码 
class MainActivity : Activity(), LifecycleOwner {

    private val lifecycleRegistry = LifecycleRegistry(this)

    override val lifecycle: Lifecycle
        get() = lifecycleRegistry

    private val timer: SecondLevelTimer = SecondLevelTimer()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val textView = findViewById<TextView>(R.id.text_view)

        lifecycleRegistry.handleLifecycleEvent(Event.ON_CREATE)
        lifecycleRegistry.addObserver(timer)
        timer.addOnTimeListener(object : SecondLevelTimer.OnTimeListener {
            override fun onTick(second: Long) {
                textView.text = "当前时间 $second"
            }
        })
    }

    override fun onStart() {
        super.onStart()
        lifecycleRegistry.handleLifecycleEvent(Event.ON_START)
    }

    override fun onResume() {
        super.onResume()
        lifecycleRegistry.handleLifecycleEvent(Event.ON_RESUME)
    }

    override fun onPause() {
        super.onPause()
        lifecycleRegistry.handleLifecycleEvent(Event.ON_PAUSE)
    }

    override fun onStop() {
        super.onStop()
        lifecycleRegistry.handleLifecycleEvent(Event.ON_STOP)
    }

    override fun onDestroy() {
        super.onDestroy()
        lifecycleRegistry.handleLifecycleEvent(Event.ON_DESTROY)
    }
}

可以看到除了将 MyLifecycleImpl 换成 LifecycleRegistry 之外，没有任何区别。 有了这个 LifecycleRegistry，我们就不需要自己写 Lifecycle 的实现类了。

ComponentActivity

但光有这个 LifecycleRegistry 还不够，大家也应该发现了，其实上面的 MainActivity 中，也存在大量的样板代码，特别是每个生命周期方法中都要添加的状态转换函数。Google 也发现了这个问题，并推出了 ComponentActivity。

引入 activity-ktx 依赖

这个 ComponentActivity 在不同的依赖库中，因此我们先将其引入进来：

ini 复制代码 
# libs.versions.toml
activityKtx = "1.13.0"

[libraries]
activity-ktx = { group = "androidx.activity", name = "activity-ktx", version.ref = "activityKtx" }

在模块级的 build.gradle 中添加依赖：

groovy 复制代码 
dependencies {
    implementation(libs.activity.ktx)
}

由于这个 androidx.activity:activity-ktx 依赖库其内部是依赖了 Lifecycle 的，因此添加了这个以后，前面添加的 lifecycle-runtime 依赖就可以删除了。

使用方式

使用 ComponentActivity 非常简单，我们将进一步简化 MainActivity：

kotlin 复制代码 
class MainComponentActivity(): ComponentActivity() {
    private val timer: SecondLevelTimer = SecondLevelTimer()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val textView = findViewById<TextView>(R.id.text_view)

        lifecycle.addObserver(timer)
        timer.addOnTimeListener(object : SecondLevelTimer.OnTimeListener {
            override fun onTick(second: Long) {
                textView.text = "当前时间 $second"
            }
        })
    }
}

好了，以上就是全部代码，是不是很简单。LifecycleRegistry 都已经在内部封装好了，可以直接使用，也不用再添加切换状态的代码了。是不是很简单。

总结

先对文章内容做一下总结：

为了演示 Lifecycle 这个库的使用，我们自己创建了一个计时器的需求，并在不是 Lifecycle 库的情况下完成了这个需求。通过这种写法我就能体会到传统写法的弊端，进而引入 Lifecycle 库，通过对其进行引入，讲解其基础知识（Lifecycle、LifecycleOwner、LifecycleObserver），我们以最小的依赖方式完成了这个需求，这里最麻烦的就是自定义 Lifecyle 的实现了。在使用 Lifecycle 依赖库完成了这个需求之后，我们引入了更大的依赖库，并使用了 LifecycleRegistry 和 ComponentActivity，形成最终的，最优雅的实现方式。

通过这篇文章，诸位应该能够对 Lifecycle 有一个初步的认识，并知道如何在实际工作中使用它了。

Lifecycle 虽然能够解决生命周期感知问题，但是它并不能解决 业务边界混乱、状态管理复杂等的问题，Lifecycle 更多的是 Android 生命周期的统一抽象层。

在后续，我们将继续探讨 Jetpack 的其他库是如何解决这些问题的。

相关推荐
成都大菠萝1 天前
Android Car CarProperty 车辆信号链路
android
敲代码的鱼1 天前
PDF 预览与签名批注写回 支持安卓 iOS 鸿蒙 UTS插件
android·前端·ios
时光足迹1 天前
uni-app 视频通话实战：康复师与患者视频问诊的 6 个致命 Bug 与解决方案
android·ios·uni-app
Coffeeee1 天前
闲聊几句，Android老哥们，你们多久没做技改需求了
android·程序员·代码规范
萝卜er1 天前
Fragment 生命周期与状态恢复-《Android深水区（四）》
android
萝卜er1 天前
Intent 显式、隐式与 PendingIntent-《Android深水区（五）》
android
Kapaseker1 天前
一文吃透 Kotlin 集合操作符
android·kotlin
三少爷的鞋1 天前
Main-safe：现代Android 架构真正的分水岭
android
沐怡旸2 天前
深入解析 Android Performance Analyzer (APA) 底层架构与技术原理
android
李斯维2 天前
从历史的角度看 Android 软件架构
android·架构·android jetpack
热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04Trae国际版与国内版深度测评：AI原生IDE的双生花05【AI】2026 年具身智能模型和世界模型总结06Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析07飞书长连接_事件订阅（接收消息，审批任务状态变更）08GitHub 镜像站点092026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？102026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）