本文章首发于公众号 Android丨Kotlin，欢迎关注！
对于在上一期《Jetpack 是什么？》的推送中，根据 Google 官方对 Jetpack 的定义，我们提炼出两个核心点：
-
它是一套组件库。
-
使用 Jetpack 可以帮助我们在不同的 Android 版本和不同的设备上，实现行为一致的工作代码。
同时，我也详细的对 Jetpack 85个组件库进行了分类和标记，一共分成了 7 个大类，帮助大家从全局的角度，理解这些组件库都是干什么的，方便我们快速的在不同场景下，选择合适的组件，帮助自己完成对应功能的实现。
没有看过的同学们，可以去翻翻之前的文章哦～
今天我们来聊聊定义中的第二个问题：为什么 Jetpack 可以帮助我们在不同的 Android 版本和不同的设备上，实现行为一致的工作代码？
Jetpack、AndroidX 以及 Support 库的关系
Jetpack 和 AndroidX 是同一个东西，从产品的维度它叫做 Jetpack，从技术的维度它叫做 AndroidX。目前 Jetpack 中所有的组件库的包名都是以 AndroidX 开头的。
在 18 年的 Google I/O 上，Android 团队首次向大家介绍了新的支持库：AndroidX 的 Alpha 版本，可以说 AndroidX 的出现就是为了解决长久以来 Support 库混乱的问题，你也可以把 AndroidX 理解为更强大的 Support 库。
Support 库是干什么的？
早之前的 Android 更新迭代是，所有的功能更新都是跟随着每一个特定的 Android 版本所发布的，例如 Fragment 是在 Android 3.0 更新的，Material Design 组件是在 Android 5.0 上更新的，由于 Android 用户庞大，每一次 Android 更新都无法覆盖所有用户的，同时因为手机厂商众多，但支持有限，也无法为自己生产的所有设备保持迭代到最新的 Android 版本，所以用户所持有的设备上 Android 版本是层次不齐的。
从技术的角度来说，因为用户的设备版本不一致，导致 Android 工程师在维护项目的时候，会遇到很多难以解决的问题。
为了解决这些由于 Android 版本不一致而出现的兼容性问题，Google 推出了 Support 库。
Support 库是针对 Framework API 的补充，Framework API 跟随每一个 Android 版本所发布，和设备具有强关联性，Support API 是开发者自主集成的，最终会包含在我们所发布的应用中， 这样我们就可以在最新的 Android 版本上进行应用的开发，同时使用 Support API 解决各种潜在的兼容性问题，帮助开发者在不同 Android 版本的设备上实现行为一致的工作代码。
Support 库有什么弊端？
最早的 Support 库发布于 2011 年，版本号为：android.support.v4 ，也就是我们所熟知的 v4 库，2013 年在 v4 的基础上，Android 团队发布了 v7 库，版本号为：android.support.v7，之后还发布了用于特定场景的 v8、v13、v14、v17。
如果是前几年刚开始学习 Android 的同学们，一定都对这些奇怪的数字很疑惑，4、7、8、13、14、17 到底都是什么意思？
拿第一代支持库 v4 举例，最初本意是指：该支持库最低可以支持到 API 4 的设备，v7 表示最低支持 API 7 的设备，但随着 Android 版本的持续更新，API 4 以及 API 7 的设备早就淘汰了。
在 2017 年 7 月 Google 将所有支持库的最低 API 支持版本提高到了 API 14，但由于包名无法修改，所以还是沿用之前的 v4、v7 命名标准，所以就出现了 Support 库第一个无法解决的问题：版本增长混乱。
与此同时 Support 库还面临一个非常严峻的问题：架构设计本身导致的严重依赖问题。 最早的 Support 库是 v4，v7 是基于 v4 进行的补充，因为 v4、v7 太过庞大，功能集中，所以如果想要开发新的支持库，也只能在 v4、v7 的基础上进行二次开发，比方说我们后期常用的，RecyclerView、CardView 等等。
这样就会产生很严重的重复依赖的问题，在无论是使用官方库，还是第三方库的时候，我们都需要保持整个项目中 Support 库版本一致，我相信很多人都在这个问题上踩过坑，虽然还是有办法解决这个问题，但无形中增加了很多工作量。
我们都知道 “组合优于继承” 这句话，但 Support 库在最初的架构设计上，却采用了重继承轻组合的方式，我猜这可能是因为开发 Support 库的人和开发 Framework API 的是同一批人有关，Framework API 里有种各种继承逻辑，例如我们常用的 Activity、Fragment、View。
虽然在后期 Google 尝试拆分 Support 库，例如推出了独立的支持库：support:design、support:customtabs 等，但并不能从根源解决依赖的问题。
Jetpack 的出现
所以为了彻底解决这两个致命的问题：
-
Support 库版本增长混乱
-
Support 库重复依赖
Google 重写了 Support 库，推出了新的 AndroidX，AndroidX 将原有的 Support 库拆分为 85 个大大小小的支持库，抛弃了之前与 API 最低支持相关联的版本命名规范，重置为1.0.0，并且每一个库在之后都会按照严格的语义版本控制规则进行版本控制。
同时通过组合依赖的方式，我们可以选择自己需要的组件库，而不是像 Support 一样全部依赖，一定程度上也减小了应用的体积。
到这里，如果你理解了最早 Support 出现的目的，那你应该就会明白为什么 Jetpack 可以帮助我们在不同的 Android 版本和不同的设备上，实现行为一致的工作代码。
很重要的一点，就是它不会随着特定的 Android 版本而更新，它是由开发者自主控制，同时包含在我们所发布的应用程序中。
如果 Jetpack 仅仅是针对 Support 库的重构，那它并没有了不起的，因为这只是 Google 解决了它自身因为历史原因所产生的代码问题。
更重要的是 Jetpack 为大家提供了一系列的最佳实践，包含：架构、数据处理、后台任务处理、动画、UI 各个方面，无需纠结于各种因为 Android 本身而出现的问题，而是让我们把更多的精力放在业务需求的实现上，这才是 Jetpack 真正了不起的地方。
例如想要安全异步的处理数据，现在有 DataStore；想要方便的实现依赖注入，现在有 Hilt；想要实现安全的页面导航，现在有 Navigation；想要实现 MVVM 架构，有 LiveData、ViewModel 帮助你。
如果你像我一样经常关注 Android 的官方文档，你会发现，上面的解释、例子、最佳实践相较之前变得详细了很多，同时更新也非常频繁，如果你是一个 Android 新手，那么去读一遍 Android 的官方文档对你入门非常有帮助，如果你是一名资深的 Android 开发，持续关注 Android 的官方文档的更新，这样才不会被技术所淘汰。
如果说 Android 的前十年是凭借着开源社区繁荣的生态而发展，那么我认为后十年 Jetpack 可以帮助 Android 变得更好。
感谢大家收看本期的文章，可以留言告诉我，关于 Jetpack 你想知道什么？之后我会为大家带来更多有关 Jetpack 的文章。
如果本期的内容有帮助到你，希望可以转发、评论和点赞，让更多人看到这篇文章，这也会对我有非常大的帮助。
感谢，我们下期再见。
