AndroidX 的前世此生

本文章首发于公众号 Android丨Kotlin，欢迎关注！android

对于在上一期《Jetpack 是什么？》的推送中，根据 Google 官方对 Jetpack 的定义，咱们提炼出两个核心点：安全

它是一套组件库。markdown
使用 Jetpack 能够帮助咱们在不一样的 Android 版本和不一样的设备上，实现行为一致的工做代码。架构

同时，我也详细的对 Jetpack 85个组件库进行了分类和标记，一共分红了 7 个大类，帮助你们从全局的角度，理解这些组件库都是干什么的，方便咱们快速的在不一样场景下，选择合适的组件，帮助本身完成对应功能的实现。app

没有看过的同窗们，能够去翻翻以前的文章哦～异步

今天咱们来聊聊定义中的第二个问题：为何 Jetpack 能够帮助咱们在不一样的 Android 版本和不一样的设备上，实现行为一致的工做代码？ide

Jetpack、AndroidX 以及 Support 库的关系

Jetpack 和 AndroidX 是同一个东西，从产品的维度它叫作 Jetpack，从技术的维度它叫作 AndroidX。目前 Jetpack 中全部的组件库的包名都是以 AndroidX 开头的。oop

在 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，以后还发布了用于特定场景的 v八、v1三、v1四、v17。

若是是前几年刚开始学习 Android 的同窗们，必定都对这些奇怪的数字很疑惑，四、七、八、1三、1四、17 到底都是什么意思？

拿第一代支持库 v4 举例，最初本意是指：该支持库最低能够支持到 API 4 的设备，v7 表示最低支持 API 7 的设备，但随着 Android 版本的持续更新，API 4 以及 API 7 的设备早就淘汰了。

在 2017 年 7 月 Google 将全部支持库的最低 API 支持版本提升到了 API 14，但因为包名没法修改，因此仍是沿用以前的 v四、v7 命名标准，因此就出现了 Support 库第一个没法解决的问题：版本增加混乱。

与此同时 Support 库还面临一个很是严峻的问题：架构设计自己致使的严重依赖问题。 最先的 Support 库是 v4，v7 是基于 v4 进行的补充，由于 v四、v7 太过庞大，功能集中，因此若是想要开发新的支持库，也只能在 v四、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 的文章。

若是本期的内容有帮助到你，但愿能够转发、评论和点赞，让更多人看到这篇文章，这也会对我有很是大的帮助。

感谢，咱们下期再见。