程序员徐公

https://www.jianshu.com/p/4b7945475a6f

程序员徐公，一位不羁的码农。

前言

在上一篇博客中，我们讲解了 lifecycle 的使用及优点。这篇博客让我们一起来了解一下 LiveData 是怎样使用的？

为什么要引进 LiveData

LiveData 是一个可以被观察的数据持有类，它可以感知 Activity、Fragment或Service 等组件的生命周期。简单来说，他主要有一下优点。

它可以做到在组件处于激活状态的时候才会回调相应的方法，从而刷新相应的 UI。
不用担心发生内存泄漏
当 config 导致 activity 重新创建的时候，不需要手动取处理数据的储存和恢复。它已经帮我们封装好了。
当 Actiivty 不是处于激活状态的时候，如果你想 livedata setValue 之后立即回调 obsever 的 onChange 方法，而不是等到 Activity 处于激活状态的时候才回调 obsever 的 onChange 方法，你可以使用 observeForever 方法，但是你必须在 onDestroy 的时候 removeObserver。

回想一下，在你的项目中，是不是经常会碰到这样的问题，当网络请求结果回来的时候，你经常需要判断 Activity 或者 Fragment 是否已经 Destroy，如果不是 destroy，才更新 UI。

而当你如果使用 Livedata 的话，因为它是在 Activity 处于 onStart 或者 onResume 的状态时，他才会进行相应的回调，因而可以很好得处理这个问题，不必写一大堆的 activity.isDestroyed()。接下来，让我们一起来看一下 LiveData 的使用

LiveData 使用

基本使用

引入相关的依赖包

// ViewModel and LiveData
implementation "android.arch.lifecycle:extensions:1.1.0"
// alternatively, just ViewModel
implementation "android.arch.lifecycle:viewmodel:1.1.0"
// alternatively, just LiveData
implementation "android.arch.lifecycle:livedata:1.1.0"

在代码中使用

LiveData 是一个抽象类，它的实现子类有 MutableLiveData ，MediatorLiveData。在实际使用中，用得比较多的是 MutableLiveData。他常常结合 ViewModel 一起使用。下面，让我们一起来看一下怎样使用它？

首先，我们先写一个类继承我们的 ViewModel，里面持有 mNameEvent。

public class TestViewModel extends ViewModel {

    private MutableLiveData<String> mNameEvent = new MutableLiveData<>();

    public MutableLiveData<String> getNameEvent() {
        return mNameEvent;
    }

}

接着，我们在 Activity 中创建 ViewModel，并监听 ViewModel 里面 mNameEvent 数据的变化，当数据改变的时候，我们打印相应的 log，并设置给 textView，显示在界面上。这样我们就完成了对 mNameEvent 数据源的观察。

mTestViewModel = ViewModelProviders.of(this).get(TestViewModel.class);
MutableLiveData<String> nameEvent = mTestViewModel.getNameEvent();
nameEvent.observe(this, new Observer<String>() {
    @Override
    public void onChanged(@Nullable String s) {
        Log.i(TAG, "onChanged: s = " + s);
        mTvName.setText(s);
    }
});

最后当我们数据源改变的时候，我们需要调用 livedata 的 setValue 或者 postvalue 方法。他们之间的区别是，调用 setValue 方法，Observer 的 onChanged 方法会在调用 serValue 方法的线程回调。而
postvalue 方法，Observer 的 onChanged 方法将会在主线程回调。

1	mTestViewModel.getNameEvent().setValue(name);

可能部分同学有这样的疑问了，我们的 ViewModel 是通过 ViewModelProviders.of(this).get(TestViewModel.class); 方法创建出来的，如果我们要携带参数，怎么办？

其实，官方也替我们考虑好了，同样是调用 ViewModelProvider of(@NonNull Fragment fragment, @Nullable Factory factory) 方法，只不过，需要多传递一个 factory 参数。

Factory 是一个接口，它只有一个 create 方法。

public interface Factory {
    /**
     * Creates a new instance of the given {@code Class}.
     * <p>
     *
     * @param modelClass a {@code Class} whose instance is requested
     * @param <T>        The type parameter for the ViewModel.
     * @return a newly created ViewModel
     */
    @NonNull
    <T extends ViewModel> T create(@NonNull Class<T> modelClass);
}

在实际当中，我们的做法是：实现 Factory 接口，重写 create 方法，在create 方法里面调用相应的构造函数，返回相应的实例。

public class TestViewModel extends ViewModel {

    private final String mKey;
    private MutableLiveData<String> mNameEvent = new MutableLiveData<>();

    public MutableLiveData<String> getNameEvent() {
        return mNameEvent;
    }

    public TestViewModel(String key) {
        mKey = key;
    }

    public static class Factory implements ViewModelProvider.Factory {
        private String mKey;

        public Factory(String key) {
            mKey = key;
        }

        @Override
        public <T extends ViewModel> T create(Class<T> modelClass) {
            return (T) new TestViewModel(mKey);
        }
    }

    public String getKey() {
        return mKey;
    }
}

ViewModelProviders.of(this, new TestViewModel.Factory(mkey)).get(TestViewModel.class)

自定义 Livedata

Livedata 主要有几个方法

observe
onActive
onInactive
observeForever

void observe (LifecycleOwner owner, Observer observer)

Adds the given observer to the observers list within the lifespan of the given owner. The events are dispatched on the main thread. If LiveData already has data set, it will be delivered to the observer.

void onActive ()

Called when the number of active observers change to 1 from 0.
This callback can be used to know that this LiveData is being used thus should be kept up to date.

当回调该方法的时候，表示该 liveData 正在背使用，因此应该保持最新

void onInactive ()

Called when the number of active observers change from 1 to 0.
This does not mean that there are no observers left, there may still be observers but their lifecycle states aren’t STARTED or RESUMED (like an Activity in the back stack).
You can check if there are observers via hasObservers().

当该方法回调时，表示他所有的 obervers 没有一个状态处理 STARTED 或者 RESUMED，注意，这不代表没有 observers。

Void observeForever

跟 observe 方法不太一样的是，它在 Activity 处于 onPause ，onStop， onDestroy 的时候，都可以回调 obsever 的 onChange 方法，但是有一点需要注意的是，我们必须手动 remove obsever，否则会发生内存泄漏。

这里我们以观察网络状态变化为例子讲解

首先我们自定义一个 Class NetworkLiveData，继承 LiveData，重写它的 onActive 方法和 onInactive 方法
在 onActive 方法中，我们注册监听网络变化的广播，即ConnectivityManager.CONNECTIVITY_ACTION。在 onInactive 方法的时候，我们注销广播。

public class NetworkLiveData extends LiveData<NetworkInfo> {

    private final Context mContext;
    static NetworkLiveData mNetworkLiveData;
    private NetworkReceiver mNetworkReceiver;
    private final IntentFilter mIntentFilter;

    private static final String TAG = "NetworkLiveData";

    public NetworkLiveData(Context context) {
        mContext = context.getApplicationContext();
        mNetworkReceiver = new NetworkReceiver();
        mIntentFilter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
    }

    public static NetworkLiveData getInstance(Context context) {
        if (mNetworkLiveData == null) {
            mNetworkLiveData = new NetworkLiveData(context);
        }
        return mNetworkLiveData;
    }

    @Override
    protected void onActive() {
        super.onActive();
        Log.d(TAG, "onActive:");
        mContext.registerReceiver(mNetworkReceiver, mIntentFilter);
    }

    @Override
    protected void onInactive() {
        super.onInactive();
        Log.d(TAG, "onInactive: ");
        mContext.unregisterReceiver(mNetworkReceiver);
    }

    private static class NetworkReceiver extends BroadcastReceiver {

        @Override
        public void onReceive(Context context, Intent intent) {
            ConnectivityManager manager = (ConnectivityManager) context
                    .getSystemService(Context.CONNECTIVITY_SERVICE);
            NetworkInfo activeNetwork = manager.getActiveNetworkInfo();
            getInstance(context).setValue(activeNetwork);

        }
    }
}

这样，当我们想监听网络变化的时候，我们只需要调用相应的 observe 方法即可，方便又快捷。

NetworkLiveData.getInstance(this).observe(this, new Observer<NetworkInfo>() {
    @Override
    public void onChanged(@Nullable NetworkInfo networkInfo) {
        Log.d(TAG, "onChanged: networkInfo=" +networkInfo);
    }
});

共享数据

Fragment Activity 之间共享数据

我们回过头来再来看一下 ViewModelProvider 的 of 方法，他主要有四个方法，分别是

ViewModelProvider of(@NonNull Fragment fragment)
ViewModelProvider of(@NonNull FragmentActivity activity)
ViewModelProvider of(@NonNull Fragment fragment, @Nullable Factory factory)
ViewModelProvider of(@NonNull FragmentActivity activity, @Nullable Factory factory)

1,2 方法之间的主要区别是传入 Fragment 或者 FragmentActivity。而我们知道，通过 ViewModel of 方法创建的 ViewModel 实例，对于同一个 fragment 或者 fragmentActivity 实例，ViewModel 实例是相同的，因而我们可以利用该特点，在 Fragment 中创建 ViewModel 的时候，传入的是 Fragment 所依附的 Activity。因而他们的 ViewModel 实例是相同的，从而可以做到共享数据。


// LiveDataSampleActivity(TestFragment 依赖的 Activity）
mTestViewModel = ViewModelProviders.of(this, new TestViewModel.Factory(mkey)).get(TestViewModel.class);
MutableLiveData<String> nameEvent = mTestViewModel.getNameEvent();
nameEvent.observe(this, new Observer<String>() {
    @Override
    public void onChanged(@Nullable String s) {
        Log.i(TAG, "onChanged: s = " + s);
        mTvName.setText(s);
    }
});


// TestFragment 中
mViewModel = ViewModelProviders.of(mActivity).get(TestViewModel.class);
mViewModel.getNameEvent().observe(this, new Observer<String>() {
    @Override
    public void onChanged(@Nullable String s) {
        Log.d(TAG, "onChanged: s =" + s + " mViewModel.getKey() =" + mViewModel.getKey());
        mTvName.setText(s);
        boolean result = mViewModel == ((LiveDataSampleActivity) mListener).mTestViewModel;
        Log.d(TAG, "onChanged: s result =" + result);
    }
});

这样，LiveDataSampleActivity 和 TestFragment 中的 ViewModel 是同一个实例。即 Activity 和 Fragment 共享数据。

全局共享数据

说到全局共享数据，我们想一下我们的应用全景，比如说我的账户数据，这个对于整个 App 来说，肯定是全局共享的。有时候，当我们的数据变化的时候，我们需要通知我们相应的界面，刷新 UI。如果用传统的方式来实现，那么我们一般才采取观察者的方式来实现，这样，当我们需要观察数据的时候，我们需要添加 observer，在界面销毁的时候，我们需要移除 observer。

但是，如果我们用 LiveData 来实现的话，它内部逻辑都帮我们封装好了，我们只需要保证 AccountLiveData 是单例的就ok，在需要观察的地方调用 observer 方法即可。也不需要手动移除 observer，不会发生内存泄漏，方便快捷。

这里 AccountLiveData 的实现就不贴出来了，可以参考上面的 NetworkLiveData 实现

小结

这里说一点关于 LiveData 与 ViewModel 的应用场景，我尽量说得通俗一点，不要说得那么官方，这样对新手很难理解。

觉得不错的，请点个赞，让我们看到你们的欢呼声。你们的支持就是我写作的最大动力。

LiveData 内部已经实现了观察者模式，如果你的数据要同时通知几个界面，可以采取这种方式
我们知道 LiveData 数据变化的时候，会回调 Observer 的 onChange 方法，但是回调的前提是 lifecycleOwner（即所依附的 Activity 或者 Fragment）处于 started 或者 resumed 状态，它才会回调，否则，必须等到 lifecycleOwner 切换到前台的时候，才回调。
因此，这对性能方面确实是一个不小的提升。但是，对于你想做一些类似与在后台工作的（黑科技）， liveData 就不太适合了，你可以使用 observeForever 方法，或者自己实现观察者模式去吧。

Lifecycle，LiveData， ViewModel 的基本使用到此已经讲解完毕，想了解他们的实现原理的话可以阅读这两篇文章。

Android lifecyle 源码解剖

发表于 2019-01-12 更新于 2023-02-28
本文字数： 19k 阅读时长 ≈ 17 分钟

说在前面

Android lifecycle 使用详解

Android LiveData 使用详解

徐公码字，一位不羁的码农。

前言

前两篇博客，我们已经讲解了 lifecycle ，liveData， ViewModel 的使用，这一篇博客，让我们一起来看一下 lifecycle 的原理。

从自定义的 lifecycle 说起

首先我们先来复习一下，如果要自定义 lifecycle，我们要这样做。

public class CustomLifecycleActivity extends FragmentActivity implements LifecycleOwner {

    private LifecycleRegistry mLifecycleRegistry;

    private static final String TAG = "CustomLifecycleActivity";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_custom_lifecycle);
        mLifecycleRegistry = new LifecycleRegistry(this);
        mLifecycleRegistry.markState(Lifecycle.State.CREATED);
        getLifecycle().addObserver(new GenericLifecycleObserver() {
            @Override
            public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
                Log.d(TAG, "onStateChanged: event = " + event);
            }
        });

    }
	
	    @Override
    protected void onStart() {
        super.onStart();
        mLifecycleRegistry.markState(Lifecycle.State.STARTED);
    }

    @Override
    protected void onResume() {
        super.onResume();
        mLifecycleRegistry.markState(Lifecycle.State.RESUMED);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mLifecycleRegistry.markState(Lifecycle.State.DESTROYED);
    }

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

第一步:先实现 LifecycleOwner 接口，并返回 mLifecycleRegistry
第二步：在 Activity 生命周期变化的时候，调用 mLifecycleRegistry.markState() 方法标记相应的状态
如果想添加 observer，调用 addObserver 方法添加观察者，这样会在 activity 生命周期变化的时候，回调 observer 的 onchange 方法。

我们先来看一下 getLifecycle() 方法， getLifecycle() 它返回的是一个 Lifecycle 的实例，sdk 中默认的实现类为 LifecycleRegistry。

接下来，我们一起来看一下它的 observer 方法。

public void addObserver(@NonNull LifecycleObserver observer) {
  // 判断是否是 DESTROYED，如果是将初始状态置为 DESTROYED，否则为 INITIALIZED
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
 // ObserverWithState 包装
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
	//  将 observer 作为key，在缓存的 mObserverMap 中查找是否存在
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
  
   // 存在，直接返回回去，证明该 observer 已经添加过了。否则，证明还没有添加过该 observer
    if (previous != null) {
        return;
    }
	 
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }

    // 这里 mAddingObserverCounter 为 0 ，mHandlingEvent 为 false
    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--;
}

在 addObserver 方法中，它主要干这几件事情

首先，先初始化状态，判断当前 mState 是否是 DESTROYED，如果是将初始状态置为 DESTROYED，否则为 INITIALIZED，接着用 ObserverWithState 包装 observer 和初始化状态 initialState
将 observer 作为 key，在缓存的 mObserverMap 中查找是否存在，如果存在，证明该 observer 已经添加过，直接返回回去，不必再进行处理。
addObserver 方法中第 21 行， isReentrance 一般情况下为 false，什么情况为 true，暂时未想到，

接下来我们先来看 calculateTargetState 方法。

private State calculateTargetState(LifecycleObserver observer) {
   // 取出 mObserverMap 的上一个 entry，previous
    Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);

   // 如果不为空，获取它的状态
    State siblingState = previous != null ? previous.getValue().mState : null;
	// 判断 mParentStates 是否为 null，不为 null，去最后的一个状态，否则，为 null
    State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
            : null;
    // 取最小的状态
    return min(min(mState, siblingState), parentState);
}

首先，取出 mObserverMap 中上一个的 entry，该 LifecycleRegistry 实例如果是第一次调用 addObserver 实例的话，那么是 null，否则是上一个 observer 的 entry
根据 previous 是否为 null，设置 siblingState 的值
判断 mParentStates 是否为 null，不为 null，取 mParentStates 最后一次的状态
取 mState, siblingState 最小的状态 a，再取 a 与 parentState 的状态 b

public enum State {
   
    DESTROYED,

    INITIALIZED,

    CREATED,

    STARTED,

    RESUMED;

    public boolean isAtLeast(@NonNull State state) {
        return compareTo(state) >= 0;
    }
}

State 中，他们排序的顺序是 DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED。

我们知道，我们在 activity 的 onCreate 方法中初始化 LifecycleRegistry，并标记它的状态为 CREATED。当我们第一次在 onCreate 方法调用 addObserver 的时候，在 calculateTargetState 方法中，若是首次调用 previous 为 null，则 siblingState，parentState 为 null，而 mState 为 CREATED，所以最终的状态为 CREATED，即 State targetState = calculateTargetState(observer); 中 targetState 为 CREATED

1 2	// 取最小的状态 return min(min(mState, siblingState), parentState);

看完 calculateTargetState 方法，我们回过头再来看一下 addObserver 方法。

public void addObserver(@NonNull LifecycleObserver observer) {
  
  
     // 省略若干行

    // 这里 mAddingObserverCounter 为 0 ，mHandlingEvent 为 false
    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--;
}

这里 statefulObserver.mState 为 DESTROYED 或者 INITIALIZED，肯定比 CREATED 小。而 mObserverMap.contains(observer) 必定为 true，除非我们手动移除掉 mObserverMap。因而，会走进 while循环。

private void pushParentState(State state) {
    mParentStates.add(state);
}

private ArrayList<State> mParentStates = new ArrayList<>();

pushParentState(statefulObserver.mState); 很简单，只是将 statefulObserver 的状态添加到 mParentStates 集合中。

继续往下走，接着会调用 statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));

private static Event upEvent(State state) {
    switch (state) {
        case INITIALIZED:
        case DESTROYED:
            return ON_CREATE;
        case CREATED:
            return ON_START;
        case STARTED:
            return ON_RESUME;
        case RESUMED:
            throw new IllegalArgumentException();
    }
    throw new IllegalArgumentException("Unexpected state value " + state);
}

upEvent 方法也很简单，只是返回它的下一个 event。这里因为他们的 state为 INITIALIZED，所以它会返回 ON_CREATE。

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

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

这里 event 为 ON_CREATE，所以 newState 也为 CREATED。 mState = min(mState, newState); mState newState，两者状态相同，所以 mState 也为 CREATED。接着回调 mLifecycleObserver 的 onStateChanged 方法。所以，这里，会收到我们的 onCreate 事件，与我们的预想相符。

但是我们并没有在 onStart，onResume, onPause , onStop 和 onDestroy 方法中调用 mLifecycleRegistry.handleLifecycleEvent 方法，它又是怎样促发 Observer 的 onStateChanged 方法的。这里先不揭晓，我们先来看一下 26.1.0 以后的 AppCompatActivity，待会你就明白了，会感叹 google 真的牛逼！

从 26.1.0 以后 AppCompatActivity 的设计说起

我们知道，在 26.1.0 以后，如果我们要使用 lifecycle，我们只需要调用以下的方法即可。

SupportActivity

getLifecycle().addObserver(new GenericLifecycleObserver() {

    @Override
    public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
        Log.d(TAG, "onStateChanged: event =" + event);
    }
});

跟踪 getLifecycle() 方法，它会跳转到 SupportActivity 的 getLifecycle 方法中。

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

    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ReportFragment.injectIfNeededIn(this);
    }
	
	    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
	
}

在 SupportActivity 中，它默认为我们初始化 mLifecycleRegistry，作为一个成员变量。接着，他在
onCreate 方法中调用了 ReportFragment.injectIfNeededIn(this); 方法。

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) {
        // 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();
        }
    }

在 injectIfNeededIn 方法中，它会判断我们是否已经添加 ReportFragment，没有的话，添加进去。

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

    private ActivityInitializationListener mProcessListener;

    private void dispatchCreate(ActivityInitializationListener listener) {
        if (listener != null) {
            listener.onCreate();
        }
    }

    private void dispatchStart(ActivityInitializationListener listener) {
        if (listener != null) {
            listener.onStart();
        }
    }

    private void dispatchResume(ActivityInitializationListener listener) {
        if (listener != null) {
            listener.onResume();
        }
    }
	
    @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;
    }
	}

然后，它在 onCreat ，onStart， onResume， onPause， onStop， onDestroy 方法中分别调用 dispatch 方法进行分发生命周期。


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

在 dispatch 方法中，会先判断 activity 是不是实现了 LifecycleRegistryOwner ，如果是，直接分发，不过不是，判断是否实现 LifecycleOwner，获取它的 lifecycle，调用它的 handleLifecycleEvent 进行分发。

1
2
3

public class SupportActivity extends Activity implements LifecycleOwner, Component {
   
    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this

而很明显，高版本的 SupportActivity 实现了 LifecycleOwner 接口，并写 LifecycleOwner.getLifecycle() 是 LifecycleRegistry

普通的 Activity

对于 26.1.0 以后的版本，你会发现，对于普通的 Activity，如果你想要使用 lifecycle，你只需要实现
LifecycleOwner 接口即可。当生命周期变化的时候，它也可以回调 Observer 的 onStateChanged 方法。

回到我们前面的问题：

我们并没有在 onStart，onResume, onPause , onStop 和 onDestroy 方法中调用 mLifecycleRegistry.handleLifecycleEvent 方法，它又是怎样促发 onStateChanged 方法的

我们猜想它也是通过 ReportFragment 实现的。但是在 Activity 的 onCreate 方法中，我们并没有发现它有添加 ReportFragment，我们在 As 全局搜一下，看哪些地方使用到 ReportFragment。如下图

从图中可以看到，有几个地方使用到他。我们先来看一下 LifecycleDispatcher

class LifecycleDispatcher {

    private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
            + ".LifecycleDispatcher.report_fragment_tag";

    private static AtomicBoolean sInitialized = new AtomicBoolean(false);

    static void init(Context context) {
        if (sInitialized.getAndSet(true)) {
            return;
        }
		// 在 init 方法中，监听全局 activity 的创建，从而来添加 fragment
        ((Application) context.getApplicationContext())
                .registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
    }

    @SuppressWarnings("WeakerAccess")
    @VisibleForTesting
    static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
        private final FragmentCallback mFragmentCallback;

        DispatcherActivityCallback() {
            mFragmentCallback = new FragmentCallback();
        }

        @Override
        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            if (activity instanceof FragmentActivity) {
                ((FragmentActivity) activity).getSupportFragmentManager()
                        .registerFragmentLifecycleCallbacks(mFragmentCallback, true);
            }
            ReportFragment.injectIfNeededIn(activity);
        }

        @Override
        public void onActivityStopped(Activity activity) {
            if (activity instanceof FragmentActivity) {
                markState((FragmentActivity) activity, CREATED);
            }
        }

        @Override
        public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
            if (activity instanceof FragmentActivity) {
                markState((FragmentActivity) activity, CREATED);
            }
        }
    }
	
	// 省略若干代码

}

可以看到，它在 init 方法中，通过 context.getApplicationContext() .registerActivityLifecycleCallbacks 监听全局 activity 的创建，在 activity oncreate 的时候，调用 ReportFragment.injectIfNeededIn(activity) ，从而来添加 fragment，进而分发相应的事件。

那 LifecycleDispatcher 的 init 方法又是在哪里调用的呢？我们全局搜索一下

public class ProcessLifecycleOwnerInitializer extends ContentProvider {
    @Override
    public boolean onCreate() {
        LifecycleDispatcher.init(getContext());
        ProcessLifecycleOwner.init(getContext());
        return true;
    }

可以看到它是在 ProcessLifecycleOwnerInitializer 的 onCreate 方法中调用的。而 ProcessLifecycleOwnerInitializer 是一个 ContentProvider。我们知道 ContentProvider 一般是在 AndroidManifest 中生命的。

果然，在 extensions-1.1.1.aar 中，我们惊喜地发现，它在 Manifest 里面注册了。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.arch.lifecycle.extensions" >

    <uses-sdk android:minSdkVersion="14" />

    <application>
        <provider
            android:name="android.arch.lifecycle.ProcessLifecycleOwnerInitializer"
            android:authorities="${applicationId}.lifecycle-trojan"
            android:exported="false"
            android:multiprocess="true" />
    </application>

</manifest>

而 ContentProvider 的 onCreate 方法优先于 Application 的 onCreate 执行，所以在 Application 之前我们就调用了 ProcessLifecycleOwnerInitializer init 方法，监听了 Activity 的创建，当 Actiivty 创建的时候，会尝试为 Activity 添加 ReportFragment。而 ReportFragment 会在 Activity 生命周期变化的时候帮助我们分发生命周期。

ContentProvider 的 onCreate 方法优先于 Application 的 onCreate 执行，可以查看这一篇博客 Android系统中的Application和四大组件一些方法的启动顺序和一些坑

总结

ok，我们来梳理一下。

对于 26.1.0 以后的 SupportActivity

它在 Activity onCreate 的时候添加了 ReportFragment，这个 ReportFragment 相当于一个代理，它在 onActivityCreated 的时候 dispatch(Lifecycle.Event.ON_CREATE) 进行分发生命周期，onStart， onResume, onPause, onStop, onDestroy 的时候也是如此。而在 dispatch 中它调用了 LifecycleRegistry handleLifecycleEvent 的方法。而 LifecycleRegistry 方法中经过一系列处理，它又调用了 observer 的 onStateChange 方法，去通知相应的 observer。

对于普通的 Activity

它利用了 ContentProvide 的特征，它是在 Application onCreate 之前初始化的，他在 ProcessLifecycleOwnerInitializer oncreate 的时候监听 Activity 的创建，在 Activity 创建的时候，判断是否已经添加过 ReportFragment，没有的话，添加进去。这是一个很巧妙的设计，隐式初始化了 lifecycle。

用流程图表示如下：

该图片引用自 Android 架构组件（一）——Lifecycle

Lifecycle 设计借鉴

利用 ProcessLifecycleOwnerInitializer contentProvider 来隐式加载

想一下，如果 ProcessLifecycleOwnerInitializer 不利用 contentProvider 来隐式加载的话，对于普通的 Activity，旧版本等，如果想使用 lifecycle，那必须在基类中，手动调用 ReportFragment.injectIfNeededIn(activity) 的方法。

利用 fragment 来分发生命周期

利用 fragment 来分发生命周期有两个优点

将逻辑从 Activity 中剥离出来，减少耦合，方便复用
可以做到在 Activity onCreate 之后才回调 observer 的 CREATED Event 事件。如果是通过 Application registerActivityLifecycleCallbacks 方法来分发生命周期的话，因为 ActivityLifecycleCallbacks 的 onActivityCreated 是在 Activity oncreate 之前调用的。

下一篇：Android livedata 源码解剖

Android lifecycle 使用详解

发表于 2019-01-11 更新于 2023-02-28
本文字数： 8.9k 阅读时长 ≈ 8 分钟

说在前面

Android lifecycle 使用详解

Android LiveData 使用详解