Android architecture components学习笔记1-Lifecycle源码分析

我们知道在安卓的开发中，出现过很多的架构，从最开始的直接4大组件开撸的类mvc，到后来的mvp，mvvm。有鉴于此，google也终于在2017年的IO开发大会上推出了Android Architecture Components(AAC)来帮助Android开发者构建更好的app架构。

AAC简介

关于AAC架构，没有比官方提供的整体架构图更能说明了，我们先看官方架构图。

可以看到，AAC实际上是一个mvvm架构，由activity,fragment充当view,ViewModel充当控制层，Repository充当数据源。那么从图上看，AAC架构和我们常用的mvp架构的最大区别在哪里呢？个人认为最主要的区别有2点。

–使用ViewModel代替了Present。

–VIew和ViewModel单向依赖。

我们都知道，在mvp中，view和Present会互相持有对方的引用，已达到View和present交互的目的，但是在AAC中，只有View持有ViewModel的引用，而ViewModel并不持有View的引用，这是如何做到的呢？这就是图中的LiveData的功劳啦，我们之后介绍。

AAC组件简介

–LifeCycle

生命周期管理（Lifecycles）组件，帮助开发者创建 “可感知生命周期的” 组件，让其自己管理自己的生命周期，从而减少内存泄露和崩溃的可能性。生命周期库是其他架构组件（如 LiveData）的基础。
android.arch.lifecycle 包提供了类和接口允许你构建生命周期感知（lifecycle-aware）的组件——可以基于当前activity或fragment生命周期自动调节它们的行为的组件。

–LiveData

LiveData 是一款基于观察者模式的可感知生命周期的核心组件。LiveData 为界面代码 （Observer）的监视对象 （Observable），当 LiveData 所持有的数据改变时，它会通知相应的界面代码进行更新。同时，LiveData 持有界面代码 Lifecycle 的引用，这意味着它会在界面代码（LifecycleOwner）的生命周期处于 started 或 resumed 时作出相应更新，而在 LifecycleOwner 被销毁时停止更新。通过 LiveData，开发者可以方便地构建安全性更高、性能更好的高响应度用户界面。

–ViewModel

ViewModel 将视图的数据和逻辑从具有生命周期特性的实体（如 Activity 和 Fragment）中剥离开来。直到关联的 Activity 或 Fragment 完全销毁时，ViewModel 才会随之消失，也就是说，即使在旋转屏幕导致 Fragment 被重新创建等事件中，视图数据依旧会被保留。ViewModels 不仅消除了常见的生命周期问题，而且可以帮助构建更为模块化、更方便测试的用户界面。

上面三个组件的介绍来自官方文档，初看可能不明觉厉，不过不要紧，下面我们将分别进行介绍。

LifeCycle简介

LifeCycle可以说是AAC架构的一个核心组件，它的作用是可以让我们创建具有生命周期的对象，这是什么意思呢？大家都知道，我们平常使用的Activity,fragment等，都是具有生命周期的，而且它们的生命周期都是由系统进行管理的，我们app无法对其进行控制，而是只能收到生命周期变化的回调，比如onCreate,onStart等方法。作为一个开发者，我们必须遵守这些生命周期的规则，否则就可能出现应用奔溃或者内存泄漏的情况。而我们的LifeCycle包就是为了让我们自己创建的对象也能感受到android组件生命周期而诞生的。参考官方介绍和教程
https://developer.android.google.cn/topic/libraries/architecture/lifecycle.html

如何让自己创建的对象感知Activity/fragment生命周期

设想一下，如果让我们自己设计，我们要如何让自建对象感知activity或者fragment的生命周期呢？我觉得这个问题并不困难，在mvp的某一种实现中，我们为了让Present能够感知到Activity的生命周期，就采用了下面的方法来解决这个问题。示例代码如下：

public class Present {
    public void onCreate(){
    }

    public void onStart(){
    }

    public void onStop(){
    }

    public void onDestroy(){   
    }
}

我们先在Present中增加需要的各个回调方法，之后Activity持有Present的引用，并在Activity的生命周期方法中，调用Present的方法，这样我们的Present也有了生命周期。

public class MainActivity extends AppCompatActivity {

    private Present present = new Present();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        present.onCreate();
    }

    @Override
    protected void onStart() {
        super.onStart();
        present.onStart();
    }

    @Override
    protected void onStop() {
        super.onStop();
        present.onStop();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        present.onDestroy();
    }
}

这个例子看起来也很好的实现了需求，但是毫无扩展性，比如我还有另一个对象B也需要声明周期或者其他Activity中的对象C也需要声明周期呢，难道我们要把这段代码写很多遍么，另外如果我们现在需要Activity当前的状态，比如是否执行过onResume,或者是否执行过onStop应该怎么做呢，为了满足这些需求，我们决定把这个例子改良一下。

首先，我们把Activity的生命周期事件抽象成一个接口，其他的类继承该接口就可以接收到Activity的生命周期事件。

public interface ILifecycle {
    void onCreate();
    void onStart();
    void onResume();
    void onPause();
    void onStop();
    void onDestroy();
}

其次我们抽象出一个BaseActivity,用它来管理所有需要生命周期事件的对象，并分发生命周期事件。同时记录Activity的生命周期状态。 可以看到我们采用了很经典的观察者模式向生命周期对象分发Activity的生命周期事件，代码比较好看懂。

public class BaseActivity extends AppCompatActivity{

    private List lifes = new ArrayList<>();
    protected String mLifeCycle = "INIT";

    public String getmLifeCycle() {
        return mLifeCycle;
    }

    protected void addLifecycle(ILifecycle cycle){
        if(!lifes.contains(cycle)){
            lifes.add(cycle);
        }
    }

    protected void removeLifecycle(ILifecycle cycle){
        if(lifes.contains(cycle)){
            lifes.remove(cycle);
        }
    }

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        for(ILifecycle cycle:lifes){
            cycle.onCreate();
        }
        mLifeCycle = "CREATE";
    }

    @Override
    protected void onStart() {
        super.onStart();
        for(ILifecycle cycle:lifes){
            cycle.onStart();
        }
        mLifeCycle = "START";
    }

    @Override
    protected void onResume() {
        super.onResume();
        for(ILifecycle cycle:lifes){
            cycle.onResume();
        }
        mLifeCycle = "RESUME";
    }

    @Override
    protected void onPause() {
        super.onPause();
        for(ILifecycle cycle:lifes){
            cycle.onPause();
        }
        mLifeCycle = "PAUSE";
    }

    @Override
    protected void onStop() {
        super.onStop();
        for(ILifecycle cycle:lifes){
            cycle.onStop();
        }
        mLifeCycle = "STOP";
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        for(ILifecycle cycle:lifes){
            cycle.onDestroy();
        }
        mLifeCycle = "DESTROY";
    }
}

最后，让我们的Present实现ILifecycle接口，MainActivity继承自BaseActivity基类，并在onCreate方法中将Prenset加入观察，即完成了Present对象对生命周期事件的监听。

public class Present implements ILifecycle{
}

public class MainActivity extends BaseActivity {
    private Present present = new Present();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        addLifecycle(present);
        super.onCreate(savedInstanceState);
    }
}

Lifecycle的例子

说了这么多，终于到了我们今天的主角，我们先直接来看看，使用Lifecycle的话，我们之前的例子要怎么写。首先，我们实现LifecycleObserver接口，使用注解标明我们需要的生命周期事件，这里我们选择接受onCreate事件，当Activity的onCreate被调用时，我们的Present的onCreate也会被调用。

public class Present implements LifecycleObserver{
    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    void onCreate(){
    }
}

然后，我们继承自AppCompatActivity,并在onCreate中完成注册即可，是不是超级简单。

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        getLifecycle().addObserver(new Present());
    }
}

Lifecycle生命周期

lifecycle使用了2个枚举来跟踪它所关联的组件的生命周期

–Event 事件

从组件或者Lifecycle类分发出来的生命周期，它们和Activity／Fragment生命周期的事件一一对应。(ON_CREATE,ON_START,ON_RESUME,ON_PAUSE,ON_STOP,ON_DESTROY)

–State 状态

当前组件的生命周期状态(INITIALIZED,DESTROYED,CREATED,STARTED,RESUMED)

它们的转换关系见下面的官方说明

Lifecycle主要类

Lifecycle的实现不算复杂，主要的类如下图所示

可以看到，主要有3大核心模块。LifecycleObserver及其子类为被观察者，负责接收生命周期事件，我们自定义的接收器就需要继承自LifecycleObserver接口；Lifecycle为被被观察者，负责从Activity,fragment接收生命周期事件，并分发到观察者中；LifecycleOwner的职责很简单，仅仅是提供了Lifecycle对象，我们使用的Support包下的Fragment和AppCompatActivity都实现了该接口。

LifecycleObserver

我们的Present对象实现了LifecycleObserver接口，只有实现该接口的对象才能够收到生命周期事件，我们来看看该接口究竟是怎么回事呢？

/**
 * Marks a class as a LifecycleObserver. It does not have any methods, instead, relies on
 * {@link OnLifecycleEvent} annotated methods.
 */
public interface LifecycleObserver {
}

出乎意料的是，该接口并没有任何内容，源码注释告诉我们，需要监听哪个生命周期，使用OnLifecycleEvent注解标明即可。我们来看看OnLifecycleEvent注解的内容。

@SuppressWarnings("unused")
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface OnLifecycleEvent {
    Lifecycle.Event value();
}

可以看到，该注解是一个运行时注解，可以使用在方法体上，返回的Lifecycle.Event对象就是我们上一节提到的Event事件。那么为什么使用该注解标识的方法就会被调用呢，我们之后分析。

LifecycleOwner

LifecycleOwner是一个接口，它只有一个方法getLifecycle用于获取Lifecycle对象

public interface LifecycleOwner {
    Lifecycle getLifecycle();
}

我们来看看有哪些类实现了该接口以方便我们使用Lifecycle,可以看到，我们的support包下的Fragment直接实现了该接口，并提供了一个Lifecycle的具体实现类LifecycleRegistry。

public class Fragment implements LifecycleOwner{
    //Lifecycle的实现类LifecycleRegistry
    LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

    @Override
    public Lifecycle getLifecycle() {
        //覆盖LifecycleOwner接口的getLifecycle方法
        //并返回LifecycleRegistry
        return mLifecycleRegistry;
    }
}

继续查看我们发现support包下的SupportActivity实现了该接口，同样提供了一个LifecycleRegistry。而我们发现AppCompatActivity最终也继承自SupportActivity,因此在我们平时的开发中，只要继承自Support包的Fragment和AppCompatActivity就可以方便的使用Lifecycle,而不用额外的继承自某个特定的基类Activity或者fragment，是不是很方便。

public class SupportActivity extends Activity implements LifecycleOwner{
    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

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

Lifecycle

该类是一个抽象类，扮演了一个被观察者的角色，从Activity/fragment中接收事件，并分发到观察者LifecycleObserver,我们来看具体代码。

public abstract class Lifecycle {
    //添加观察者
    public abstract void addObserver(LifecycleObserver observer);
    //移除观察者
    public abstract void removeObserver(LifecycleObserver observer);
    //获取当前的State
    public abstract State getCurrentState();
    //Lifecycle生命周期的Event事件
    public enum Event {
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY
    }
    //Lifecycle生命周期的State状态
    public enum State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;
    }
}

该类是一个抽象类，其中的addObserver,removeObserver方法是观察者模式当中典型的添加，删除观察者方法。而其内部类Event和State就是我们之前说过的Lifecycle的Event事件和State状态。

LifecycleRegistry

该类为Lifecycle的实现类，添加，移除观察者，以及分发生命周期事件到LifecycleObserver中都是由该类实现的，我们之后会进行重点分析。

Lifecycle流程分析

我们从以下几个方面来分析Lifecycle的工作过程。

1，fragment/activity生命周期事件如何通知LifecycleRegistry
2，如果添加和移除LifecycleObserver到LifecycleRegistry中？
3，LifecycleRegitstry如何通知LifecycleObserver？

Fragment通知LifecycleRegistry

public class Fragment implements LifecycleOwner{
    //创建LifecycleRegistry对象，该对象就是LifecycleOwner的实现类。
    LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

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

     void performCreate(Bundle savedInstanceState) {
        //...无关代码
        //先执行onCreate
        onCreate(savedInstanceState);
        //分发ON_CREATE这个Event给LifecycleRegistry
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
    }

     void performDestroy() {
        //...无关代码
        //先分发ON_DESTROY事件
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);
        //后执行onDestroy方法
        onDestroy();
    }
    //省略onStart,onResume,onPause,onStop等事件的分发，和上面一致。
}

可以看到，Fragment生命周期通知Lifecycle的过程非常直接，fragment中创建了LifecycleRegistry对象，在fragment的生命周期中直接调用了LifecycleRegistry的handleLifecycleEvent方法，这样就将生命周期通知到了Lifecycle。

Activity通知LifecycleRegistry

看完上面Fragment生命周期分发的过程，大家可能觉得Activity的过程都不用看了吧，毕竟照着上面来一遍，生命周期事件也就分发出去了，如果你是这么想的，那可就错了，我们来看代码。

public class SupportActivity extends Activity implements LifecycleOwner {

    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

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

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //在本Activity添加一个ReportFragment，使用该Fragment来跟踪
        //Activity的生命周期
        ReportFragment.injectIfNeededIn(this);
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        //将Lifecycle的状态修改为CREATE
        mLifecycleRegistry.markState(Lifecycle.State.CREATED);
        super.onSaveInstanceState(outState);
    }
}

可以看到，google竟然不按套路出牌，虽然创建了LifecycleRegistry,但是在Activity的生命周期方法中使用它传递事件，那么生命周期事件如何创建了，答案就是onCreate中的ReportFragment，google使用它来感知Activity的生命周期，并传递生命周期事件到Lifecycle中，我们来看看ReportFragment吧。

ReportFragment传递生命周期事件

public class ReportFragment extends Fragment {
    private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
            + ".LifecycleDispatcher.report_fragment_tag";

    public static void injectIfNeededIn(Activity activity) {
        FragmentManager manager = activity.getFragmentManager();
        //创建自身并添加到宿主Activity中
        if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
            manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
            manager.executePendingTransactions();
        }
    }

    static ReportFragment get(Activity activity) {
        //获取自身的实例
        return (ReportFragment) activity.getFragmentManager().findFragmentByTag(
                REPORT_FRAGMENT_TAG);
    }

    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
        //分发ON_CREATE事件
        dispatch(Lifecycle.Event.ON_CREATE);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        //分发ON_DESTROY事件
        dispatch(Lifecycle.Event.ON_DESTROY);
    }
    //...其他生命周期事件的分发省略

    private void dispatch(Lifecycle.Event event) {
        Activity activity = getActivity();
        //如果宿主Activity继承了LifecycleOwner，则分发生命周期事件
        if (activity instanceof LifecycleOwner) {
            Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
            if (lifecycle instanceof LifecycleRegistry) {
                ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
            }
        }
    }
}

可以看到，我们在Activity的onCreate方法中，将ReportFragment添加进来，之后该Fragment就具有了和宿主Activity一样的生命周期，我们在ReportFragment的生命周期中分发事件到Lifecycle中即可。

那么问题就来了，我们直接在SupportActivity的生命周期方法中，向lifecycle传递事件一样可以达到目的啊，为啥还搞出了一个ReportFragment，感觉很多余啊，google为何要这么做呢？个人推测这个问题的原因和Lifecycle的历史实现有关，我们之后再解释。

将LifecycleObserver添加到Lifecycle中

前面我们介绍了，Lifecycle是基于观察者模式工作的，那么我们是什么时候将观察者注册到Lifecycle中的呢？没错，就是通过下面这个简单的语句，我们就注册了观察者。

 getLifecycle().addObserver(new Present());

通过前面的分析，我们知道，getLifecycle方法获取到的为LifecycleRegistry的实例，我们先来看看LifecycleRegistry中2个很重要的成员变量。

public class LifecycleRegistry extends Lifecycle{
     //Lifecycle自定义的数据结构，我们可以看成HashMap,支持遍历时添加，删除元素。
     private FastSafeIterableMap mObserverMap =
            new FastSafeIterableMap<>();
     //当前的生命周期状态
     private State mState;
}

我们来梳理一下，首先在LifecycleRegistry类中，会使用一个类似LinkedHashMap的结构来保存所有的被观察者，已确保生命周期发生变化时，能够通知LifecycleObserver。
这里有一个注释说明，说的是我们如果按照ob1,ob2的顺序添加了观察者，那么ob1的状态将会大于或等于ob2的状态,这个会有什么影响呢？影响就是启动时，ob1的ON_CREATE,ON_START,ON_RESUME事件会先于Ob2。而停止时，ob2的ON_PAUSE,ON_STOP事件先于ob1。
它的键是我们的观察者LifecycleObserver对象，值是ObserverWithState对象，这个对象其实只是一个简单的对Observer和State的封装，我们看一下他的实现。

static class ObserverWithState {
    //保存当前Observer的状态
    State mState;
    //源Observer的包装类
    GenericLifecycleObserver mLifecycleObserver;

    ObserverWithState(LifecycleObserver observer, State initialState) {
        //生成一个原Observer的包装类
        mLifecycleObserver = Lifecycling.getCallback(observer);
        mState = initialState;
    }
    //该方法将生命周期事件分发到LifecycleObserver中
    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = getStateAfter(event);
        mState = min(mState, newState);
        //调用包装类的onStateChanged方法，传递生命周期事件到Observer中
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

原来ObserverWithState类的实现很简单，主要就是保存了当前Observer类的状态State,并且使用Lifecycling类的getCallback方法返回了一个LifecycleObserver的真正实现类，该实现类就是之前类图中的ReflectiveGenericLifecycleObserver。

该类的实现原理我们大致说一下，在创建的时候，使用反射扫描我们传入的Observer对象中包含了OnLifecycleEvent注解的方法,将扫描到的方法缓存下来，并在调用GenericLifecycleObserver类的onStateChanged方法时，找到真正的生命周期回调方法并调用。详细代码我们这里就不分析了。

我们继续看关键的addObserver方法

@Override
public void addObserver(LifecycleObserver observer) {
//计算初始状态，如果当前Lifecycle状态不为DESTROYED，我们就设置为初始状态
  State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
  ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
//如果Map中存在observer这个key，我们返回它原来对应的值，否则将该键值对加入map
  ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
//一个observer不能多次加入到同一个Lifecycle中，因此我们这里判断如果它已经加入
//过了，则直接返回，不进行处理。
  if (previous != null) {
      return;
  }
//判断该添加是否可重入，这里和多线程添加Observer有关，正常情况下，我们在主线程中
//添加Observer，该标志永远为false
  boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
//计算当前Lifecycle的状态
  State targetState = calculateTargetState(observer);
  mAddingObserverCounter++;
//如果我们新添加的观察者的状态小于当前状态，则我们将它迁移到当前状态
//例如当前状态为RESUMED,则Observer将收到ONCREATE ONSTART ONRESUME事件
  while ((statefulObserver.mState.compareTo(targetState) < 0
          && mObserverMap.contains(observer))) {
      //调用ObserverWithState对象的dispatchEvent方法，向真正的Observer发送生命周期事件
      statefulObserver.dispatchEvent(mLifecycleOwner, upEvent(statefulObserver.mState));
      //重新计算当前状态
      targetState = calculateTargetState(observer);
  }
  //该方法我们之后分析
  if (!isReentrance) {
      sync();
  }
  mAddingObserverCounter--;
}

可以看到，该方法大体分为4个步骤，详细流程图如下：

1,计算Observer的初始状态，并创建包装类ObserverWithState。
2,如果全局Map中已经存在该Observer了，直接返回，如果不存在，则加入map中。
3,将Observer的当前状态和Lifecycle的状态进行比较，如果Lifecycle的状态较大，则循环迁徙Observer的状态为和Lifecycle的状态一致。
4,调用sync方法同步所有的Observer对象的生命周期状态，该方法我们之后会进行详细分析

针对第三点举个例子，例如我们在Activity的onResume中添加Observer,则由于Lifecycle的状态为RESUMED,而我们添加的Observer的状态为INIT,那么Observer的状态将依次变为CREATED,STARTED,RESUMED.并受到ON_CREATE ONSTART ONRESUME事件。

LifecycleRegistry分发生命周期事件到LifecycleObserver中

之前我们已经了解到Activity,Fragment通过LifecycleRegistry类的handleLifecycleEvent方法将生命周期事件传递到Lifecycle中，我们接下来就分析该方法，看看Lifecycle怎样将该事件分发到所有的观察者Observer中。

 public void handleLifecycleEvent(Lifecycle.Event event) {
    //1，根据当前事件，获取该事件发生后的状态
    mState = getStateAfter(event);
    //2,这个判断个人理解只有多线程下执行本方法或者addObserver
    //方法才会发生。由于我们基本不会这么用，所以可以跳过。
    if (mHandlingEvent || mAddingObserverCounter != 0) {
        mNewEventOccurred = true;
        // we will figure out what to do on upper level.
        return;
    }
    mHandlingEvent = true;
    //3,执行关键的同步sync方法
    sync();
    mHandlingEvent = false;
}

该方法的实现比较简单，第一步就是根据当前收到的生命周期事件，判断我们之后应处于的状态，我们来看一下getStateAfter的源代码

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);
}

该方法的实现比较简单，对照之前的事件状态转换图，可谓一目了然。

我们回到handleLifecycleEvent方法，该方法的第二步是判断mHandlingEvent 为真或者mAddingObserverCounter不为0，就返回，不执行之后的操作。这2个判断个人理解是为了在addObserver和本方法可能执行在其他线程服务的，因为如果大家都执行在主线程的话，这些判断根本就不会起作用，由于handleLifecycleEvent方法在前面的实现中，一定执行在主线程，所以只有addObserver方法执行在子线程时，这个判断才会起作用。我们暂时忽略这种情况，继续分析。

sync方法

该方法的第三步执行了sync方法，同步所有的观察者状态，我们来分析sync方法。

private void sync() {
    //判断是否同步完成，如果未完成，则同步直到完成为止。
    while (!isSynced()) {
        mNewEventOccurred = false;
        //之前我们说过，排在全局map第一位的状态是最大的，如果我们当前lifecycle
        //状态比它小，那么我们需要回退某些Observer的状态到mState
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
            backwardPass();
        }
        Entry newest = mObserverMap.newest();
        //之前我们说过，排在全局map最后的状态是最小的，如果我们当前lifecycle
        //状态比它大，那么我们需要前进某些Observer的状态到mState
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            forwardPass();
        }
    }
    mNewEventOccurred = false;
}

可以看到，sync方法也分为3步
1，如果有Observer处于未同步状态，则继续同步，否则直接返回。
2，使用当前Lifecycle的State和所有Observer中State最大的比较，如果mState较小，说明我们需要递减状态，执行backwardPass方法。例如状态从RESUMED递减到STARTED,事件为ON_PAUSE。
3，使用当前Lifecycle的State和所有Observer中State最小的比较，如果mState较大，说明我们要递增状态，执行forwardPass方法。例如状态从CREATED递增到STARTED,事件为ON_START。

下面我们看一下isSynced方法，可以看到，实现非常简单，去除所有Observer中的最大状态，最小状态，并和Lifecycle的状态进行比较。也就是所有Observer的状态都已经被同步为了Lifecycle的状态，才算同步完成。

private boolean isSynced() {
    if (mObserverMap.size() == 0) {
        return true;
    }
    //获取所有Observer中的最大状态
    State eldestObserverState = mObserverMap.eldest().getValue().mState;
    //获取所有Observer中的最小状态
    State newestObserverState = mObserverMap.newest().getValue().mState;
    //判断Observer中的所有状态都和当前Lifecycle的状态一致了，则说明我们已经同步完成
    return eldestObserverState == newestObserverState && mState == newestObserverState;
}

下面我们在来看一下递增状态的forwardPass方法，该方法首先获取一个按添加Observer顺序的迭代器，然后遍历所有的Observer,对每一个Observer，递增其状态并通过dispatchEvent分发生命周期事件，直到其状态递增到Lifecycle的mState为止。这样既完成了所有Observer的状态同步和事件分发。

private void forwardPass() {
    //获取一个按添加Observer顺序的迭代器
    Iterator> ascendingIterator =
            mObserverMap.iteratorWithAdditions();
    //遍历所有Observer
    while (ascendingIterator.hasNext() && !mNewEventOccurred) {
        Entry entry = ascendingIterator.next();
        ObserverWithState observer = entry.getValue();
        //如果当前Observer的State小于mState,则递增递增当前状态
        while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            pushParentState(observer.mState);
            //使用我们之前介绍的ObserverWithState类的dispatchEvent方法分发生命周期事件
            //该事件最终会分发到我们的Observer的注解方法中
            observer.dispatchEvent(mLifecycleOwner, upEvent(observer.mState));
            popParentState();
        }
    }
}

至于backwardPass方法，和上面很类似，仅仅是把状态递增改为了递减，这里就不分析了。

到这里，我们就基本分析完了Lifecycle的流程和实现原理，下面我们用一张时序图来作为总结。注意我们只画了addObserver和ON_CREATE事件的传递过程，其他生命周期事件的传递与此类似，就不画了。

Lifecycle设计思路借鉴

分析完了Lifecycle的使用，流程和代码，我们可以思考一下它的设计思路是否能对我们有所借鉴，毕竟对于很多库和框架，我们未必会直接使用到我们自己的项目中，但是阅读了它的设计思路和源码后，想想我们平时的代码设计和实现中有什么可以借鉴的闪光点，如果能把这些设计思路用到我们自己的项目中，也是不错的。我个人以为Lifecycle有以下几个值得借鉴的地方。
1，ReportFragment的使用，Fragment是我们平时常用的ui组件，我们一般用它来组织界面显示，达到复用的目的。而Lifecycle向我们展示了Fragment的另外一种用法，即完全不用来展示界面，而仅仅是嵌入到宿主Activity中，用来传递生命周期。这就告诉我们，fragment可以做的事情不仅仅是展示界面，如果我们想象力丰富一下，它还可以做更多的事情，例如这里的监听Activity生命周期,以及之后要介绍的AAC组件ViewModel中的作为数据容器。
2，注解和反射的使用，我们其实可以在LifecycleObserver接口中定义7个生命周期方法on_create,on_start等，让其他类来实现这些接口，达到不使用注解和反射的目的，但是这样就需要我们覆盖所有的方法，哪怕我们并不需要某些生命周期事件，而Lifecycle为了使用的灵活性。采用了运行时注解和反射的方式，大家都知道，反射对性能是有一定消耗的，所以Lifecycle中对于注解方法采用了一次查找，之后缓存的方式，来应该该问题。大家在使用反射和运行时注解时也可以借鉴。