Jetpack之Lifecycle

Lifecycle是谷歌推出用來幫助開發(fā)者管理Activity和Fragment等的生命周期的，避免開發(fā)者在各個生命周期中寫大量重復(fù)性類似的代碼邏輯，同時使得我們的監(jiān)聽者與Activity或Fragment解耦。

1.簡述

Lifecycle整套邏輯與觀察者模式類似，由LifecycleOwner觸發(fā)事件，即它是事件源，而我們自己寫的觀察者則接收這些事件并處理。為了規(guī)范使用，我們的觀察者必然遵循一定的規(guī)則（接口）。

觀察者模式.png

2.使用

在Lifecycle中，需要我們創(chuàng)建Observer（實現(xiàn)LifecycleObserver接口，該接口是個空接口，可以理解為一種標(biāo)記），用于監(jiān)聽聲明周期狀態(tài)，同時使用注解的方式，來指明各個生命周期觸發(fā)時對應(yīng)的調(diào)用方法。例如

public class ActivityLifecycleObserver implements LifecycleObserver {
    private static final String TAG = "ActivityObserver";

    // 當(dāng)activity調(diào)用了onResume方法時，會回調(diào)到這個方法
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    public void onHostResume(){
        Log.e(TAG, "host invoke resume, thread: " + Thread.currentThread().getName());
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    public void onHostDestroy(){
        Log.e(TAG, "host invoke destroy");
    }
}

注意到我們的回調(diào)方法中打印的日志，結(jié)果如下：

E/ActivityObserver: host invoke resume, thread: main

也就是說生命周期觀察者是運(yùn)行在主線程中的，因此我們要避免在方法內(nèi)部做耗時操作處理。

2.1 簡單使用

在新版本中AppCompatActivity的父類ComponentActivity已經(jīng)實現(xiàn)了LifecycleOwner接口，因此我們只需要在其中注冊我們的Observer即可。

public class MainActivity extends AppCompatActivity {

    private ActivityLifecycleObserver mObserver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // 注冊觀察者
        mObserver = new ActivityLifecycleObserver();
        getLifecycle().addObserver(mObserver);
    }

    @Override
    protected void onResume() {
        super.onResume();
    }

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

這樣我們的Observer就可以監(jiān)聽到Activity的生命周期的變化了。可以發(fā)現(xiàn)我們不需要在onResume或者onDestroy方法中寫任何邏輯，就可以完成監(jiān)聽操作了，這樣避免了傳統(tǒng)方式會在這些生命周期方法中存在大量重復(fù)性的邏輯。

2.2 自定義LifecycleOwner

我們創(chuàng)建一個自己的Observable并實現(xiàn)LifecycleOwner，在內(nèi)部我們維護(hù)一套類似Activity生命周期的方法，如下

public class Observable implements LifecycleOwner {
    private LifecycleRegistry mLifecycleRegistry;

    public Observable() {
        mLifecycleRegistry = new LifecycleRegistry(this);//1
        getLifecycle().addObserver(new ActivityLifecycleObserver());//2
    }

    public void onCreate(){
        mLifecycleRegistry.setCurrentState(Lifecycle.State.CREATED);//3
    }

    public void onResume(){
        mLifecycleRegistry.setCurrentState(Lifecycle.State.RESUMED);
    }

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

在1處創(chuàng)建LifecycleRegistry，用于協(xié)助我們Observable來發(fā)送事件，并在getLifecycle方法中返回它。在2處添加我們之前定義的Observer（注意：我們應(yīng)該在使用這個新的LifecycleOwner實例時把舊的實例中添加的觀察者移除，避免出現(xiàn)多個被觀察者同時持有一個觀察者的情況，具體可以通過getLifecycle().removeObserver(mObserver)來移除），在3處發(fā)送事件，這樣就模擬了類似Activity的操作了。

2.3 Lifecycle有什么優(yōu)勢呢

在上面分析中，知道在activity的生命周期中，我們不需要再進(jìn)行寫一些列重復(fù)性的代碼，下面具體對比一下兩種不同方式的效果。（示例來源于谷歌官方文檔）
具體以定位功能為例，在傳統(tǒng)方式中，我們在activity中的大致邏輯如下：

class MyActivity extends AppCompatActivity {
    private MyLocationListener myLocationListener;

    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, location -> {
            // update UI
        });
    }

    @Override
    public void onStart() {
        super.onStart();
        Util.checkUserStatus(result -> {
            // what if this callback is invoked AFTER activity is stopped?
            if (result) {
                myLocationListener.start();
            }
        });
    }

    @Override
    public void onStop() {
        super.onStop();
        myLocationListener.stop();
    }
}

“雖然此示例看起來沒問題，但在真實的應(yīng)用中，最終會有太多管理界面和其他組件的調(diào)用，以響應(yīng)生命周期的當(dāng)前狀態(tài)。管理多個組件會在生命周期方法（如 onStart() 和 onStop()）中放置大量的代碼，這使得它們難以維護(hù)。

此外，無法保證組件會在 Activity 或 Fragment 停止之前啟動。在我們需要執(zhí)行長時間運(yùn)行的操作（如 onStart() 中的某種配置檢查）時尤其如此。這可能會導(dǎo)致出現(xiàn)一種競爭條件，在這種條件下，onStop() 方法會在 onStart() 之前結(jié)束，這使得組件留存的時間比所需的時間要長。” 這時谷歌中文官方原話。

而如果我們使用Lifecycle呢，“我們可以讓 MyLocationListener 類實現(xiàn) LifecycleObserver，然后在 onCreate() 方法中使用 Activity 的 Lifecycle 對其進(jìn)行初始化。這樣，MyLocationListener 類便可以“自給自足”，這意味著，對生命周期狀態(tài)的變化做出響應(yīng)的邏輯會在 MyLocationListener（而不是在 Activity）中進(jìn)行聲明。讓各個組件存儲自己的邏輯，可使 Activity 和 Fragment 邏輯更易于管理。”
同時，如果LifecycleOwner的生命周期并沒有處于活動狀態(tài)，那么應(yīng)該避免繼續(xù)回調(diào)操作，“例如，如果回調(diào)在 Activity 狀態(tài)保存后運(yùn)行 Fragment 事務(wù)，就會引發(fā)崩潰，因此我們絕不能調(diào)用該回調(diào)?！?所以，Lifecycle給觀察者提供了查詢LifecycleOwner的狀態(tài)信息，這樣觀察者與被觀察者之間的耦合降到最低?；具壿嬵愃迫缦拢?/p>

class MyLocationListener implements LifecycleObserver {
    private boolean enabled = false;
    public MyLocationListener(Context context, Lifecycle lifecycle, Callback callback) {
       ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void start() {
        if (enabled) {
           // connect
        }
    }

    public void enable() {
        enabled = true;
        if (lifecycle.getCurrentState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void stop() {
        // disconnect if connected
    }
}

這里舉例暫且說到這里，其實這里看出來，使用Lifecycle之后效果也有一定麻煩。而且還存在一部分類似的模板邏輯可以繼續(xù)抽象出來，例如在LifecycleOwner的生命周期處于非活動狀態(tài)時，可以停止數(shù)據(jù)加載過程（在這里是定位查詢的功能）。實際上jetpack中這些交給了LiveData和ViewModel，畢竟這與本文主題相悖，在最后總結(jié)時來看看谷歌推薦的最佳用法。

3.原理分析

通過前面的觀察者模式的UML圖，我們知道觀察者模式中被觀察者與觀察者是一種聚合的關(guān)系。那么在Observable中必然維護(hù)了一個Observer的引用列表，事件觸發(fā)時，遍歷列表并調(diào)用相關(guān)方法。下面帶著這個結(jié)論，閱讀源碼。

3.1 注冊

首先找到分析入口，注冊觀察者：

getLifecycle().addObserver(mObserver);

方法回調(diào)到Lifecycle接口中，從前文我們知道實際上調(diào)用該邏輯的是LifecycleRegistry。

@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);

LifecycleRegistry.java

@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);//1
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);//2

    if (previous != null) {
        return;
    }
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }

    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }

    if (!isReentrance) {
        // we do sync only on the top level.
        sync();
    }
    mAddingObserverCounter--;
}

在注釋1處創(chuàng)建了一個ObserverWithState對象，并傳入了LifecycleObserver對象，在注釋2處調(diào)用了mObserverMap.putIfAbsent方法，mObserverMap是一個以LifecycleObserver為key、FastSafeIterableMap類型的數(shù)據(jù)結(jié)構(gòu)，內(nèi)部維護(hù)了一個HashMap。我們暫且不去深入了解其內(nèi)部實現(xiàn)，繼續(xù)主路線分析。
在putIfAbsent方法中邏輯如下，從方法名和邏輯都可以看出，如果元素不存在在集合中，則會調(diào)用put操作。

@Override
public V putIfAbsent(@NonNull K key, @NonNull V v) {
    Entry<K, V> current = get(key);
    if (current != null) {
        return current.mValue;
    }
    mHashMap.put(key, put(key, v));
    return null;
}

至此，一條引用鏈：Activity(或其他LifecycleOwner)--->LifecycleRegistry ----> FastSafeIterableMap（存儲ObserverWithState集合）---->LifecycleObserver。從整個邏輯來看,LifecycleRegistry實現(xiàn)了Lifecycle接口，而我們Activity實現(xiàn)了LifecycleOwner接口，并在內(nèi)部創(chuàng)建了LifecycleRegistry對象，如下ComponentActivity代碼注釋1處。

ComponentActivity.java

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
    LifecycleOwner,
    ViewModelStoreOwner,
    SavedStateRegistryOwner,
    OnBackPressedDispatcherOwner {

...
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);//1
private final SavedStateRegistryController mSavedStateRegistryController =
        SavedStateRegistryController.create(this);
...
}

這也就很好理解，為什么Activity等實現(xiàn)了接口名稱為LifecycleOwner了，其內(nèi)部持有了Lifecycle實現(xiàn)類LifecycleRegistry對象。LifecycleRegistry內(nèi)部維護(hù)了一個存儲著LifecycleObserver的集合，通過它實現(xiàn)了觀察者和被觀察者之間的聚合關(guān)系。因此上面的觀察者模式的UML圖，可以大致轉(zhuǎn)換為下面的UML類圖。

基本草圖.png

3.2 事件發(fā)送

上面觀察者與被觀察者已經(jīng)建立了聚合關(guān)系，接下來就是被觀察者發(fā)送事件并通知觀察者處理了。
前面由代碼分析，在activity的生命周期中沒有調(diào)用相關(guān)的LifecycleRegistry的setCurrentState方法，而我們在自定義的LifecycleOwner調(diào)用了這些方法，LifecycleOberver接收到了事件。因此我們直接進(jìn)入LifecycleOwner的實現(xiàn)者ComponentActivity。

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
    LifecycleOwner,
    ViewModelStoreOwner,
    SavedStateRegistryOwner,
    OnBackPressedDispatcherOwner {

    private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);//1

    private final SavedStateRegistryController mSavedStateRegistryController =
        SavedStateRegistryController.create(this);
...
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mSavedStateRegistryController.performRestore(savedInstanceState);
        ReportFragment.injectIfNeededIn(this);//2
        if (mContentLayoutId != 0) {
            setContentView(mContentLayoutId);
        }
    }
...
    @CallSuper
    @Override
    protected void onSaveInstanceState(@NonNull Bundle outState) {
        Lifecycle lifecycle = getLifecycle();
        if (lifecycle instanceof LifecycleRegistry) {
            ((LifecycleRegistry) lifecycle).setCurrentState(Lifecycle.State.CREATED);//3
        }
        super.onSaveInstanceState(outState);
        mSavedStateRegistryController.performSave(outState);
    }

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

在注釋1處創(chuàng)建了LifecycleRegistry即Lifecycle的實現(xiàn)類，并在注釋4處LifecycleOwner的getLifecycle方法中返回了上述對象。我們只在注釋3看到調(diào)用了我們之前的setCurrentState方法，而其他地方?jīng)]有調(diào)用過。其實關(guān)鍵的邏輯在注釋2處，如下
ReportFragment.java

...
public static void injectIfNeededIn(Activity activity) {
    // ProcessLifecycleOwner should always correctly work and some activities may not extend
    // FragmentActivity from support lib, so we use framework fragments for activities
    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();
    }
}
...

上述邏輯中通過activity拿到FragmentManager，并通過add方法添加了創(chuàng)建的ReportFragment對象，因為activity的生命周期和fragment生命周期之間有一定的關(guān)系，所以生命周期的變動都交給了ReportFragment來協(xié)助完成。這種依賴無頁面的Fragment來實現(xiàn)生命周期監(jiān)聽的方式，在Glide、舊版RxPermissions也是通過這種方式實現(xiàn)的。

public class ReportFragment extends Fragment {
    @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(Lifecycle.Event event) {
        Activity activity = getActivity();
        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);
            }
        }
    }
}

上述所有方法都調(diào)用了dispatch方法，在dispatch方法中判斷activity所實現(xiàn)的接口類型，通過源碼查看可以知道，LifecycleRegistryOwner接口中也有一個getLifecycle方法，而返回類型是LifecycleRegistry。通過前面代碼，在LifecycleOwner中，activity中使用的也是LifecycleRegistry，因此最終上面dispatch方法最終都是調(diào)用到了LifecycleRegistry中的handleLifecycleEvent方法。
LifecycleRegistry.java

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

private void moveToState(State next) {
    if (mState == next) {
        return;
    }
    mState = next;
    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) {
        throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already"
                + "garbage collected. It is too late to change lifecycle state.");
    }
    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;
}

在1處調(diào)用了getStateAfter方法，即根據(jù)當(dāng)前的Event類型，返回不同的CREATED等State類型，它是一種枚舉類型，表示的是狀態(tài)；而Event也是一種枚舉，表示的一種事件類型，即我們常見的onCreate事件等?？梢钥吹疆?dāng)我們調(diào)用了onCreate或onStop事件方法，將會進(jìn)入CREATED狀態(tài)...

LifecycleRegistry.java

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

這兩個枚舉State和Event之間的關(guān)系如下圖（圖片來源于google官方文檔）

Lifecycle的event與state關(guān)系.jpg

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "MainActivity";

    private ActivityLifecycleObserver mObserver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // 注冊觀察者
        mObserver = new ActivityLifecycleObserver();
        getLifecycle().addObserver(mObserver);
    }

    @Override
    protected void onStop() {
        super.onStop();
        Lifecycle.State currentState = getLifecycle().getCurrentState();
        Log.e(TAG,"onStop, current state is "+currentState);
    }

    @Override
    public void onSaveInstanceState(@NonNull Bundle outState) {
        super.onSaveInstanceState(outState);
        Lifecycle.State currentState = getLifecycle().getCurrentState();
        Log.e(TAG,"onSaveInstanceState, current state is "+currentState);
    }

    public void invokeSave(View view) { //對應(yīng)btn的onClick
        // 手動觸發(fā)onSaveInstanceState
        onSaveInstanceState(new Bundle());
    }
}

按下按鈕，輸出日志如下：

E/MainActivity: onSaveInstanceState, current state is CREATED

再退出整個activity，輸出日志如下：

E/MainActivity: onStop, current state is CREATED
E/MainActivity: onSaveInstanceState, current state is CREATED

也就是說按下按鈕時，并沒有觸發(fā)onStop方法，但狀態(tài)已經(jīng)轉(zhuǎn)變?yōu)榱薈REATED狀態(tài)，這與activity中流程不太一致。

最終調(diào)用backwardPass或forwardPass方法。這里以backwardPass方法為例，最終看到調(diào)用到了ObserverWithState的dispatchEvent方法

LifecycleRegistry.java

private void backwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
    while (descendingIterator.hasNext() && !mNewEventOccurred) {
        Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
        ObserverWithState observer = entry.getValue();
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            Event event = downEvent(observer.mState);
            pushParentState(getStateAfter(event));
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}

而ObserverWithState就是在注冊時創(chuàng)建并被put到集合中的對象。

LifecycleRegistry.java

static class ObserverWithState {
    State mState;
    LifecycleEventObserver mLifecycleObserver;

    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);//2
        mState = initialState;
    }

    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = getStateAfter(event);
        mState = min(mState, newState);
        mLifecycleObserver.onStateChanged(owner, event);//1
        mState = newState;
    }
}

在1處調(diào)用到了LifecycleEventObserver的onStateChanged方法。前面我們自定義創(chuàng)建是LifecycleObserver，而LifecycleEventObserver是什么？在注釋2處是它的創(chuàng)建點，而我們之前創(chuàng)建ObserverWithState時傳入了LifecycleObserver對象，核心進(jìn)入到注釋2處。

Lifecycling.java

@NonNull
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;
    }

    final Class<?> klass = object.getClass();
    int type = getObserverConstructorType(klass);
    if (type == GENERATED_CALLBACK) {
        List<Constructor<? extends GeneratedAdapter>> constructors =
                sClassToAdapters.get(klass);
        if (constructors.size() == 1) {
            GeneratedAdapter generatedAdapter = createGeneratedAdapter(
                    constructors.get(0), object);
            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);
}

我們前面Observer創(chuàng)建是通過注解方式完成的，所以內(nèi)部邏輯實際上調(diào)用了最后的ReflectiveGenericLifecycleObserver創(chuàng)建過程，因此最終進(jìn)入了ReflectiveGenericLifecycleObserver中。

ReflectiveGenericLifecycleObserver.java

class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
    private final Object mWrapped;
    private final CallbackInfo mInfo;

    ReflectiveGenericLifecycleObserver(Object wrapped) {
        mWrapped = wrapped;
        mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());//1
    }

    @Override
    public void onStateChanged(LifecycleOwner source, Event event) {
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}

在注釋1處內(nèi)部調(diào)用了getInfo方法來創(chuàng)建CallbackInfo。

ClassesInfoCache.java

CallbackInfo getInfo(Class klass) {
    CallbackInfo existing = mCallbackMap.get(klass);
    if (existing != null) {
        return existing;
    }
    existing = createInfo(klass, null);
    return existing;
}

private CallbackInfo createInfo(Class klass, @Nullable Method[] declaredMethods) {
    Class superclass = klass.getSuperclass();
    Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
    if (superclass != null) {
        CallbackInfo superInfo = getInfo(superclass);
        if (superInfo != null) {
            handlerToEvent.putAll(superInfo.mHandlerToEvent);
        }
    }

    Class[] interfaces = klass.getInterfaces();
    for (Class intrfc : interfaces) {
        for (Map.Entry<MethodReference, Lifecycle.Event> entry : getInfo(
                intrfc).mHandlerToEvent.entrySet()) {
            verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
        }
    }

    Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
    boolean hasLifecycleMethods = false;
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);//1
        if (annotation == null) {
            continue;
        }
        hasLifecycleMethods = true;
        Class<?>[] params = method.getParameterTypes();
        int callType = CALL_TYPE_NO_ARG;
        //2
        if (params.length > 0) {
            callType = CALL_TYPE_PROVIDER;
            if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. Must be one and instanceof LifecycleOwner");
            }
        }
        Lifecycle.Event event = annotation.value();

        if (params.length > 1) {
            callType = CALL_TYPE_PROVIDER_WITH_EVENT;
            if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. second arg must be an event");
            }
            if (event != Lifecycle.Event.ON_ANY) {
                throw new IllegalArgumentException(
                        "Second arg is supported only for ON_ANY value");
            }
        }
        if (params.length > 2) {
            throw new IllegalArgumentException("cannot have more than 2 params");
        }
        MethodReference methodReference = new MethodReference(callType, method);//3
        verifyAndPutHandler(handlerToEvent, methodReference, event, klass);//4
    }
    CallbackInfo info = new CallbackInfo(handlerToEvent);
    mCallbackMap.put(klass, info);//5
    mHasLifecycleMethods.put(klass, hasLifecycleMethods);
    return info;
}

在注釋1處看到了我們之前的OnLifecycleEvent注解，在內(nèi)部通過反射獲取到所定義的所有方法，并找到所有被OnLifecycleEvent注解的方法。在注釋2處，可以發(fā)現(xiàn)我們定義的LifecycleObserver類中生命周期的方法最多可以有兩個參數(shù)，在不同狀態(tài)下有不同的要求。在注釋3處創(chuàng)建了MethodReference類型，并在注釋4處把前面的methodReferce存入handlerToEvent（Map數(shù)據(jù)結(jié)構(gòu)類型），在注釋5處通過put方法把ClassInfo存入mCallbackMap中，該mCallbackMap是一個HashMap。
最后回到ReflectiveGenericLifecycleObserver的onStateChanged方法，如下注釋1中，并調(diào)用invokeCallbacks方法。

class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
    private final Object mWrapped;
    private final CallbackInfo mInfo;

    ReflectiveGenericLifecycleObserver(Object wrapped) {
        mWrapped = wrapped;
        mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
    }

    @Override
    public void onStateChanged(LifecycleOwner source, Event event) {
        mInfo.invokeCallbacks(source, event, mWrapped);//1
    }
}

ClassesInfoCache.java

void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
        invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);
        invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event,
                target);
    }

可以看出來，調(diào)用了invokeMethodsForEvent方法，如下，調(diào)用handlers拿到MethodReference類，并調(diào)用invokeCallback方法

private static void invokeMethodsForEvent(List<MethodReference> handlers,
            LifecycleOwner source, Lifecycle.Event event, Object mWrapped) {
    if (handlers != null) {
        for (int i = handlers.size() - 1; i >= 0; i--) {
            handlers.get(i).invokeCallback(source, event, mWrapped);
        }
    }
}

void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
        //noinspection TryWithIdenticalCatches
        try {
            switch (mCallType) {
                case CALL_TYPE_NO_ARG:
                    mMethod.invoke(target);
                    break;
                case CALL_TYPE_PROVIDER:
                    mMethod.invoke(target, source);
                    break;
                case CALL_TYPE_PROVIDER_WITH_EVENT:
                    mMethod.invoke(target, source, event);
                    break;
            }
        } catch (InvocationTargetException e) {
            throw new RuntimeException("Failed to call observer method", e.getCause());
        } catch (IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }

最終完成了方法的調(diào)用，即觀察者響應(yīng)觸發(fā)事件。

總結(jié)

1.所有實現(xiàn)了LifecycleObserver接口的類，被注解修飾的方法會被注冊時收集起來，最后事件觸發(fā)時通過反射調(diào)用。最終我總結(jié)整體UML類圖如下：

詳細(xì)類關(guān)系圖.png

2.谷歌官方文檔給出了Lifecycle使用的最佳方法，下面摘自原文。

1）使界面控制器（Activity 和 Fragment）盡可能保持精簡。它們不應(yīng)試圖獲取自己的數(shù)據(jù)，而應(yīng)使用 ViewModel 執(zhí)行此操作，并觀察 LiveData 對象以將更改體現(xiàn)到視圖中。

2）設(shè)法編寫數(shù)據(jù)驅(qū)動型界面，對于此類界面，界面控制器的責(zé)任是隨著數(shù)據(jù)更改而更新視圖，或者將用戶操作通知給 ViewModel。

3）將數(shù)據(jù)邏輯放在 ViewModel 類中。 ViewModel 應(yīng)充當(dāng)界面控制器與應(yīng)用其余部分之間的連接器。不過要注意，ViewModel 不負(fù)責(zé)獲取數(shù)據(jù)（例如，從網(wǎng)絡(luò)獲?。?。
ViewModel 應(yīng)調(diào)用相應(yīng)的組件來獲取數(shù)據(jù)，然后將結(jié)果提供給界面控制器。

4）使用 Data Binding 在視圖與界面控制器之間維持干凈的接口。這樣一來，您可以使視圖更具聲明性，并盡量減少需要在 Activity 和 Fragment 中編寫的更新代碼。如果您更愿意使用 Java 編程語言執(zhí)行此操作，請使用諸如 Butter Knife 之類的庫，以避免樣板代碼并實現(xiàn)更好的抽象化。

5）如果界面很復(fù)雜，不妨考慮創(chuàng)建 presenter 類來處理界面的修改。這可能是一項艱巨的任務(wù)，但這樣做可使界面組件更易于測試。

6）避免在 ViewModel 中引用 View 或 Activity 上下文。 如果 ViewModel 存在的時間比 Activity 更長（在配置更改的情況下），Activity 將泄露并且不會由垃圾回收器妥善處置。

7）使用 Kotlin 協(xié)程管理長時間運(yùn)行的任務(wù)和其他可以異步運(yùn)行的操作。
整體的UML結(jié)構(gòu)圖

上面內(nèi)容涉及到LiveData和ViewModel等其他知識，以及MVVM，需要我們深入繼續(xù)學(xué)習(xí)它們。

參考：
官方文檔：https://developer.android.google.cn/topic/libraries/architecture/lifecycle#java