什么是Lifecycle? LifeCycle是JetPack库中的一个重要组成部分. 它将一个对象的生命周期管理与对象本身抽离开来, 实现了观察与反应的解耦. 可能这几句话比较抽象, 我来展示一个实际的情景:
当我们学习Activity和Fragment的时候, 一定都写过相应的demo, 通过Log这个工具来展示二者的生命周期, 就像下面的代码:
Example1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 public class MainActivity extends AppCompatActivity { private static final String TAG = "tag" ; @Override protected void onCreate (Bundle savedInstanceState) { super .onCreate(savedInstanceState); setContentView(R.layout.activity_main); Log.i(TAG, "Activity正在创建" ); } @Override protected void onStart () { Log.i(TAG, "Activity正在启动" ); } @Override protected void onResume () { Log.i(TAG, "Activity正在继续" ); } @Override protected void onPause () { Log.i(TAG, "Activity正在暂停" ); } @Override protected void onStop () { Log.i(TAG, "Activity正在停止" ); } @Override protected void onDestroy () { Log.i(TAG, "Activity正在销毁" ); } }
可以看到, 即使是最简单的打印日志, Activity类就已经非常长了. 如果在实际应用中, 其它类想要监听Activity的生命周期, 不仅要让Activity类持有这些类的实例的引用, 还要在各种Activity的生命周期函数中填满这些实例的相应方法. 这样一来, Activity变得臃肿庞大不说, 它所拥有的实例引用过多也可能会导致各种各样的问题.
LifeCycle就是专门负责解决这种问题的. 至于怎么解决, 请大家继续往下看.
Lifecycle的结构 LifecycleOnwer和LifecycleObserver 在介绍LifeCycle的用法之前, 我们需要对LifeCycle相关的接口做一个简单的学习. 首先, 我们直接接触的接口有两个: LifeCycleOwner和LifeCycleObserver. 这两个接口的意义很简单, LifeCycleOwner用来修饰需要被观察生命周期的类(比如Activity和Fragment), LifeCycleOwner用来修饰要观察一个类的声明周期的类(比如一个专门用来输出Acitivity的生命周期的日志打印类). 它们的源码如下:
LifecycleOnwer和LifecycleObserver 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 @SuppressWarnings({"WeakerAccess", "unused"}) public interface LifecycleOwner { @NonNull Lifecycle getLifecycle () ; } @SuppressWarnings("WeakerAccess") public interface LifecycleObserver { }
两个接口都十分简单. 作为被观察的对象, LifecycleOwner只需要提供自己的生命周期就好了, 所以它只有一个getLifecycle()方法. 作为观察者, 我们看到LifecycleObserver并没有直接提供对应生命周期的函数. 我猜测原因是这样的: 并不是所有的的观察者都需要在被观察对象的每个生命周期阶段执行操作, 如果将各个生命周期阶段的回调函数都写入这个接口中, 那么就会造成接口污染, 这是违反接口隔离原则的. 为了解决这个问题, 谷歌使用了注解来动态注册相应阶段的回调方法.
从这两个接口的源码中可以看到, 它们都是Lifecycle类对外提供的接口, 要想正确地使用它们, 就还要再学习Lifecycle类的实现.
Lifecycle Lifecycle 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 public abstract class Lifecycle { @MainThread public abstract void addObserver (@NonNull LifecycleObserver observer) ; @MainThread public abstract void removeObserver (@NonNull LifecycleObserver observer) ; @MainThread @NonNull public abstract State getCurrentState () ; @SuppressWarnings("WeakerAccess") public enum Event { ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_ANY } @SuppressWarnings("WeakerAccess") public enum State { DESTROYED, INITIALIZED, CREATED, STARTED, RESUMED; public boolean isAtLeast (@NonNull State state) { return compareTo(state) >= 0 ; } } }
上面是Lifecycle类的源码. 因为源码的注释有很多, 为了不影响大家的阅读体验, 我删去了很多无伤大雅的注释. 通过源码我们可以看到, Lifecycle这个抽象类包括LifecycleObserver的添加和移除方法, 获取当前生命周期的getCurrentState()方法以及Event和State两个枚举类. 我们分别来说一下它们的意义.
首先是addObserver和removeObserver两个方法. 从刚才LifecycleOwner的源码中我们可以看到, LifecycleOwner只是用来标记一个类是否拥有Lifecycle的, 真正被LifecycleObserver观察的, 不是LifecyclerOwner这个接口, 而是Lifecycle这个抽象类. 换句话说, 如果你想让一个类能被一个LifecycleObserver观察到, 要么让这个类直接继承Lifecycle这个抽象类, 要么让这个类持有一个Lifecyle的引用.
然后是Event枚举类. 在学习LifecycleBoserver的源码中我们看到, 要实现回调就必须使用注解来注册回调函数. Event枚举类就是标明这些回调函数应该在生命周期的哪个阶段来执行的.
最后是State枚举类和getCurrentState()方法. 如果说Event枚举类中的元素是生命周期的一段时间的话, 那么State枚举类中的元素就是生命周期中的特定时间点, 它们用来分隔开Event中元素所代表的生命周期时段. 通过getCurrentState()方法, 我们就可以得知目前被观察的类处在生命周期的哪个时间点上. 除了精确获取时间点的getCurrentState()方法, 我们还可以通过State类中的isAtLeast()方法来判断被观察的类是否经过了参数给定的时间点. 大家可以看到, State类中各元素的注释我并没有删除, 这是因为这些注释非常重要, 它们写明了某个State元素在生命周期中的具体位置, 这是需要大家记住的.
如何使用Lifecycle? 看了这么多源码, 我们已经对Lifecycle的使用有了基本的认识, 接下来我们来看一看怎么使用Lifecycle.
自定义LifecycleOwner 由于经常被观察的AppCompatActivity和Fragment已经实现了LifeCycleOwner的接口, 所以其实我们用得最多的还是为自己的类实现LifecycleObserver接口. 这里我们就用Lifecycle将文章开头的例子改写一下:
首先创建一个用于打印日志的MyLifeCycleObserver类:
Example2-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 public class MyLifeCycleObserver implements LifecycleObserver { private static final String TAG = "tag" ; @OnLifecycleEvent(Lifecycle.Event.ON_CREATE) public void onCreate () { Log.i(TAG, "Activity正在创建" ); } @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void onResume () { Log.i(TAG, "Activity正在继续" ); } @OnLifecycleEvent(Lifecycle.Event.ON_START) public void onStart () { Log.i(TAG, "Activity正在启动" ); } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void onPause () { Log.i(TAG, "Activity正在暂停" ); } @OnLifecycleEvent(Lifecycle.Event.ON_STOP) public void onStop () { Log.i(TAG, "Activity正在停止" ); } @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY) public void onDestroy () { Log.i(TAG, "Activity正在销毁" ); } @OnLifecycleEvent(Lifecycle.Event.ON_ANY) public void alwaysWork () { Log.i(TAG, "这条消息总会出现" ); } }
代码逻辑很简单, 仍然是在Activity生命周期的各个阶段打印日志.
然后我们让一个MyLifeCycleObserver的实例去观察MainActivity:
Example2-2 1 2 3 4 5 6 7 8 9 10 11 public class MainActivity extends AppCompatActivity { @Override protected void onCreate (Bundle savedInstanceState) { super .onCreate(savedInstanceState); setContentView(R.layout.activity_main); getLifecycle().addObserver(new MyLifeCycleObserver ()); } }
我们看到, 用Lifecycle实现的例子中, MainActivity的内容就没有那么冗长了, 所有关于它的在各种生命周期执行的回调函数都被放入了MyLifeCycleObserver中, 这就是观察和反应的解耦.
接下来我们看一下运行的结果:
可以看到, 一切都运行地非常完美.
自定义LifecycleOwner 当然, 我们也可以自定义LifecycleOwner. 在这里, 我们让MainActivity继承于没有实现LifecycleOwner的Activity类, 然后再实现LifecycleOwner接口:
Example2-3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 public class MainActivity extends Activity implements LifecycleOwner { private LifecycleRegistry lifecycleRegistry = new LifecycleRegistry (this ); @Override protected void onCreate (Bundle savedInstanceState) { super .onCreate(savedInstanceState); setContentView(R.layout.activity_main); lifecycleRegistry.markState(Lifecycle.State.CREATED); getLifecycle().addObserver(new MyLifeCycleObserver ()); } @NonNull @Override public Lifecycle getLifecycle () { return lifecycleRegistry; } @Override protected void onStart () { super .onStart(); lifecycleRegistry.markState(Lifecycle.State.STARTED); } @Override protected void onResume () { super .onResume(); lifecycleRegistry.markState(Lifecycle.State.RESUMED); } @Override protected void onStop () { super .onStop(); lifecycleRegistry.markState(Lifecycle.State.DESTROYED); } }
可以看到, 实现LifecycleOwner, 其实最重要的就是在生命周期的各个阶段用State枚举类的元素进行标记, 这样就可以通知它的观察者执行一系列回调了. 至于LifecycleRegistry这个类是用来干什么的, 我们在下面会提到.
然后我们再执行程序:
可以看到效果是一样的.
LifeCycle的实现原理 讲完了Lifecycle相关的使用, 现在我们来看一下Lifecycle到底是怎么实现的. 关于LifecycleObserver的实现, 在上面已经基本上讲完了, 所以这部分主要讲的是LifecycleOwner的实现.
在自定义LifecycleOwner的部分, 我们看到了有一个LifecycleRegistry类, 这个类是用来干什么的呢?
LifecycleRegistry 1 2 3 4 5 6 7 8 public class LifecycleRegistry extends Lifecycle { private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap <>(); private State mState; private final WeakReference<LifecycleOwner> mLifecycleOwner; private int mAddingObserverCounter = 0 ; }
上面是LifecycleRegistry的一些属性, 我们看到, LifecycleRegistry实际上就是一个Lifecycle, 它通过一个Map来管理观察自己的Observer, 通过mState来记录自己的当前生命周期状态. 显然, 要实现的addObserver、removeObserver以及getCurrentState这三个抽象方法就是用来管理这两个属性的. 那么Map中的ObserverWithState是什么呢? 它是LifecycleRegistry的内部静态类, 实现代码如下:
ObserverWithState 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 static class ObserverWithState { State mState; LifecycleEventObserver mLifecycleObserver; ObserverWithState(LifecycleObserver observer, State initialState) { mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer); mState = initialState; } void dispatchEvent (LifecycleOwner owner, Event event) { State newState = getStateAfter(event); mState = min(mState, newState); mLifecycleObserver.onStateChanged(owner, event); mState = newState; } }
可以看到, 这个类的实现逻辑是这样的: 不是所有的Observer都是在Lifecycle刚创建时就被添加进来的, 因为它们的起点不一样, 所以不能统一用LifecycleRegistry的mState来通知. 解决方法是, 在添加Observer时, 复制LifecycleRegistry当前的状态作为这个Observer的起点. 当Lifecycle的生命周期变化时, 它会遍历Map存储的所有Observer, 更新它们的状态副本, 然后再让它们执行它们对应的回调.
到这里, Lifecycle基本上就讲完了, 不过还有一个小问题: 在自定义LifecycleOwner的时候, 我们在Activity的各个生命周期函数中调用了markState()这个方法来标记自己的状态. 但是在我们重写AppCompaatActivity的各个生命周期函数时, 我们并没有看到有这些东西啊?
为了解答这个问题, 我们寻找AppCompatActivity的父类到实现了LifecycleOwner接口的ComponentActivity类. 在这个类中, 我们能看到一句话:
1 ReportFragment.injectIfNeededIn(this );
看来和ReportFragment又有关系了, 那我们就来看看它的源码:
ReportFragment 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 public class ReportFragment extends Fragment { private static final String REPORT_FRAGMENT_TAG = "androidx.lifecycle" + ".LifecycleDispatcher.report_fragment_tag" ; public static void injectIfNeededIn (Activity activity) { if (Build.VERSION.SDK_INT >= 29 ) { activity.registerActivityLifecycleCallbacks( new LifecycleCallbacks ()); } android.app.FragmentManager manager = activity.getFragmentManager(); if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null ) { manager.beginTransaction().add(new ReportFragment (), REPORT_FRAGMENT_TAG).commit(); manager.executePendingTransactions(); } } @SuppressWarnings("deprecation") 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); } } } static ReportFragment get (Activity activity) { return (ReportFragment) activity.getFragmentManager().findFragmentByTag( 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); mProcessListener = null ; } private void dispatch (@NonNull Lifecycle.Event event) { if (Build.VERSION.SDK_INT < 29 ) { dispatch(getActivity(), event); } } void setProcessListener (ActivityInitializationListener processListener) { mProcessListener = processListener; } interface ActivityInitializationListener { void onCreate () ; void onStart () ; void onResume () ; } static class LifecycleCallbacks implements Application .ActivityLifecycleCallbacks { @Override public void onActivityCreated (@NonNull Activity activity, @Nullable Bundle bundle) { } @Override public void onActivityPostCreated (@NonNull Activity activity, @Nullable Bundle savedInstanceState) { dispatch(activity, Lifecycle.Event.ON_CREATE); } @Override public void onActivityStarted (@NonNull Activity activity) { } @Override public void onActivityPostStarted (@NonNull Activity activity) { dispatch(activity, Lifecycle.Event.ON_START); } @Override public void onActivityResumed (@NonNull Activity activity) { } @Override public void onActivityPostResumed (@NonNull Activity activity) { dispatch(activity, Lifecycle.Event.ON_RESUME); } @Override public void onActivityPrePaused (@NonNull Activity activity) { dispatch(activity, Lifecycle.Event.ON_PAUSE); } @Override public void onActivityPaused (@NonNull Activity activity) { } @Override public void onActivityPreStopped (@NonNull Activity activity) { dispatch(activity, Lifecycle.Event.ON_STOP); } @Override public void onActivityStopped (@NonNull Activity activity) { } @Override public void onActivitySaveInstanceState (@NonNull Activity activity, @NonNull Bundle bundle) { } @Override public void onActivityPreDestroyed (@NonNull Activity activity) { dispatch(activity, Lifecycle.Event.ON_DESTROY); } @Override public void onActivityDestroyed (@NonNull Activity activity) { } } }
虽然这个类很长, 但是逻辑却十分简单. 谷歌通过重重的封装和调用, 将AppCompatActivity的生命周期标记任务从AppCompatActivity本身转移到了ReportFragment身上. 也就是说, 我们获取到的AppCompatActivity的生命周期, 其实是ReportFragment的生命周期. 因为Fragment和Activity的生命周期是相同的, 所以这种“移花接木”的方式也能实现我们想要的效果.
