温馨提示：如果这是第一次接触《重学安卓》，可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容，以及了解它的最新动态 和 发展状况。
截至目前，专栏已对 体系化文章 做了 1270 余次修订，数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会，订阅后可随时进群交流。
前言
很高兴见到你！
前几期，我们在 全网独家 深度思考 的引导下，通过
重学安卓：Activity 生命周期的 3 个辟谣
重学安卓：绝不丢失状态的 Activity 重建机制！
重学安卓：你丢了 offer，只因拎不清 Activity 任务和返回栈
重学安卓：Intent 就是你的择偶标准啊！
重学安卓：我的碎片很听话，你的 Fragment 有自己的想法
分别正确理解了 视图控制器 Activity 和 Fragment 的 生命周期、重建机制、状态管理、路由跳转、页面通信 的 存在缘由、设计依据、职责边界 和 相互间关系。
相信阅读完这几篇的朋友，对视图控制器的脉络已形成深刻的印象。😉
被提前提上日程的 Jetpack
所以，本来我是想，紧接着出几期 “视图系统” 相关的解读，而 Jetpack 放在最后一期软件工程实战时统一介绍。
没想到在后台有读者留言说，期待能早日看到我对 Jetpack 的解说。
—— 是网上关于 Jetpack 的文章太少了吗？不是的，恰恰相反，网上的 Jetpack 文章一抓一大把，却基本上是 未经思考 就发布到网上 的 大段摘抄、全篇都在贴源码的、人云亦云、含糊其辞 的搬运文。😡😠
这不仅不能 帮助读者迅速了解状况 —— 究竟是面临了什么问题，乃至于问世了这样的框架。反而还让人看了觉得云里雾里、白费大量时间。（例如，生命周期 “感知” 是一个十分抽象的术语，一味地用 “感知” 来自嗨，并不能让更多的人 “感知” 真实的状况）
更有甚者，完全脱离事实 去 意淫和鼓吹一些本不存在的职责和作用，给读者造成误导。
此外，考虑到前几期刚好是 完整地将 视图控制器的知识点 给过了一遍。
于是我打算趁热打铁地将 生命周期管理、状态管理、页面通信、路由跳转 的 Jetpack 最佳实践给大家过一遍。
也即接下来几期，我会分别解说 Lifecycle、ViewModel、LiveData、Navigation，来方便大家迅速理解真实的状况。😉
文章目录一览
- 前言
- 被提前提上日程的 Jetpack
- Lifecycle 的目标只有三个
- Lifecycle 问世前的混沌世界
- Lifecycle 为什么能解决这三个问题？
- 那 Lifecycle 具体是依赖什么机制运作的呢？
- 引入 Lifecycle 后的世界
- 综上
- 附注
- Note 2020.2.27 加餐：
- 造成人们误认为 “页面 onPause 时不会收到 LiveData 通知” 的原因
- Note 2021.2.21 加餐：
Lifecycle 的目标只有三个
Lifecycle 最早是在 support 26.1.0 时被引入的。它的设计是如此地成熟和应景，乃至于已经成为源码的一部分，而几乎无需使用者在 Gradle 额外地配置依赖。 [注1]
Lifecycle 的目标只有三个：
1.实现生命周期 管理的一致性，做到 “一处修改、处处生效”。
2.让第三方组件能够 随时在自己内部拿到生命周期状态，以便执行 及时叫停 错过时机的 异步业务 等操作。
3.让第三方组件在调试时 能够 更方便和安全地追踪到 事故所在的生命周期源。
此外不存在任何 个别人士讹传的其他作用！
划重点 👆👆👆
如果光是阅读了以上三点，你还是不太理解的话，那接下来我就分别介绍 99% 网文都不曾介绍的真实状况，来方便你迅速建立起感性的认识。😉
Lifecycle 问世前的混沌世界
例如我们开发了一个需要及时关闭资源的第三方组件 GpsManager。那么为了做到跟随生命周期及时启用或释放资源，我们分别需要在每个依赖 GpsManager 的 Activity 中调用 onResume、onPause 等方法。
并且为了能够 及时叫停 错过时机 的异步业务，来避免内存泄漏等情况发生，我们额外安排了 isActive 变量，以便能够及时从 Activity 拿到 “异步业务是否适合继续” 的指标，并在异步的业务中定期做出判断。
那这样带来一个什么问题呢？—— 复杂度激增导致的容易出错。
为什么呢？
因为我们需要为每个依赖 GpsManager 的 Activity 都安排好 生命周期调用 和 状态通知。
一旦 Activity 变多，就 难以保证修改的一致性，比如日后我在 ActivityA 修改了 GpsManager 生命周期的管理方式，而同事的 ActivityB 忘了被修改，这就造成了问题。
如果你对 “一致性” 的概念不太理解的话，那么请回顾一下大学时期 数据库课程中提到的 “存储过程”，它就是典型的 “一致性” 封装：将一套连贯的 SQL 序列封装在一个 “API” 中，外部人员只需调用这个 “API”，而无需知道内部具体发生了什么。
这避免了程序员 A 修改了某 SQL 语句，而程序员 B 没跟上。并且，“API” 的管理人只需一处修改，就能做到处处生效。
此外，对接收状态通知的需求，导致了我们可能需要在每个 Activity 中的每个生命周期回调额外安排上 setActive，这无疑又增加了复杂度。
再者，如果调试时，我想确知当前的事件源是哪个 Activity 呢？传统的方式只能额外地注入 Activity 到 GpsManager 中了。虽然如今倡导单 Activity App，使得 Activity 的生命周期基本和 Application 持平，而规避了一系列内存泄漏的问题，但如果事件源是 Fragment 呢？
Lifecycle 就是为解决上述三个问题而存在。
温馨提示：如果这是第一次接触《重学安卓》，可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容，以及了解它的最新动态 和 发展状况。
截至目前，专栏已对 体系化文章 做了 1270 余次修订，数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会，订阅后可随时进群交流。
前言
很高兴见到你！
前几期，我们在 全网独家 深度思考 的引导下，通过
重学安卓：Activity 生命周期的 3 个辟谣
重学安卓：绝不丢失状态的 Activity 重建机制！
重学安卓：你丢了 offer，只因拎不清 Activity 任务和返回栈
重学安卓：Intent 就是你的择偶标准啊！
重学安卓：我的碎片很听话，你的 Fragment 有自己的想法
分别正确理解了 视图控制器 Activity 和 Fragment 的 生命周期、重建机制、状态管理、路由跳转、页面通信 的 存在缘由、设计依据、职责边界 和 相互间关系。
相信阅读完这几篇的朋友，对视图控制器的脉络已形成深刻的印象。😉
被提前提上日程的 Jetpack
所以，本来我是想，紧接着出几期 “视图系统” 相关的解读，而 Jetpack 放在最后一期软件工程实战时统一介绍。
没想到在后台有读者留言说，期待能早日看到我对 Jetpack 的解说。
—— 是网上关于 Jetpack 的文章太少了吗？不是的，恰恰相反，网上的 Jetpack 文章一抓一大把，却基本上是 未经思考 就发布到网上 的 大段摘抄、全篇都在贴源码的、人云亦云、含糊其辞 的搬运文。😡😠
这不仅不能 帮助读者迅速了解状况 —— 究竟是面临了什么问题，乃至于问世了这样的框架。反而还让人看了觉得云里雾里、白费大量时间。（例如，生命周期 “感知” 是一个十分抽象的术语，一味地用 “感知” 来自嗨，并不能让更多的人 “感知” 真实的状况）
更有甚者，完全脱离事实 去 意淫和鼓吹一些本不存在的职责和作用，给读者造成误导。
此外，考虑到前几期刚好是 完整地将 视图控制器的知识点 给过了一遍。
于是我打算趁热打铁地将 生命周期管理、状态管理、页面通信、路由跳转 的 Jetpack 最佳实践给大家过一遍。
也即接下来几期，我会分别解说 Lifecycle、ViewModel、LiveData、Navigation，来方便大家迅速理解真实的状况。😉
文章目录一览
- 前言
- 被提前提上日程的 Jetpack
- Lifecycle 的目标只有三个
- Lifecycle 问世前的混沌世界
- Lifecycle 为什么能解决这三个问题？
- 那 Lifecycle 具体是依赖什么机制运作的呢？
- 引入 Lifecycle 后的世界
- 综上
- 附注
- Note 2020.2.27 加餐：
- 造成人们误认为 “页面 onPause 时不会收到 LiveData 通知” 的原因
- Note 2021.2.21 加餐：
Lifecycle 的目标只有三个
Lifecycle 最早是在 support 26.1.0 时被引入的。它的设计是如此地成熟和应景，乃至于已经成为源码的一部分，而几乎无需使用者在 Gradle 额外地配置依赖。 [注1]
Lifecycle 的目标只有三个：
1.实现生命周期 管理的一致性，做到 “一处修改、处处生效”。
2.让第三方组件能够 随时在自己内部拿到生命周期状态，以便执行 及时叫停 错过时机的 异步业务 等操作。
3.让第三方组件在调试时 能够 更方便和安全地追踪到 事故所在的生命周期源。
此外不存在任何 个别人士讹传的其他作用！
划重点 👆👆👆
如果光是阅读了以上三点，你还是不太理解的话，那接下来我就分别介绍 99% 网文都不曾介绍的真实状况，来方便你迅速建立起感性的认识。😉
Lifecycle 问世前的混沌世界
例如我们开发了一个需要及时关闭资源的第三方组件 GpsManager。那么为了做到跟随生命周期及时启用或释放资源，我们分别需要在每个依赖 GpsManager 的 Activity 中调用 onResume、onPause 等方法。
并且为了能够 及时叫停 错过时机 的异步业务，来避免内存泄漏等情况发生，我们额外安排了 isActive 变量，以便能够及时从 Activity 拿到 “异步业务是否适合继续” 的指标，并在异步的业务中定期做出判断。
那这样带来一个什么问题呢？—— 复杂度激增导致的容易出错。
为什么呢？
因为我们需要为每个依赖 GpsManager 的 Activity 都安排好 生命周期调用 和 状态通知。
一旦 Activity 变多，就 难以保证修改的一致性，比如日后我在 ActivityA 修改了 GpsManager 生命周期的管理方式，而同事的 ActivityB 忘了被修改，这就造成了问题。
如果你对 “一致性” 的概念不太理解的话，那么请回顾一下大学时期 数据库课程中提到的 “存储过程”，它就是典型的 “一致性” 封装：将一套连贯的 SQL 序列封装在一个 “API” 中，外部人员只需调用这个 “API”，而无需知道内部具体发生了什么。
这避免了程序员 A 修改了某 SQL 语句，而程序员 B 没跟上。并且，“API” 的管理人只需一处修改，就能做到处处生效。
此外，对接收状态通知的需求，导致了我们可能需要在每个 Activity 中的每个生命周期回调额外安排上 setActive，这无疑又增加了复杂度。
再者，如果调试时，我想确知当前的事件源是哪个 Activity 呢？传统的方式只能额外地注入 Activity 到 GpsManager 中了。虽然如今倡导单 Activity App，使得 Activity 的生命周期基本和 Application 持平，而规避了一系列内存泄漏的问题，但如果事件源是 Fragment 呢？
Lifecycle 就是为解决上述三个问题而存在。
温馨提示：如果这是第一次接触《重学安卓》，可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容，以及了解它的最新动态 和 发展状况。
截至目前，专栏已对 体系化文章 做了 1270 余次修订，数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会，订阅后可随时进群交流。
前言
很高兴见到你！
前几期，我们在 全网独家 深度思考 的引导下，通过
重学安卓：Activity 生命周期的 3 个辟谣
重学安卓：绝不丢失状态的 Activity 重建机制！
重学安卓：你丢了 offer，只因拎不清 Activity 任务和返回栈
重学安卓：Intent 就是你的择偶标准啊！
重学安卓：我的碎片很听话，你的 Fragment 有自己的想法
分别正确理解了 视图控制器 Activity 和 Fragment 的 生命周期、重建机制、状态管理、路由跳转、页面通信 的 存在缘由、设计依据、职责边界 和 相互间关系。
相信阅读完这几篇的朋友，对视图控制器的脉络已形成深刻的印象。😉
被提前提上日程的 Jetpack
所以，本来我是想，紧接着出几期 “视图系统” 相关的解读，而 Jetpack 放在最后一期软件工程实战时统一介绍。
没想到在后台有读者留言说，期待能早日看到我对 Jetpack 的解说。
—— 是网上关于 Jetpack 的文章太少了吗？不是的，恰恰相反，网上的 Jetpack 文章一抓一大把，却基本上是 未经思考 就发布到网上 的 大段摘抄、全篇都在贴源码的、人云亦云、含糊其辞 的搬运文。😡😠
这不仅不能 帮助读者迅速了解状况 —— 究竟是面临了什么问题，乃至于问世了这样的框架。反而还让人看了觉得云里雾里、白费大量时间。（例如，生命周期 “感知” 是一个十分抽象的术语，一味地用 “感知” 来自嗨，并不能让更多的人 “感知” 真实的状况）
更有甚者，完全脱离事实 去 意淫和鼓吹一些本不存在的职责和作用，给读者造成误导。
此外，考虑到前几期刚好是 完整地将 视图控制器的知识点 给过了一遍。
于是我打算趁热打铁地将 生命周期管理、状态管理、页面通信、路由跳转 的 Jetpack 最佳实践给大家过一遍。
也即接下来几期，我会分别解说 Lifecycle、ViewModel、LiveData、Navigation，来方便大家迅速理解真实的状况。😉
文章目录一览
- 前言
- 被提前提上日程的 Jetpack
- Lifecycle 的目标只有三个
- Lifecycle 问世前的混沌世界
- Lifecycle 为什么能解决这三个问题？
- 那 Lifecycle 具体是依赖什么机制运作的呢？
- 引入 Lifecycle 后的世界
- 综上
- 附注
- Note 2020.2.27 加餐：
- 造成人们误认为 “页面 onPause 时不会收到 LiveData 通知” 的原因
- Note 2021.2.21 加餐：
Lifecycle 的目标只有三个
Lifecycle 最早是在 support 26.1.0 时被引入的。它的设计是如此地成熟和应景，乃至于已经成为源码的一部分，而几乎无需使用者在 Gradle 额外地配置依赖。 [注1]
Lifecycle 的目标只有三个：
1.实现生命周期 管理的一致性，做到 “一处修改、处处生效”。
2.让第三方组件能够 随时在自己内部拿到生命周期状态，以便执行 及时叫停 错过时机的 异步业务 等操作。
3.让第三方组件在调试时 能够 更方便和安全地追踪到 事故所在的生命周期源。
此外不存在任何 个别人士讹传的其他作用！
划重点 👆👆👆
如果光是阅读了以上三点，你还是不太理解的话，那接下来我就分别介绍 99% 网文都不曾介绍的真实状况，来方便你迅速建立起感性的认识。😉
Lifecycle 问世前的混沌世界
例如我们开发了一个需要及时关闭资源的第三方组件 GpsManager。那么为了做到跟随生命周期及时启用或释放资源，我们分别需要在每个依赖 GpsManager 的 Activity 中调用 onResume、onPause 等方法。
并且为了能够 及时叫停 错过时机 的异步业务，来避免内存泄漏等情况发生，我们额外安排了 isActive 变量，以便能够及时从 Activity 拿到 “异步业务是否适合继续” 的指标，并在异步的业务中定期做出判断。
那这样带来一个什么问题呢？—— 复杂度激增导致的容易出错。
为什么呢？
因为我们需要为每个依赖 GpsManager 的 Activity 都安排好 生命周期调用 和 状态通知。
一旦 Activity 变多，就 难以保证修改的一致性，比如日后我在 ActivityA 修改了 GpsManager 生命周期的管理方式，而同事的 ActivityB 忘了被修改，这就造成了问题。
如果你对 “一致性” 的概念不太理解的话，那么请回顾一下大学时期 数据库课程中提到的 “存储过程”，它就是典型的 “一致性” 封装：将一套连贯的 SQL 序列封装在一个 “API” 中，外部人员只需调用这个 “API”，而无需知道内部具体发生了什么。
这避免了程序员 A 修改了某 SQL 语句，而程序员 B 没跟上。并且，“API” 的管理人只需一处修改，就能做到处处生效。
此外，对接收状态通知的需求，导致了我们可能需要在每个 Activity 中的每个生命周期回调额外安排上 setActive，这无疑又增加了复杂度。
再者，如果调试时，我想确知当前的事件源是哪个 Activity 呢？传统的方式只能额外地注入 Activity 到 GpsManager 中了。虽然如今倡导单 Activity App，使得 Activity 的生命周期基本和 Application 持平，而规避了一系列内存泄漏的问题，但如果事件源是 Fragment 呢？
Lifecycle 就是为解决上述三个问题而存在。
