温馨提示:如果这是第一次接触《重学安卓》,可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容,以及了解它的最新动态 和 发展状况。
截至目前,专栏已对 体系化文章 做了 1070 余次修订,数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会,订阅后可随时进群交流。
前言
很高兴见到你!
前几期,我们在 全网独家 深度思考 的引导下,通过
重学安卓: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 通知” 的原因
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,这无疑又增加了复杂度。
温馨提示:如果这是第一次接触《重学安卓》,可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容,以及了解它的最新动态 和 发展状况。
截至目前,专栏已对 体系化文章 做了 1070 余次修订,数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会,订阅后可随时进群交流。
前言
很高兴见到你!
前几期,我们在 全网独家 深度思考 的引导下,通过
重学安卓: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 通知” 的原因
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,这无疑又增加了复杂度。
温馨提示:如果这是第一次接触《重学安卓》,可借助 这份在 GitBook 上维护的 “导读” 来快速了解《重学安卓》专栏、获取它的目录、试读内容,以及了解它的最新动态 和 发展状况。
截至目前,专栏已对 体系化文章 做了 1070 余次修订,数十位群友告诉我 受专栏的启发 他们也开启了写作之路。群里不定期会有小伙伴讨论适配问题、分享原创的开源库 和 提供内推机会,订阅后可随时进群交流。
前言
很高兴见到你!
前几期,我们在 全网独家 深度思考 的引导下,通过
重学安卓: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 通知” 的原因
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,这无疑又增加了复杂度。