Lifecycle 使用与源码分析

一、Lifecycle 介绍

Lifecycle是一个生命周期感知组件,一般用来响应Activity、Fragment等组件的生命周期变化,并将变化通知到已注册的观察者。有助于更好地组织代码,让代码逻辑符合生命周期规范,减少内存泄漏,增强稳定性。

这些组件可帮助您生成更易于组织且通常更轻量级的代码,这些代码更易于维护。

按照国际规范,我们先讲使用,后解析源码。

二、使用方法

先来看一下如何使用,这样再去分析源码就能有的放矢

1.添加依赖:

在app或者module目录下的build.gradle中,添加依赖:

这里介绍Androidx 项目引入lifecycle

dependencies {
    implementation "androidx.lifecycle:lifecycle-runtime-ktx:2.2.0"
    // Annotation processor
    kapt "androidx.lifecycle:lifecycle-compiler:2.2.0"
}

2.LifecycleObserver接口

实现LifecycleObserver 接口,使用 @OnLifecycleEvent注解在方法上,注解值表示该方法对应生命周期的哪个函数

//特别注意,这里不需要传入Lifecycle,本例是为了测试嵌套添加LifecycleObserver 的生命周期,才故意这样写
class P1(var mLifecycle: Lifecycle) : LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun p1Create() {
        Log.i("P1 ", "执行了p1 的 create 生命周期")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun p1Start() {
        //注意,这里是嵌套添加LifecycleObserver,
        //会在P1 Start 阶段完全执行完,才去执行P2 Start阶段
        mLifecycle.addObserver(P2(mLifecycle))
        Log.i("P1 ", "执行了p1 的 start 生命周期")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun p1Resume() {
        Log.i("P1 ", "执行了p1 的 resume 生命周期")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun p1Pause() {
        Log.i("P1 ", "执行了p1 的 pause 生命周期")
    }
}

3.将LifecycleObserver添加到Lifecycle的观察者列表

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        Log.i("MainActivity ", "onCreate 生命周期 开始执行")
        setContentView(R.layout.activity_main)
        //这句很重要,如果不填加的话就收不到activity状态回调,lifecycle为AppCompatActivity的getLifecycle方法
        lifecycle.addObserver(P1(lifecycle))  
        Log.i("MainActivity ", "onCreate 生命周期 执行完成")

    }


    override fun onStart() {
        super.onStart()
        Log.i("MainActivity ", "start 生命周期 执行完成")
    }
}

输出日志

 I/MainActivity: onCreate 生命周期 开始执行
 I/MainActivity: onCreate 生命周期 执行完成
 I/P1: 执行了p1 的 create 生命周期
 I/MainActivity: start 生命周期 执行完成
 I/P1: 执行了p1 的 start 生命周期
 I/P1: 执行了p1 的 resume 生命周期

当然也可以自己实现 LifecycleOwner接口,需要做3件事情

1、实现LifecycleOwner 接口的方法:getLifecycle()
2、注册Lifecycle new LifecycleRegistry(this)
3、在Activity生命周期函数中分发事件

public class MainActivity extends Activity implements LifecycleOwner {
    private LifecycleRegistry mLifecycleRegistry;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mLifecycleRegistry = new LifecycleRegistry(this);
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
        mLifecycleRegistry.addObserver(new TestObserver());
    }

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

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

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

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

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

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

4. 监听应用前后台切换

前面讲解的都是处理一个activity生命周期,那如果要是想要监听整个应用的生命周期该怎么办呢?
一些银行 app 都有这样的功能,当切换应用到后台,会给用户一个提示,“xx 手机银行正在后台运行,请注意安全!” 。用我 LifeCycle 来实现的话,异常的简单。

class KtxAppLifeObserver : LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onForeground() {
        Ktx.app.toast("应用进入前台")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onBackground() {
        Ktx.app.toast("应用进入后台")
    }
}

然后在应用启动时,如 ContentProvier,Application 中 ,调用如下代码:

 ProcessLifecycleOwner.get().lifecycle.addObserver(KtxAppLifeObserver())

通过代码你也发现了是通过我的家族成员 ProcessLifecycleOwner 来实现的。它可以感知整个应用进程的生命周期,这样一来,监听应用前后台切换就轻而易举了。3.3和3.4小节将会带领我们分析这个问题。

5. 全局管理 Activity

相信你们都做过这样的功能,特定情况下要 finish 掉打开过的所有 Activity,或者要关闭指定的 Activity 。通常的做法是在 BaseActivity 的生命周期回调中保存已经打开或关闭的 Activity 。虽然实现也还算优雅,但是如何给日益臃肿的 BaseActivity 减负呢?又到我 LifeCycle 出场了。

class KtxLifeCycleCallBack : Application.ActivityLifecycleCallbacks {

    override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
        KtxManager.pushActivity(activity)
        "onActivityCreated : ${activity.localClassName}".loge()
    }

    override fun onActivityStarted(activity: Activity) {
        "onActivityStarted : ${activity.localClassName}".loge()
    }

    override fun onActivityResumed(activity: Activity) {
        "onActivityResumed : ${activity.localClassName}".loge()
    }

    override fun onActivityPaused(activity: Activity) {
        "onActivityPaused : ${activity.localClassName}".loge()
    }

    override fun onActivityDestroyed(activity: Activity) {
        "onActivityDestroyed : ${activity.localClassName}".loge()
        KtxManager.popActivity(activity)
    }

    override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle?) {
    }

    override fun onActivityStopped(activity: Activity) {
        "onActivityStopped : ${activity.localClassName}".loge()
    }
}

通过我的另一个家族成员,Application.ActivityLifecycleCallbacks ,你可以监听到所有的 Activity 的所有生命周期。在 Application 中注册这个 Callback 就行了。

application.registerActivityLifecycleCallbacks(KtxLifeCycleCallBack())

根据 单一职责原则,一个类做一件事情,这种写法将 Activity 的管理职责集中到一个类中,降低代码耦合。而原来的写法有两个问题,第一,你必须得继承 BaseActivity 才能具备管理当前 Activity 的功能。这又涉及到合作开发,不想继承,或者忘记继承。第二,让 BaseActivity 承担了过多的职责,并不符合基本的设计原则。

6. 配合协程使用

协程作为 Android 异步处理方案的新贵,不仅仅是我 LifeCycle ,ViewModel,LIveData 等其他 Jetpack 组件都为其提供了特定的支持。
要使用 LifeCycle 的协程支持,需要添加androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha01 或更高版本。该支持库为每个 LifeCycle对象定义了 LifecycleScope 。在此范围内启动的协程会在 LifeCycle 被销毁时自动取消。你可以通过 lifecycle.coroutineScopelifecycleOwner.lifecycleScope 属性访问 Lifecycle 的 CoroutineScope。下面是一个简单的示例:

class MyFragment: Fragment() {
        override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
            super.onViewCreated(view, savedInstanceState)
            viewLifecycleOwner.lifecycleScope.launch {
               ...
            }
        }
    }

三、源码分析

3.1 Lifecycle相关的类图

先来看一下 Lifecycle相关的类图
在这里插入图片描述

  • 自定义的Activity都继承自AppCompatActivity ,AppCompatActivity 继承了FragmentActivity,FragmentActivity继承了ComponentActivity。上图全部用AppCompatActivity代表了这个3个Activity。

  • ComponentActivity实现了LifecycleOwner接口,同时持有实现了Lifecycle的LifecycleRegistry对象,这个对象就可以将其理解为观察者模式中的Subject,LifecycleRegistr聚合多个LifecycleObserver,生命周期改变时通知LifecycleObserver进行相应的方法调用。

    public class ComponentActivity extends androidx.core.app.ComponentActivity implements
            LifecycleOwner,
            ViewModelStoreOwner,
            SavedStateRegistryOwner,
            OnBackPressedDispatcherOwner
    
    private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
    
    @Override
    public Lifecycle getLifecycle() {
        //返回构造好的LifecycleRegistry对象,正常在使用过程中我们会调用这个方法并添加Observer,从这里可以看到。
        //实际上我们最终是把实现了LifecycleObserver的对象添加到了LifecycleRegistry中
        return mLifecycleRegistry;
    }
    
  • FragmentActivity在Activity生命周期函数中分发事件

     @Override
        protected void onCreate(@Nullable Bundle savedInstanceState) {
          ...
          mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
          mFragments.dispatchCreate();
        }
    

我们看到,ComponentActivity实现了LifecycleOwner这个接口,那么表明它就是一个宿主类了。

//作为一个拥有生命周期的宿主,这些生命周期可以被其他自定义的组件进行监听,
//但是这些组件不需要在Activity或者Fragment中编写任何与生命周期相关的代码实现
public interface LifecycleOwner {
    @NonNull
    Lifecycle getLifecycle();
}

3.2、生命周期感知

Lifecycle是一个生命周期感知的框架,那么它是如何感知Activity的生命周期呢?

看AppCompatActivity 继承的ComponentActivity 中的onCretae方法

protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    ReportFragment.injectIfNeededIn(this);
}

ReportFragment 类是一个Fragment,它负责分派生命周期的时间.
injectIfNeededIn()就是在当前的Activity里添加一个ReportFragment。

    public static void injectIfNeededIn(Activity activity) {
        if (Build.VERSION.SDK_INT >= 29) {
        	//API29+,直接使用LifecycleCallbacks
            // On API 29+, we can register for the correct Lifecycle callbacks directly
            LifecycleCallbacks.registerIn(activity);
        }
        //在 API 29 之前,为了保持与旧版本的 ProcessLifecycleOwner 的兼容性
        //(生命周期运行时更新时可能不会更新并且需要支持不从支持库中的 FragmentActivity 扩展的活动),
        // 使用框架片段来获取正确的 生命周期事件的时间安排
        android.app.FragmentManager manager = activity.getFragmentManager();
        if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
            manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
            // Hopefully, we are the first to make a transaction.
            manager.executePendingTransactions();
        }
    }

在API29+,直接使用LifecycleCallbacks来回调生命周期,后面会讨论,本篇主要探讨API29以下的版本。再看ReportFragment的生命周期函数。

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

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

@Override
public void onResume() {
    super.onResume();
    dispatchResume(mProcessListener);
    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);
    // just want to be sure that we won't leak reference to an activity
    mProcessListener = null;
}

private void dispatch(@NonNull Lifecycle.Event 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(getActivity(), event);
    }
}

static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
    if (activity instanceof LifecycleRegistryOwner) {
        ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
        return;
    }

    if (activity instanceof LifecycleOwner) {
        Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
        if (lifecycle instanceof LifecycleRegistry) {
            ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
        }
    }
}

你会发现都调用了dispatch()方法,而dispatch()方法则会判断Activity是否实现了LifecycleOwner接口,如果实现了该接口就调用LifecycleRegister的handleLifecycleEvent(),这样生命周期的状态就会借由LifecycleRegistry通知给各个LifecycleObserver从而调用其中对应Lifecycle.Event的方法。这种通过Fragment来感知Activity生命周期的方法其实在Glide的中也是有体现的。
大概流程图如下所示
在这里插入图片描述

3.3、LifecycleRegister分析

把LifecycleObserver (观察者)添加到 Lifecycle(被观察者)的列表中,使用的是addObserver,而在源代码中,实现Lifecycle接口的是LifecycleRegister

    getLifecycle().addObserver(new LifecycleObserver1 ());

LifecycleRegister#addObserver()

来看一下LifecycleRegister 类中的addObserver方法

@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    //这个状态值是一个枚举类型的,生命周期越靠后,值越小 DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

    if (previous != null) {
        return;
    }
    //由上面的使用可知,LifecycleOwner相当于是观察者模式中的被观察者,它来向各LifecycleObserver发送生命周期消息
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }
    /*
    重点:两件事,1. 循环对齐状态,
    这里的While循环主要的目的在于通过循环保证Lifecycle中的事件和状态对齐,不遗漏。什么意思呢
    比如你是在onResume中调用addObserver添加监听的,那么通过这个循环进行处理,onCreate和onStart对应
    的事件也会被分发,这样一来监听者同样会处理ON_CREATE和ON_START事件
    ===============================================
    2. 处理嵌套事件
	mAddingObserverCounter 表示正在添加的观察者的数量,
	开始添加新的observe之前,对该变量进行 ++ 操作,添加完成后,进行 -- 操作。
	如果mAddingObserverCounter 不为0 ,说明在添加observe A时,在while循环中更新observe A的生命周期时,又添加了新的observe B。
	这就是嵌套事件。而由于B 是后添加的,所以同一生命周期的回调顺序,要保证B在A后被回调。
	mHandlingEvent  表示是否正在处理事件中
	*/
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    //这里是while 循环,新添加的LifecycleObserver ,会不断更新自己的生命周期到指定的targetState
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        //注意这里的upEvent,获取statefulObserver.mState下一状态的值,
        //也就是说mParentStates中的状态比即将执行的生命周期要小一个阶段
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();
        // mState / subling may have been changed recalculate 兄弟节点可能会改变这个计算
        targetState = calculateTargetState(observer);
    }
	// 没有事件正在处理,或者是添加了observe,就需要重新同步一次状态
	// 嵌套添加observer,只有最先添加的observer,isReentrance 才是false,才会执行sync()
	// 也就是说嵌套添加observer,sync 只会被执行一次。
    if (!isReentrance) {
        // we do sync only on the top level.
        //防止在添加过程中,生命周期发生了变化,状态不一致的问题
        sync();
    }
    mAddingObserverCounter--;
}

LifecycleRegister#FastSafeIterableMap

其中mObserverMap 是FastSafeIterableMap

    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();

这里生成了一个ObserverWithState,然后放入FastSafeIterableMap里,这个类
是一个自定义列表,用于保存观察者并可在遍历期间处理删除/添加。
观察者1和观察者2的任何时刻:如果addition_order(observer1)<addition_order(observer2),那么 state(observer1)> = state(observer2)

LifecycleRegister#calculateTargetState

/**
 * 计算出的 targetState 一定是小于等于当前 mState 的
 */
private State calculateTargetState(LifecycleObserver observer) {
   //前面observer 都会被添加到一个Map中, 这里是在map中获取到当前observer的前一个observer
    Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
	// 获取前一个observer 的最终状态
    State siblingState = previous != null ? previous.getValue().mState : null;
    // 如果是嵌套添加observer,获取父级observer的状态,这个状态是当前父级状态的前一个状态(详见addObserver 的while循环中的代码), 无重入情况下可不考虑 parentState ,为 null
    State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
            : null;
    //获取最小状态,DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED     
    return min(min(mState, siblingState), parentState);
}

我们可以添加多个生命周期观察者,这时候就得注意维护它们的状态。每次添加新的观察者的初始状态是 INITIALIZED ,需要把它同步到当前生命周期状态,确切的说,同步到一个不大于当前状态的 targetState 。从源码中的计算方式也有所体现,targetState 是 当前状态 mState,mObserverMap 中最后一个观察者的状态 ,有重入情况下 parentState 的状态 这三者中的最小值。

为什么要取这个最小值呢?我是这么理解的,当有新的生命周期事件时,需要将 mObserverMap 中的所有观察者都同步到新的同一状态,这个同步过程可能尚未完成,所以新加入的观察者只能先同步到最小状态。注意在 addObserver 方法的 while 循环中,新的观察者每改变一次生命周期,都会调用 calculateTargetState() 重新计算 targetState 。

有小伙伴可能有疑问,已经有了siblingState状态,为什么还要获取parentState 状态? 而且如果你调试过程序会发现,这里的siblingState 值(如果有的话) 和parentState 值是一样的。

parentState的存在是为了解决下面这种情况,结合下面这个。

void onStart() {
    mRegistry.removeObserver(this);
    mRegistry.add(newObserver);
}

为了方便描述,我们把被删除的LifecycleObserver 称为 A,新添加的称为B

删除LifecycleObserver,也就是从mObserverMap中移除,那么在calculateTargetState 函数中,siblingState 的值就是null

这里是嵌套添加LifecycleObserverB,是在LifecycleObserverA的回调函数中添加的,此时LifecycleObserverA, 在源码中执行了pushParentState ,再回调本函数onStart,回调执行结束会执行popParentState。

如果此时添加LifecycleObserverB,在调用calculateTargetState函数中,siblingState 的值就可能为空的(如果mObserverMap 只有一个值,removeObserver后,就为空),parentState值不为空(在popParentState 中设置的,该值也就是LifecycleObserverA的上个生命阶段),最后添加完成后,执行了sync(),再次同步状态

也就说LifecycleObserverA 某一生命周期阶段(这里指onStart)执行完成后,才会执行LifecycleObserverB的同一生命周期阶段。
就前面的分析,onCreate流程应该是这个样子,需要注意的是Observer的状态在onstateChange方法之后才会更新
在这里插入图片描述
再看onStart事件的分发,与上一个forwardPass方法不同,这里我们标记了pushParentState,不是上一次没有而是用不上,在FirstObserver的onStart方法里先移除了自己再添加了SecondObserver,所以FirstObserver还没来得及升级到STARTED状态就挂了。

再看calculateTargetState方法,由于前面FirstObserver被移除了,state为null,如果没有使用pushParentState记录FirstObserver状态,那么返回的目标状态就是STARTED,这样SecondObserver就会连续触发onCreate和onStart,但此时FirstObserver的onstateChange还没执行完,状态还没升到STARTED,导致后加的SecondObserver状态越界,使用parentState起到限制作用。在这个addObserver方法中SecondObserver只会被提到CREATED状态,随后的循环才会分发SecondObserver的onStart事件和提升状态。
在这里插入图片描述

最终的稳定状态下,没有生命周期切换,没有添加新的观察者,mObserverMap 中的所有观察者应该处于同一个生命周期状态。最终状态如下
在这里插入图片描述

LifecycleRegister#handleLifecycleEvent

前面提到了,每当生命周期发生变化,最终都会调用dispatch方法中的handleLifecycleEvent方法
下图是每个生命周期对应的状态,及转换:
在这里插入图片描述
这张图来源于Android开发者网站,主要描述了Lifecycle中所定义的事件和状态的流转情况。我们可以看到,整个过程以RESUMED为分界状态,分别有从INITIALIZED到RESUMED的前进流程,和从RESUMED到DESTROYED的回退流程。

正向前进流程

  1. 初始状态为INITIALIZED, 当执行了onCreate方法,触发ON_CREATE事件后进入CREATED状态。
  2. 执行了onStart方法触发ON_START事件后进入STARTED状态
  3. 执行onResume方法触发ON_RESUME状态后进入RESUMED状态

后退反向流程

  1. 当处于RESUMED状态时,如果发生onPause方法的执行,就会触发ON_PAUSE事件,进入STARTED状态,什么时候
    触发onPause呢,可以参考Activity/Fragment的生命周期
  2. 如果继续进入onStop方法触发ON_STOP事件的话继续回退到CREATED状态
  3. 最后如果走到onDestroy触发ON_DESTROY事件,那么进入DESTROYED状态

我们可以看到,状态并没有像生命周期方法或事件一样有一一对应的。对应的状态和生命周期关系如下

  • onStart和onPause处于同一个状态,STARTED
  • onStop和onCreate后处于同一状态,CREATED
  • onDestroy处于DESTROYED状态
  • onResume处于RESUMED状态
  • 初始状态为INITIALIZED状态

下面来看下handleLifecycleEvent方法的代码:

 public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
     State next = getStateAfter(event);
     moveToState(next);
 }

private void moveToState(State next) {
    if (mState == next) {
        return;
    }
    mState = next;
    //mHandlingEvent 表示处理事件,所以不需要再次调用
    //mAddingObserverCounter != 0 表示正在添加observer(在函数addObserver),满足此条件,最后会调用sync(),所以这里不需再次调用
    if (mHandlingEvent || mAddingObserverCounter != 0) {
       // 停止正在更新生命周期的操作,因为有新的事件传递进来
        mNewEventOccurred = true;
        // we will figure out what to do on upper level.
        return;
    }
    mHandlingEvent = true;
    sync();
    mHandlingEvent = false;
}
private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
                + "new events from it.");
        return;
    }
    while (!isSynced()) {
        mNewEventOccurred = false;
        // no need to check eldest for nullability, because isSynced does it for us.
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
            backwardPass(lifecycleOwner);
        }
        Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            forwardPass(lifecycleOwner);
        }
    }
    mNewEventOccurred = false;
}

这里可以看到

  • 如果ObserverWithState的state小于当前state,那么就调用forwardPass方法,
  • 如果大于当前state,那么就调用backwardPass方法。

ObserverWithState默认的State是在addObserver方法里确定的,如果不是DESTROYED状态,就初始为 INITIALIZED

LifecycleRegister#forwardPass

继续看forwardPass方法

    private void forwardPass(LifecycleOwner lifecycleOwner) {
        Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
                mObserverMap.iteratorWithAdditions();
        //如果有新的事件发生,则停止        
        while (ascendingIterator.hasNext() && !mNewEventOccurred) {
            Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
            ObserverWithState observer = entry.getValue();
            //如果有新的事件发生,则停止    
            while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                    && mObserverMap.contains(entry.getKey()))) {
                //下面这三句,和addObserve 中的操作一样    
                pushParentState(observer.mState);
                observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
                popParentState();
            }
        }
    }

上面的observer其实是一个ObserverWithState对象,它是一个静态内部类

LifecycleRegister#ObserverWithState

添加Observer的时候会把LifecycleObserver包装成ObserverWithState,主要的目的在于对LifecycleObserver和State进行绑定,并添加dispatchEvent方法处理事件分发逻辑

    static class ObserverWithState {
        State mState;
        LifecycleEventObserver mLifecycleObserver;

        ObserverWithState(LifecycleObserver observer, State initialState) {
            //这里调用lifecycleEventObserver,生成一个事件观察者mLifecycleObserver,
            //每个生命周期,要发送给谁,都是通过这个变量来实现的(它是一个接口onStateChanged,有不同的实现)
            mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
            mState = initialState;
        }

        void dispatchEvent(LifecycleOwner owner, Event event) {
            State newState = event.getTargetState();
            mState = min(mState, newState);
            //生命周期的分发,最终在这里调用到 自己实现的
            mLifecycleObserver.onStateChanged(owner, event);
            //这里会在回调完成后,才更新状态
            //!!!!!! 重入的时候,如果涉及到删除
            mState = newState;
        }
    }

调用了Lifecycling.lifecycleEventObserver方法来获得LifecycleEventObserver 的实例,通过这个实例调用onStateChanged

    static LifecycleEventObserver lifecycleEventObserver(Object object) {
        boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
        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;
        }
		//获取监听者的类型,实际上就有两种,一种是使用Lifecycle-compiler自动生成的,一种是继承或者实现内置Observer类的
		//通过反射,找到Lifecycle 自动生成的类 XXX_LifecycleAdapter
        final Class<?> klass = object.getClass();
        int type = getObserverConstructorType(klass);
        //处理使用lifecycle-compiler进行编译时生成Observer的处理逻辑
        if (type == GENERATED_CALLBACK) {
            List<Constructor<? extends GeneratedAdapter>> constructors =
                    sClassToAdapters.get(klass);
            //如果是只有一个构造函数,构造GeneratedAdapter 实例对象并作为SingleGeneratedAdapterObserver
            //的构造函数参数传递进来,最终生成一个SingleGeneratedAdapterObserver,这个类实现
            //LifecycleEventObserver,并在onStateChanged方法中调用GeneratedAdapter 的callMethod方法,最终调用
            //到我们的Lifecycle Observer类的周期函数
            if (constructors.size() == 1) {
                GeneratedAdapter generatedAdapter = createGeneratedAdapter(
                        constructors.get(0), object);
                //最终使用XXX_LifecycleAdapter,创建SingleGeneratedAdapterObserver
                return new SingleGeneratedAdapterObserver(generatedAdapter);
            }
            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);
        }
        return new ReflectiveGenericLifecycleObserver(object);
    }

这个方法大概意思就是,根据传进的LifecycleObserver进行判断,构造一个LifecycleEventObserver对象.

LifecycleEventObserver 是一个接口 有一个方法onStateChanged(),有四种实现:

  1. FullLifecycleObserverAdapter
  2. SingleGeneratedAdapterObserver
  3. CompositeGeneratedAdaptersObserver
  4. ReflectiveGenericLifecycleObserver

FullLifecycleObserverAdapter

LifecycleEventObserver,该接口继承自LifecycleObserver,增加了onStateChanged回调函数,实现了不需要通过OnLifecycleEvent注解监听生命周期事件,所有的事件变换都会在onStateChanged中进行监听

/**
 * 如果一个类实现了这个接口和DefaultLifecycleObserver接口,那么DefaultLifecycleObserver方法会被先调用,紧接着就会
 * 调用onStateChanged方法
 * 如果一个类实现了这个接口,同时也实现了了OnLifecycleEvent注解接口,那么注解接口就会被忽略
 */
public interface LifecycleEventObserver extends LifecycleObserver {
    void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}

FullLifecycleObserver,定义了所有完整与宿主生命周期相同的函数,实现类直接可以在对应的函数中处理生命周期事件

interface FullLifecycleObserver extends LifecycleObserver {

    void onCreate(LifecycleOwner owner);

    void onStart(LifecycleOwner owner);

    void onResume(LifecycleOwner owner);

    void onPause(LifecycleOwner owner);

    void onStop(LifecycleOwner owner);

    void onDestroy(LifecycleOwner owner);
}

可以看到组件本身为了提供不同的事件处理方式,提供了非常灵活的接口给调用方,而FullLifecycleObserverAdapter正好是利用适配器模式,通过适配器来实现对FullLifecycleObserver 和LifecycleEventObserver 这两种Observer的事件统一处理逻辑。

 //本身实现了LifecycleEventObserver ,这样可以方便的处理LifecycleEventObserver 的onStageChange回调
class FullLifecycleObserverAdapter implements LifecycleEventObserver {
    //FullLifecycleObserver 
    private final FullLifecycleObserver mFullLifecycleObserver;
     //FullLifecycleObserver 
    private final LifecycleEventObserver mLifecycleEventObserver;

    FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
            LifecycleEventObserver lifecycleEventObserver) {
        mFullLifecycleObserver = fullLifecycleObserver;
        mLifecycleEventObserver = lifecycleEventObserver;
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
       //在onStateChanged中做了两件事情
       //1. 利用回调来处理和调用mFullLifecycleObserver的各个生命周期函数
       //2. 在这里同样会将事件继续传递给LifecycleEventObserver 
        switch (event) {
            case ON_CREATE:
                mFullLifecycleObserver.onCreate(source);
                break;
            case ON_START:
                mFullLifecycleObserver.onStart(source);
                break;
            case ON_RESUME:
                mFullLifecycleObserver.onResume(source);
                break;
            case ON_PAUSE:
                mFullLifecycleObserver.onPause(source);
                break;
            case ON_STOP:
                mFullLifecycleObserver.onStop(source);
                break;
            case ON_DESTROY:
                mFullLifecycleObserver.onDestroy(source);
                break;
            case ON_ANY:
                throw new IllegalArgumentException("ON_ANY must not been send by anybody");
        }
        
        if (mLifecycleEventObserver != null) {
            mLifecycleEventObserver.onStateChanged(source, event);
        }
    }
}

解析和处理lifecycle-compiler

为什么要提供这个组件,本章内容我们有提到过LifecycleObserver这个接口,它是一个标志性接口,需要监听生命周期事件的话需要使用OnLifecycleEvent注解,而这个注解绑定的函数最终是通过反射来调用的,这样一来在性能上会有一些损耗,所以就提供这个组件,在编译期就会生成对应的LifecycleAdapter类,可以直接进行调用,不用反射。
我们先看一下利用Lifecycle-compiler自动生成的类(app/build/generated/source/apt/包名/下生成了一个辅助文件)

//生成一个LifecycleAdapter结尾的类,并实现GeneratedAdapter 
public class Task_LifecycleAdapter implements GeneratedAdapter {
  //这个receiver就是我们定义的实现了LifecycleObserver接口的实例对象
  final Task mReceiver;

  Task_LifecycleAdapter(Task receiver) {
    this.mReceiver = receiver;
  }

  @Override
  public void callMethods(LifecycleOwner owner, Lifecycle.Event event, boolean onAny,
      MethodCallsLogger logger) {
    boolean hasLogger = logger != null;
    if (onAny) {
      return;
    }
    //在这个callMethods中会根据Event的类型调用Observer的对应方法
    if (event == Lifecycle.Event.ON_RESUME) {
      if (!hasLogger || logger.approveCall("start", 1)) {
        mReceiver.start();
      }
      return;
    }
    if (event == Lifecycle.Event.ON_STOP) {
      if (!hasLogger || logger.approveCall("stop", 1)) {
        mReceiver.stop();
      }
      return;
    }
    ...
  }
}

前文提到在处理编译生成的LifecycleAdapter时会把该LifecycleAdapter类作为SingleGeneratedAdapterObserver(单构造函数情况下,这里只分析单构造函数)的构造函数参数,实例化SingleGeneratedAdapterObserver作为lifecycleEventObserver的返回值。

本例中onStateChanged 函数会调用到下面这个类中

class SingleGeneratedAdapterObserver implements LifecycleEventObserver {
	 //对应的就是编译时生成的P1_LifecycleAdapter类
    private final GeneratedAdapter mGeneratedAdapter;

    SingleGeneratedAdapterObserver(GeneratedAdapter generatedAdapter) {
        mGeneratedAdapter = generatedAdapter;
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
        //mGeneratedAdapter 也就是Lifecycle 自动生成的类,这里特指P1_LifecycleAdapter
        //onStateChanged方法中直接调用生成的LifecycleAdapter的callMethods方法,这样就会最终调用
        //到我们自定义的LifecycleObserver类中相关的注解绑定函数
        mGeneratedAdapter.callMethods(source, event, false, null);
        mGeneratedAdapter.callMethods(source, event, true, null);
    }
}

通过这样的方式,使得调用效率会更高,避免了反射调用的性能损耗。如果没有采用Lifecycle-compiler的话是采用反射的方式来调用目标LifecycleObserver,具体可以参考ReflectiveGenericLifecycleObserver,我们不再进行分析。

下面来看下,自动生成的类P1_LifecycleAdapter,在不同的生命周期事件,调用不同的函数
使用注解,会自动生成。所以需要在依赖中添加kapt “androidx.lifecycle:lifecycle-compiler:2.2.0”
不添加的话也可以运行,但不会生成自动类,运行还是通过注解反射的方式,会损耗性能。

public class P1_LifecycleAdapter implements GeneratedAdapter {
  final P1 mReceiver;

  P1_LifecycleAdapter(P1 receiver) {
    this.mReceiver = receiver;
  }

  @Override
  public void callMethods(LifecycleOwner owner, Lifecycle.Event event, boolean onAny,
      MethodCallsLogger logger) {
    boolean hasLogger = logger != null;
    if (onAny) {
      return;
    }
    if (event == Lifecycle.Event.ON_CREATE) {
      if (!hasLogger || logger.approveCall("p1Create", 1)) {
        mReceiver.p1Create();
      }
      return;
    }
    if (event == Lifecycle.Event.ON_START) {
      if (!hasLogger || logger.approveCall("p1Start", 1)) {
        mReceiver.p1Start();
      }
      return;
    }
    if (event == Lifecycle.Event.ON_RESUME) {
      if (!hasLogger || logger.approveCall("p1Resume", 1)) {
        mReceiver.p1Resume();
      }
      return;
    }
    if (event == Lifecycle.Event.ON_PAUSE) {
      if (!hasLogger || logger.approveCall("p1Pause", 1)) {
        mReceiver.p1Pause();
      }
      return;
    }
  }
}

四、Lifecycle为什么要使用Fragment

Lifecycle为什么要使用Fragment,为什么不直接把这些方法,在Activity中实现呢?

我个人认为有两个原因:

因为不是所有的页面都继承AppCompatActivity,为了兼容非AppCompatActivity
Activity和Fragment都实现Lifecycle,避免代码重复
所以封装一个同样具有生命周期的Fragment来给Lifecycle分发生命周期事件。

五、总结

State是如何与Activity/Fragment的生命周期绑定的?

  • 在Activity中添加一个ReportFragment(如果你的Activity继承AppCompatActivity,会在父类的onCreate()中添加ReportFragment,否则由LifecycleDispatcher添加),在ReportFragment生命周期函数中调用LifecycleRegistry.handleLifecycleEvent()方法改变State。

Event事件是如何分发到LifecycleObserver的?

  • LifecycleRegistry在收到handleLifecycleEvent()后,内部调用moveToState()方法,改变State值,每一次State值改变,都会调用LifecycleObserver.onStateChanged()方法将Event分发到LifecycleObserver

最后总结一张图
在这里插入图片描述

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值