唠唠 Activity 的生命周期
Android 复习笔记目录
唠唠任务栈，返回栈和生命周期
唠唠 Activity 的生命周期
上一篇文章唠了唠 任务栈，返回栈和启动模式，今天来聊一聊同样和 Activity 息息相关的 生命周期 。
关于 Activity 的生命周期，我相信大家倒着都可以说出来了。这里放一张 android-lifecycle 里的经典大图，其中也包含了 Fragment 的生命周期图。
由于这是一张 2014 年的图，注意 onRestoreInstanceState() 和 onSaveInstanceState() 的调用时机会因为 SDK 版本的不同稍有变化，文章后面也会提到。
目录
每个生命周期做了什么？
onStart/onStop ？还是 onResume/onPause ？
如何进行 UI 状态的存储与恢复？
Activity 和应用进程的关系
在什么时机触发 LeakCanary 的检测？
被 SharedPreference 拖累的 Activity
每个生命周期做了什么？
onCreate()
这是 Activity 的第一个生命周期方法，其中必须要做的操作就是 setContentView()。
setContentView() 里面大概做了这么几件事：
创建 DecorView，并设置 PhoneWindow
解析 xml 布局文件，生成 View 对象并塞到 DecorView 中
此时 DecorView 并没有被绘制，Window 对象也没有被显示到屏幕，Activity 也是不可见的。
除此之外，开发者通常也会在 onCreate() 方法中做一些数据的初始化操作。
onCreate() 在一次完整的生命周期中只会回调一次，它也不是一个长驻状态，完成工作只会就会进入 onStart() 。
onStart()
onStart() 也不是一个长驻状态，官方文档对于它的描述是这样的：
The onStart() call makes the activity visible to the user, as the app prepares for the activity to enter the foreground and become interactive.
在 onStart() 方法中，Activity 对用户可见，应用准备进入前台和用户交互。我对这句 Activity 对用户可见 其实抱有很大的疑问。
不考虑特殊情况，正常启动一个 Activity，onCreate -> onStart ，此时所谓的 “可见”，见到的是什么？
这个问题在下面的 onResume 一节中会详细说明，读者可以先仔细揣摩一下。
onStart() 方法中可以做些什么呢？通常会和 onStop() 搭配做一些资源申请和释放的工作，例如相机的申请和释放。
onResume
熟悉 UI 绘制流程的读者肯定知道，onResume() 是真正进行 UI 绘制以及显示的地方。其中的核心逻辑就是 WindowManager.addView() 方法，实际调用的是 WindowManagerGlobal.addView() 方法。它大致干了这么几件事：
创建 ViewRootImpl 对象
调用 ViewRootImpl.setView() 方法
ViewRootImpl 的构造函数中做了这么几件事：
初始化跟 WMS 通信的 WIndowSession 对象，这是一个 Binder 对象
初始化 Choreographer 对象
ViewRootImpl.setView() 方法做了这么几件事：
调用 requestLayout() 方法，发起绘制
Binder 调用 WMS.addToDisplay() 方法，将 window 添加到屏幕
requestLayout() 方法中就会进行我们所熟知的 测量、布局和绘制 流程，但并不是直接进行的，它依赖 vsync 信号。requestLayout() 只是通过前面已经初始化了的 Choreographer 对象进行注册监听，当下一个 vsync 信号来临时，会回调 performTraversals() 方法，这其中就会真正的进行测量、布局和绘制。
整个 UI 绘制流程的知识点很多，仅靠以上简单一段文字肯定是无法完全概括的，感兴趣的读者可以自己去翻翻源码。但是我们可以肯定是，onResume 是真正的用户界面可见的时机。
再回到之前的问题，onStart 中可见的是什么？我也无法回答这个问题，或者可能大家都曲解了官方文档的意思，是否应该理解为 “Activity 即将可见”。大家可以在留言区说说你的看法。
同样，onResume() 通常也可以和 onPause() 搭配做一些资源申请和释放的工作。那么，既然 onStart/onStop 和 onResume/onPause 都可以，该如何选择呢？同样放到后面进行解答。
onPause
onPause() 是一个很短暂的过程，之后如果用户返回了之前的 Activity，则会回调 onResume 。如果没有，则会回调 onStop 。
给 onPause 一个精准的描述的话，应该是 非前台，不可交互，但不一定不可见 。对于系统来说，无论是手机还是 PC ，同一个时间一定只有一个处于前台，获取焦点，且可与用户交互的活动窗口，所以 非前台，不可交互 很好理解。那 不一定不可见 如何理解呢？其实也很简单，类似 PC 的多窗口，Android 系统也是有多窗口模式的。
最后，注意 onPause 中不建议进行重量级的耗时操作，因为在 Activity 跳转过程中，前一个 Activity 的 onPause() 是发生在后一个 Activity 的任何生命周期之前的。
onStop
完全的不可见状态。但此时的 Activity 仍在内存中，只是没有关联到任何 Window 。如果后续有机会再次返回，则会回调 onRestart -> onStart 。
onDestroy
onStop 之后没有被用户捞回去，最后就得被销毁。主动的调用 finish 或者系统配置改变也会可能导致销毁。
注意在 onDestroy 中释放所有不需要的资源，否则可能导致内存泄露。
到目前为止，简单介绍了各个生命周期的回调时机和应该处理的事情，同时也带了一些疑问。下面来说说一些知识点。
onStart/onStop ？还是 onResume/onPause ？
在使用 EventBus 的时候，需要在相应的声明周期中进行注册和解注册的操作，如下所示：
@Override
public void onStart() {
super.onStart();
EventBus.getDefault().register(this);
}
@Override
public void onStop() {
super.onStop();
EventBus.getDefault().unregister(this);
}
当然，在 onResume/onPause 中一般也是没有问题的。
@Override
public void onResume() {
super.onStart();
EventBus.getDefault().register(this);
}
@Override
public void onPause() {
super.onStop();
EventBus.getDefault().unregister(this);
}
但它们之间并不是完全没有区别的。通常情况下，onPause 之后很快就会 onStop，但是考虑到 Android 7.0 之后新增的 多窗口模式 的话，Activity 可能会停留在 onPause 一段时间。这种情况下，如果在 onStop 中进行资源释放操作的话，可能并不能及时释放。如果你的 Activity 持有的是相机等系统资源，会导致其他应用无法使用该资源，对用户来说无疑是很不友好的。所以，在进行类似操作的时候要考虑一下应用场景。onResume/onPause 关注的是 Activity 是否可以交互，onStart/onStop 关注的是 Activity 是否可见。
最后得说下，上面的代码中把生命周期处理和视图控制器耦合在一起，并不是那么优雅，可以通过 LifeCycle 组件进行解耦。拿我之前文章中的代码说明一下：
class LocationUtil( ) : LifeCycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun startLocation( ){
......
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun stopLocation( ){
......
}
}
传送门：
硬核讲解 Jetpack 之 LifeCycle 使用篇
硬核讲解 Jetpack 之 LifeCycle 源码篇
如何进行 UI 状态的存储与恢复？
除了正常状态下的数据持久化存储，异常情况下的数据保存和恢复也是必要的。这里的异常情况一般指系统配置变化，典型的横竖屏切换，系统语言切换等。
异常情况下终止的 Activity，系统会调用 onSaveInstanceState() 方法来保存当前 Activity 的状态。那么哪些状态默认会被保存呢？我们可以看一下 TextView 的 onSaveInstanceState() 方法。
@Override
public Parcelable onSaveInstanceState() {
Parcelable superState = super.onSaveInstanceState();
......
if (freezesText || hasSelection) {
SavedState ss = new SavedState(superState);
if (freezesText) {
if (mText instanceof Spanned) {
final Spannable sp = new SpannableStringBuilder(mText);
if (mEditor != null) {
removeMisspelledSpans(sp);
sp.removeSpan(mEditor.mSuggestionRangeSpan);
}
// 保存文字
ss.text = sp;
} else {
ss.text = mText.toString();
}
}
...
return ss;
}
return superState;
}
可以看到文字是保存了的，这里删减了很多代码，其实还保存了其他一些状态。只要是实现了 onSaveInstanceState()方法的 View，都会被保存下来。当 Activity 重新创建时，会通过 onCreate() 或者 onRestoreInstanceState() 方法恢复状态。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
}
override fun onRestoreInstanceState(savedInstanceState: Bundle) {
super.onRestoreInstanceState(savedInstanceState)
}
在 Kotlin 中重写这两个方法也可以看到，onCreate() 方法的参数是可空的，因为会有正常启动的情况。所以一般建议直接在 onRestoreInstanceState 方法中进行状态恢复即可。
对于非 UI 状态的其他数据，就得自己手动进行保存和恢复了。这里直接拿官方文档的示例代码：
override fun onSaveInstanceState(outState: Bundle?) {
// Save the user's current game state
outState?.run {
putInt(STATE_SCORE, currentScore)
putInt(STATE_LEVEL, currentLevel)
}
// Always call the superclass so it can save the view hierarchy state
super.onSaveInstanceState(outState)
}qubie
override fun onRestoreInstanceState(savedInstanceState: Bundle?) {
// Always call the superclass so it can restore the view hierarchy
super.onRestoreInstanceState(savedInstanceState)
// Restore state members from saved instance
savedInstanceState?.run {
currentScore = getInt(STATE_SCORE)
currentLevel = getInt(STATE_LEVEL)
}
}
要注意的是，通过 onSaveInstanceState 的方式存储数据，由于是发生在主线程，且存在序列化/反序列化的开销，并不建议存储大量数据。其实更好的做法是使用 ViewModel ，它可以在系统配置变化发生的 Activity 重建过程中来保存数据。
最后来说一下 onSaveInstanceState 的调用时机问题。在不同的 SDK 版本中，这个时机是不唯一的。
SDK 11 之前，在
onPause()之前调用SDK 28 之前，会在
onStop()之前调用SDK 28 之后，会在
onStop之后调用
当然，这对我们来说并没有什么实质的区别。
Activity 和应用进程的关系
当系统内存不足时，会存在单个 Activity 直接被系统回收的情况吗？
答案是否定的。
首先应用进程的生存时间并不是由自己直接控制的，而是由系统决定的。每一个 App 都至少对应着一个 Linux 进程。当系统内存不足无法满足正在与用户交互的进程的需求时，可能会回收一些资源。这些资源是一个一个进程，而不是进程里的一个一个组件，不会存在单个 Activity 被系统回收的情况。
那么，既然要回收进程，那么肯定会给进程分个三六五等。按照官方文档的描述，大致有这么几类，重要性依次降低。
Foreground Process :
有 Activity 处于前台，正在和用户交互
BroadcastReceiver 的 onReceive 方法正在执行
Service 正在运行代码，包括 onCreate，onStart，onDestroy
Visible Process ：
有 Activity 可见，但不在前台
Service 正在运行前台服务
持有一些用户可以感知的特定服务，如动态壁纸，输入法服务
Service Process ：
有正在运行的 Service ，对用户不可见，但正在进行一些用户关心的工作，例如后台下载等。当系统内存不足的时候，可能会被干掉。
官方文章说运行超过 30 min 可能会被降级，但这个在不同的国产 ROM 肯定是有魔改的，具体应该以实际测试为准。
Cached Process ：
当系统内存不足时可以随时自由终止的无用线程。但是为了更高效的切换应用，系统一般不会把它们全部 kill 掉。
在什么时机触发 LeakCanary 的检测？
之前群里的小伙伴 codelang 分享了一个有趣的知识点：
为什么 LeakCanary 要在 Activity onDestroy 之后调用 RefWatcher.watch() 开始监测内存泄露？
他给出的答案是：
从 ActivityThread 的角度看，Activity 就是一个对象，按照 GC Root，Activity 是被 ActivityThread 给引用着的。为什么要在 onDestroy 之后开始检测，因为这个时候 Activity 和 ActivityThread 的引用断开了，在 ActivityThread.performDestroyActivity() 中从 mActivities 中移除了当前 Activity 对象。
的确，在 onDestroy() 之前，Activity 根本没有断开和 GC Roots 的引用，检测个啥呢。
被 SharedPreference 拖累的 Activity
之前写过一篇 细数 SharedPreference 的槽点 来吐槽 SP 。不合理的使用 SP 可能会导致卡顿，甚至 ANR 。
apply() 方法和 commit() 方法不同，它是通过异步任务来进行存储操作的，通过 QueuedWork 类实现。
QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
而在 onStop 中，需要等待这个异步任务的完成。看一下 ActivityThread.java 中 handleStopActivity() 方法：
@Override
public void handleStopActivity(IBinder token, boolean show, int configChanges,
PendingTransactionActions pendingActions, boolean finalStateRequest, String reason) {
......
// 可能因等待写入造成卡顿甚至 ANR
if (!r.isPreHoneycomb()) {
QueuedWork.waitToFinish();
}
......
}
无论修改了什么数据，这里的存储都是全量写入，如果数据量过大，一定是会存在性能问题的。此外还要注意 SP 的舒适化过程也是全量读取放到内存中，所以在数据量大的情况下，注意提前初始化。
最后
关于 Activity 的生命周期就说这么多了，后面如果碰到相关的有意思的问题，再回来补充。
都看到这了，不妨关注我一下呗！
