重学安卓2-1：为你还原一个真实的 Jetpack Lifecycle

作品简介
来龙去脉，专栏目录，更新动态，优惠政策，版权须知
温馨提示：如这是第一次接触《重学安卓》，可通过上述链接快速了解《重学安卓》专栏，获取 专栏目录、试读内容、更新动态 和 发展状况。
截至目前，专栏已对 体系化文章 实施 3310 余次修订，数十位群友告诉我，受专栏启发 亦开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创开源库 和 提供内推机会，订阅后可随时进群交流。

·

Note 2021.5.25 重要提示：
阅读本文最佳时机是，您已吃过 阅读 “源码” 或 “源码分析文” 时 找不到头绪的苦。
您还没吃过苦，那您先不要着急阅读本文。您得吃过苦，才会有体会。
在您吃够这方面苦后，您才有机会发现，本文正是专用于解决 “如何找到正确打开方式” 的困扰。
我们绝不通篇贴源码，而是基于广泛实践和反思，在累积过大量样本 乃至足以排除掉所有干扰信息后，点到为止揭露 Lifecycle 框架最核心本质，方便您理解其真实的存在意义，乃至笃信使用项目中。
关于 Lifecycle 在项目中实践，请另行查阅《GitHub : Jetpack-MVVM-Best-Practice》源码（可自行在 Android Studio 中通过全局查找关键字 “DefaultLifecycleObserver” 来定位）。

前言


前几期，我们在 “深度思考” 引导下，分别拆解 “视图控制器” Activity 和 Fragment “生命周期、重建机制、状态管理、路由跳转、页面通信” 的 存在缘由、设计依据、职责边界 和 相互间关系，

相信阅读完这几篇朋友，对 “视图控制器” 来龙去脉有了印象。

趁热打铁 Jetpack


基于上述 “前置知识” 的铺垫，接下来几期，我们趁热打铁拆解 Jetpack 高频使用的架构组件。

笔者写这篇文章的时候，也曾考虑过多方参考借鉴，不幸的是，彼时网上资料多是人云亦云搬运为主，部分博客甚至 意淫和鼓吹本不存在的职责和作用，让人阅读后难对实际状况有个基本把握，

故这期，我们继续从头开始追溯 Lifecycle 的来龙去脉，相信阅读后你会豁然开朗。

文章目录一览

  • 前言
  • 趁热打铁 Jetpack
  • Lifecycle 目标只有三个
  • Lifecycle 问世前的混沌世界
  • Lifecycle 为何能解决这三个问题？
  • Lifecycle 具体依赖的运作机制
  • 引入 Lifecycle 后的世界
  • 综上
  • 附注
  • Note 2020.2.27 加餐：
  • 造成人们误认为 “页面 onPause 时不会收到 LiveData 通知” 的原因
  • Note 2021.2.21 加餐：
  • 对 “一致性” 及 “一致性问题” 本质的解析

Lifecycle 目标只有三个


Lifecycle 最早是于 Support 26.1.0 引入。其设计是如此成熟和应景，乃至已成 appcompat 源码一部分，无需使用者在 Gradle 额外单独配置。 [注1]

Lifecycle 目标只有三个：

1.实现 “生命周期组件管理” 代码修改的一致性。
2.使第三方组件 随时可在自己内部拿到生命周期状态，以便执行 及时叫停 “错过时机” 异步业务 等操作。
3.使第三方组件调试时，能 安全便捷追踪到 “事故所在生命周期源”。

此外不存在个别人士讹传的其他作用。

划重点 👆👆👆

上述三点，如暂无体会，请跟随我脚步铺垫 Lifecycle 来龙去脉。

Lifecycle 问世前的混沌世界


例如开发一个需 “及时关闭资源” 的第三方组件 GpsManager。

为了 能跟随 “生命周期” 及时启用或释放资源，我们需要分别在每个 “依赖 GpsManager 组件的 Activity” 的 onResume、onPause 等生命周期节点方法中调用 GpsManager 对应的方法。

且为了 能及时叫停 “错过时机” 的异步业务 以避免 “内存泄漏” 等情况发生，我们额外安排 isActive 变量，用于及时从 Activity 拿到 “异步业务是否适合继续” 指标，以便在异步业务中定期做出判断。


那这么做会带来什么问题？—— 复杂度激增导致容易出错 ——

因为我们需为每个依赖 GpsManager 的 Activity，都安排好 “生命周期调用” 和 “状态通知”，

一旦 Activity 变多，便 难保证多处代码修改一致 —— 例如日后我在 ActivityA 的 onPause 节点添加 GpsManager 新增的 onClear 方法，而同事的 ActivityB 忘添加。

此外，对 “接收状态通知” 需求，导致我们需在 “每个 Activity” 的生命周期回调中，额外安排 setActive，无疑又增加复杂度（并且 “每个 Activity 都维护 isActive 等变量” 的做法同样也构成 “代码修改不一致” 的隐患）。

再者，如调试时，我想确知当前事件源 Activity，传统方式只能额外注入 Activity 到 GpsManager 中，

虽如今倡导单 Activity App，使 Activity 生命周期基本和 Application 持平从而规避一系列 “内存泄漏” 问题，但如果事件源是 Fragment，情况就变得复杂多端。而，

Lifecycle 就是为解决上述三个问题而存在。

Lifecycle 为何能解决这三个问题？


在 《重学安卓：Activity 快乐你不懂》 中我们介绍到，Activity 是一种 “模版方法模式” 实现，也即将 “窗口管理、多任务管理” 等开发者无需关注细节，放基类中完成，对子类只暴露生命周期等回调。

这样开发者就能通过继承 Activity，拿到简洁干净子类模板 Activity。

Lifecycle 同样包含 “模版方法模式” 封装思想，将生命周期管理封装在基类，如此子类模板中只需统一调用一行 API：getLifecycle().addObserver(mGpsManager) 即可达成 “生命周期组件管理” 代码修改的一致性。
创作时间：