引言

上一篇我们学习了LifeCycle的简单使用Android jetpack LifeCycle（一）使用篇，那在这一篇主要学习LifeCycle的原理。源码基于androidx.lifecycle:lifecycle-runtime:2.8.3

优势

Lifecycle 是 Android Jetpack 的生命周期感知型组件，通过观察者模式将 Activity/Fragment 的生命周期事件解耦到独立组件中，解决传统开发中手动管理生命周期的痛点：

​解耦性：业务逻辑（如 Presenter、ViewModel）无需直接依赖 Activity/Fragment，通过观察者接收生命周期事件。
​内存安全​：自动解除注册，避免因未及时注销导致的内存泄漏。
​状态一致性​：确保观察者状态与宿主同步，避免无效操作（如在后台更新 UI）。

原理分析前置

原理分析之前，先看下最重要的几个类和状态

三大核心概念

概念接口	描述	实现类
LifeCycleOwner	声明拥有生命周期的组件	Activity、Fragment、Service（自定义）
LifeCycle	抽象生命周期状态和事件，由 LifecycleRegistry 实现具体管理逻辑	LifecycleRegistry
LifecycleObserver	观察生命周期事件的组件	ViewModel、LiveData、自定义业务类

五大状态

1、LifecycleOwner

public interface LifecycleOwner {
    /**
     * @return The lifecycle of the provider.
     */
    public val lifecycle: Lifecycle
}

public val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
    get() = lifecycle.coroutineScope
}

生命周期持有者，返回一个Lifecycle对象，如果你使用的是 AndroidX（也属于 Jetpack 一部分）在这Activity 、Fragment 两个类中，默认实现了 LifecycleOwner 接口

看下 Lifecycle 类是什么

2、Lifecycle

在Lifecycle类中定义了添加观察者和移除观察者的方法，并定义了两个枚举类
LifecycleRegistry类是对Lifecycle这个抽象类的具体实现，可以处理多个观察者，如果你自定义 LifecycleOwner可以直接使用它。

public abstract class Lifecycle {
    @MainThread public abstract fun addObserver(observer: LifecycleObserver)
    @MainThread public abstract fun removeObserver(observer: LifecycleObserver)
    @get:MainThread public abstract val currentState: State

	 public enum class Event {
	 //五种状态事件
	 }
	 
    public enum class  State {
       
    }

	public inline fun Lifecycle.addObserver(
    	crossinline action: LifecycleObserver.(source: LifecycleOwner, event: Lifecycle.Event) -> Unit
	): LifecycleObserver {
    	val observer = object : LifecycleEventObserver {
            override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
                action(this, source, event)
            }
        }
    	addObserver(observer)
    	return observer
	}
}

3、LifecycleObserver

啥也没有，一个单纯的接口类。不要直接使用此接口，而应实现 [DefaultLifecycleObserver] 或 [LifecycleEventObserver] 以接收生命周期事件的通知。

public interface LifecycleObserver

前置总结

LifecycleOwner：可获取Lifecycle的接口，可以再 Activity、Fragment生命周期改变时，通过LifecycleRegistry类处理对应的生命周期事件，并通知 LifecycleObserver这个观察者
Lifecycle：是被观察者，用于存储有关组件（如 Activity 或 Fragment）的生命周期状态的信息，并允许其他对象观察此状态。
LifecycleObserver：观察者，可以通过被LifecycleRegistry类通过 addObserver(LifecycleObserver o)方法注册,被注册后，LifecycleObserver便可以观察到LifecycleOwner对应的生命周期事件
Lifecycle.Event：分派的生命周期事件。这些事件映射到 Activity 和 Fragment 中的回调事件。
Lifecycle.State：Lifecycle组件的当前状态。

了解上面的基本内容，就进行具体的源码分析，通过看源码，就能知道整个流程了。

原理

当你写了一个自定义activity继承自ComponentActivity时，可以使用Lifecycle观察。

ComponentActivity

public class ComponentActivity extends xxx implements LifecycleOwner,xxx {

// 创建了LifecycleRegistry,Lifecycle的实现类
	private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

	@Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
		....
		// 将 ComponentActivity 注入到了 ReportFragment 中
        ReportFragment.injectIfNeededIn(this);
        
    }
	// 实现了LifecycleOwner的getLifecycle方法,最终返回的是LifecycleRegistry
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }

}

可以看到上述代码**ReportFragment.injectIfNeededIn(this);**
，在onCreate的时候，将这个activity注入到一个隐形的ReportFragment中，由该隐形fragment来感知具体的生命周期变化。

ReportFragment

接下来我们来看看ReportFragment的源码（基于androidx.lifecycle:lifecycle-runtime:2.8.3），他是如何感知生命周期变化的？

public open class ReportFragment() : android.app.Fragment() {
    private var processListener: ActivityInitializationListener? = null
	// 1
    private fun dispatchCreate(listener: ActivityInitializationListener?) {
        listener?.onCreate()
    }

    private fun dispatchStart(listener: ActivityInitializationListener?) {
        listener?.onStart()
    }

    private fun dispatchResume(listener: ActivityInitializationListener?) {
        listener?.onResume()
    }

    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        dispatchCreate(processListener)
        // 2
        dispatch(Lifecycle.Event.ON_CREATE)
    }

    override fun onStart() {
        super.onStart()
        dispatchStart(processListener)
        dispatch(Lifecycle.Event.ON_START)
    }

    override fun onResume() {
        super.onResume()
        dispatchResume(processListener)
        dispatch(Lifecycle.Event.ON_RESUME)
    }

    override fun onPause() {
        super.onPause()
        dispatch(Lifecycle.Event.ON_PAUSE)
    }

    override fun onStop() {
        super.onStop()
        dispatch(Lifecycle.Event.ON_STOP)
    }

    override fun onDestroy() {
        super.onDestroy()
        dispatch(Lifecycle.Event.ON_DESTROY)
        // just want to be sure that we won't leak reference to an activity
        processListener = null
    }
    private fun dispatch(event: Lifecycle.Event) {
        if (Build.VERSION.SDK_INT < 29) {
            // Only dispatch events from ReportFragment on API levels prior
            // to API 29. On API 29+, this is handled by the ActivityLifecycleCallbacks
            // added in ReportFragment.injectIfNeededIn
            dispatch(activity, event)
        }
    }
    // 4
    ...
	@RequiresApi(29)
    internal class LifecycleCallbacks : Application.ActivityLifecycleCallbacks {
        override fun onActivityCreated(
            activity: Activity,
            bundle: Bundle?
        ) {}

        override fun onActivityPostCreated(
            activity: Activity,
            savedInstanceState: Bundle?
        ) {
            dispatch(activity, Lifecycle.Event.ON_CREATE)
        }
		...
        companion object {
            @JvmStatic
            fun registerIn(activity: Activity) {
                activity.registerActivityLifecycleCallbacks(LifecycleCallbacks())
            }
        }
    }

	// 具体实现
	public companion object {
        private const val REPORT_FRAGMENT_TAG =
            "androidx.lifecycle.LifecycleDispatcher.report_fragment_tag"

        @JvmStatic
        public fun injectIfNeededIn(activity: Activity) {
            if (Build.VERSION.SDK_INT >= 29) {
                // On API 29+, we can register for the correct Lifecycle callbacks directly
                LifecycleCallbacks.registerIn(activity)
            }
            // Prior to API 29 and to maintain compatibility with older versions of
            // ProcessLifecycleOwner (which may not be updated when lifecycle-runtime is updated and
            // need to support activities that don't extend from FragmentActivity from support lib),
            // use a framework fragment to get the correct timing of Lifecycle events
            val manager = activity.fragmentManager
            if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
                manager.beginTransaction().add(ReportFragment(), REPORT_FRAGMENT_TAG).commit()
                // Hopefully, we are the first to make a transaction.
                manager.executePendingTransactions()
            }
        }

		// 3
        @JvmStatic
        internal fun dispatch(activity: Activity, event: Lifecycle.Event) {
            if (activity is LifecycleRegistryOwner) {
                activity.lifecycle.handleLifecycleEvent(event)
                return
            }
            if (activity is LifecycleOwner) {
                val lifecycle = (activity as LifecycleOwner).lifecycle
                if (lifecycle is LifecycleRegistry) {
                    lifecycle.handleLifecycleEvent(event)
                }
            }
        }
    }
}    

从以上源码看：

// 2： 在各个生命周期中，都会调用dispatch并传入具体的Event；（以此来感知生命周期！！！）
// 3： dispatch方法主要负责获取Lifecycle，调用handleLifecycleEvent方法来处理生命周期Event事件。
// 4： 在SDK29以上注册了LifecycleCallbacks回调，LifecycleCallbacks是Application.ActivityLifecycleCallbacks的实现类，这是29以上才有的api , 因此在api 29以上，不需要直接感受生命周期，当然在29以下api中，在ReportFragment中主要做的任务也是调用dispatch方法，分发生命周期事件。

看到这里我们就能知道几个问题的答案：
1、Lifecycle是如何感知生命周期的？
api 29以下：在ReportFragment中的各个生命周期都调用了dispatch(Lifecycle.Event event) 方法，传递了不同的Event的值；以此来感知生命周期。
api 29以上：通过注入正确的lifecycleCallback来感知生命周期。

2、Lifecycle是如何处理生命周期的？
api 29以下：通过调用了((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);方法，也就是LifecycleRegistry 类来处理这些生命周期。
api 29以上：一样的，通过调用了((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);方法，也就是LifecycleRegistry 类来处理这些生命周期。

LifecycleRegistry

接下来我们就去看看handleLifecycleEvent是怎么做的。

	public actual open fun handleLifecycleEvent(event: Event) {
    	enforceMainThreadIfNeeded("handleLifecycleEvent")
    	moveToState(event.targetState)
	}
	
     private fun moveToState(next: State) {
        ...
        state = next
        ...
        // 重点！！！！
        sync()   
       ...
    }
    
	public val targetState: State
        get() {
            when (this) {
                ON_CREATE, ON_STOP -> return State.CREATED
                ON_START, ON_PAUSE -> return State.STARTED
                ON_RESUME -> return State.RESUMED
                ON_DESTROY -> return State.DESTROYED
                ON_ANY -> {}
             }
            throw IllegalArgumentException("$this has no target state")
        }

解读一下，其实就是根据传入的Lifecycle.Event的值，也就是 Activity、Fragment 生命周期回调的值，来跳转到下一个 Lifecycle.State 的状态，也就是 Lifecycle 将要到什么状态。
结合我们在五大状态中的图一起看更清楚一点。

接下来可以直接看sync方法，

	// happens only on the top of stack (never in reentrance),
    // so it doesn't have to take in account parents
    private fun sync() {
        val lifecycleOwner = lifecycleOwner.get()
            ?: throw IllegalStateException(
                "LifecycleOwner of this LifecycleRegistry is already " +
                    "garbage collected. It is too late to change lifecycle state."
            )
        while (!isSynced) {
            newEventOccurred = false
            if (state < observerMap.eldest()!!.value.state) {
                backwardPass(lifecycleOwner)
            }
            val newest = observerMap.newest()
            if (!newEventOccurred && newest != null && state > newest.value.state) {
                forwardPass(lifecycleOwner)
            }
        }
        newEventOccurred = false
        _currentStateFlow.value = currentState
    }

如果没有同步过，会比较state 当前的状态和observerMap中的eldest ，如果小于旧的，则向后，比较state 当前的状态和newest的状态，如果大于最新的，则向前；具体也可以看五大状态的贴图会更清晰。

接下来我们选向前的方向分析流程

	
	private fun forwardPass(lifecycleOwner: LifecycleOwner) {
        @Suppress()
        val ascendingIterator: Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> =
            observerMap.iteratorWithAdditions()
        // 迭代观察者，对每个观察者，当它的状态小于某个 state 且没有新事件发生时，它会向上分发事件    
        while (ascendingIterator.hasNext() && !newEventOccurred) {
            val (key, observer) = ascendingIterator.next()
            while (observer.state < state && !newEventOccurred && observerMap.contains(key)
            ) {
                pushParentState(observer.state)
                // 根据观察者的当前状态获取一个 Event。Event.upFrom(state) 返回
                // 从给定状态向上过渡到下一个状态对应的事件
                //（例如，从 INITIALIZED 到 CREATED 的事件是 ON_CREATE）。
                // 如果不存在向上事件（比如已经是最高状态），会抛出异常。
                val event = Event.upFrom(observer.state)
                    ?: throw IllegalStateException("no event up from ${observer.state}")
                // 重点！！！
                observer.dispatchEvent(lifecycleOwner, event)
                popParentState() 
                // 事件分发完成后，将之前压入的状态从栈中弹出，恢复上下文。
            }
        }
    }

这段代码主要在状态提升时（比如生命周期从CREATED到STARTED）用来将事件分发给观察者，使它们的状态与当前生命周期状态同步。

// local val observer: LifecycleRegistry.ObserverWithState
主要看这段代码：observer.dispatchEvent(lifecycleOwner, event), 调用观察者包装对象的 dispatchEvent 方法，将事件分发给实际的观察者。这最终会调用观察者的回调方法（如 onCreate、onStart 等）。

接下来我们看观察者分发事件的具体方法，

内部类 LifecycleRegistry.ObserverWithState

这个观察者早在我们的owner（Activity或者fragment） addObserver时完成初始化。可以看五大状态下Lifecycle的Lifecycle.addObserver方法

	internal class ObserverWithState(observer: LifecycleObserver?, initialState: State) {
        var state: State
        // 传入的原始观察者，可以是任何实现了 LifecycleObserver 接口或其子接口
        //（如 DefaultLifecycleObserver、LifecycleEventObserver）的对象。
        var lifecycleObserver: LifecycleEventObserver

        init {
        	// 此处会具体转为对应类
            lifecycleObserver = Lifecycling.lifecycleEventObserver(observer!!)
            state = initialState
        }

        fun dispatchEvent(owner: LifecycleOwner?, event: Event) {
            val newState = event.targetState // 传入事件的目标状态
            // 处理向后状态兼容 1
            state = min(state, newState)
            lifecycleObserver.onStateChanged(owner!!, event)
            state = newState
        }
    }

解释：
//1: 这行代码先将当前状态更新为当前状态和新状态中较小的那个（即较低的生命周期阶段）。这里的“较小”是按照生命周期状态的枚举顺序定义的，通常 INITIALIZED 最小，DESTROYED 最大（但实际顺序需参考源码：一般是 INITIALIZED < CREATED < STARTED < RESUMED；DESTROYED 通常视为比 INITIALIZED 还小？）。这里的关键在于 min(state, newState) 会选择较低的状态。

为什么需要先降低状态再回调？

当事件是向上提升时（例如从 CREATED 提升到 STARTED），newState 高于 state，此时 min(state, newState) = state，所以第一次赋值实际上没有改变状态。

但是，当事件是向下降低时（例如从 STARTED 降到 CREATED），newState 低于 state，此时 min(state, newState) = newState，状态会先被降为最终的目标状态，然后再回调。

这背后的设计考量是：
在回调观察者之前，将观察者的状态“预置”为目标状态（向下时）或保持原样（向上时），目的是为了在回调过程中，如果观察者内部查询当前状态（比如通过 lifecycle.currentState），能够获得一个在事件分发期间语义上正确的中间状态。这种设计保证了状态变化的原子性.

最后我们来看看最关键的代码onStateChanged

DefaultLifecycleObserverAdapter

internal class DefaultLifecycleObserverAdapter(
    private val defaultLifecycleObserver: DefaultLifecycleObserver,
    private val lifecycleEventObserver: LifecycleEventObserver?
) : LifecycleEventObserver {
    override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
        when (event) {
            Lifecycle.Event.ON_CREATE -> defaultLifecycleObserver.onCreate(source)
            Lifecycle.Event.ON_START -> defaultLifecycleObserver.onStart(source)
            Lifecycle.Event.ON_RESUME -> defaultLifecycleObserver.onResume(source)
            Lifecycle.Event.ON_PAUSE -> defaultLifecycleObserver.onPause(source)
            Lifecycle.Event.ON_STOP -> defaultLifecycleObserver.onStop(source)
            Lifecycle.Event.ON_DESTROY -> defaultLifecycleObserver.onDestroy(source)
            Lifecycle.Event.ON_ANY ->
                throw IllegalArgumentException("ON_ANY must not been send by anybody")
        }
        lifecycleEventObserver?.onStateChanged(source, event)
    }
}

为啥我会贴出DefaultLifecycleObserverAdapter这个类的重写方法，原因请看下面：

在上面的LifecycleRegistry.ObserverWithState中,初始化时会通过 Lifecycling.lifecycleEventObserver(observer!!) 转换为对应的observer类。这里我们能看到是通过DefaultLifecycleObserverAdapter适配器统一配置的。

@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP_PREFIX)
public actual object Lifecycling {
    @JvmStatic
    @Suppress("DEPRECATION")
    public actual fun lifecycleEventObserver(`object`: Any): LifecycleEventObserver {
        val isLifecycleEventObserver = `object` is LifecycleEventObserver
        val isDefaultLifecycleObserver = `object` is DefaultLifecycleObserver
        if (isLifecycleEventObserver && isDefaultLifecycleObserver) {
            return DefaultLifecycleObserverAdapter(
                `object` as DefaultLifecycleObserver,
                `object` as LifecycleEventObserver
            )
        }
        if (isDefaultLifecycleObserver) {
            return DefaultLifecycleObserverAdapter(`object` as DefaultLifecycleObserver, null)
        }
        if (isLifecycleEventObserver) {
            return `object` as LifecycleEventObserver
        }
        val klass: Class<*> = `object`.javaClass
        val type = getObserverConstructorType(klass)
        if (type == GENERATED_CALLBACK) {
            val constructors = classToAdapters[klass]!!
            if (constructors.size == 1) {
                val generatedAdapter = createGeneratedAdapter(
                    constructors[0], `object`
                )
                return SingleGeneratedAdapterObserver(generatedAdapter)
            }
            val adapters: Array<GeneratedAdapter> = Array(constructors.size) { i ->
                createGeneratedAdapter(constructors[i], `object`)
            }
            return CompositeGeneratedAdaptersObserver(adapters)
        }
        return ReflectiveGenericLifecycleObserver(`object`)
    }
}

统一分发接口：LifecycleRegistry 内部维护的所有观察者都被要求是 LifecycleEventObserver 类型（通过 Lifecycling.lifecycleEventObserver 工厂方法转换）。这样，在遍历观察者时只需调用统一的 onStateChanged 方法，而无需关心观察者原本是哪种类型。

总结

好了，这样就串起来了！最后总结一下。

1、我们的activity或者fragment作为LifecycleOwner，调用addObserver添加了观察者对象；
2、在activity 的oncreate中会通过一个隐形的reportFragment注入。将生命周期转到这个隐形的fragment中感知。
3、在隐形fragment中会分发各个生命周期的事件，在Lifecycle的实现类LifecycleRegsitry中对这个事件进行处理。主要是观察具体状态变更。
4、最终会通过LifecycleObserver的统一适配器处理状态的变更。
5、此时我们的activity或者fragment生命周期就被感知到了。

参考文献：
Android官方架构组件Lifecycle:生命周期组件详解&原理分析

转载自CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_43532972/article/details/158609449