总而言之 ， 在新的 Android 项目中 ， 建议直接使用 AndroidX 。并且 ， 针对老项目 ， 我也推荐你们将迁移到 AndroidX 列到计划中 ， 虽然现在你看不到迁移 AndroidX 过后 ， 带来的任何收益 。无论如何 ， 你都有可能在某个时间点进行 AndroidX 的迁移 ， 所以最好能够按照自己的进度进行迁移 ， 而不是在 6 个月后 ， 你需要使用某个新的 AndroidX 库时 ， 再进行紧急迁移 。

文章插图
Jetpack
在讨论 AndroidX 过后 ， 还必须要提到 Jetpack 。在我的印象中 ， Jetpack 开始是作为“架构组件”的一把保护伞推出的 。但是到后面 ， 引入了几乎所有关于 AndroidX 的 API 。因此 ， 现在来看 ， 我们看不到它与 AndroidX 之间的任何区别 ， 除了 Marketing 和 PR（即市场和公关） 。
当你查看 Jetpack 主页[2]时 ， 会发现 ， 这个页面并不是一个技术文档页面 。这个更像是一个早期的 SaaS 页面 。
看看例子 ， 开发者“赞誉”：

文章插图
开发者赞誉
或者“信赖应用”列表：

文章插图
信赖应用
这些在市场公关层面更受关注 ， 如果 Jetpack 在 2020 年申请独立 IPO ， 我都不会感到惊讶 。
不过 ， 说真的 ， 尝试向自己生态系统内的开发者“销售”API 的想法 ， 我觉得存在一些问题 ， 比如说 ， 谁会想看搜索出来第一个就是 ViewModel 广告呢？

文章插图
Android ViewModel
总而言之 ， Jetpack 只是 AndroidX 库的一个聚合 ， 所以在前面写到的 AndroidX 的内容 ， 在很大的程度上也适用于 Jetpack 。在后面的内容中 ， 我将单独讨论其中一些 API 。

文章插图
后台作业
在 Android 应用程序不在前台执行逻辑时 ， 你可以有很多种方式来实现后台运行 ， 这也是 Android 动态化的用例之一 。如果你不引入 doze , SyncAdapter , CGMNetworkManager , FirebaseJobDispatcher , JobScheuler 和最近的 WorkManager ， 可以使用常规的启动服务（非绑定服务）来实现 。这些都是 Google 提供的 API  ，  我可以说出所有的使用方式 。当然 ， 还有一些第三方库可以使用 ，  例如：Android-Job 。
不过 ， Google 最近宣布 ， 他们将围绕 WorkManager 来统一后台任务调度[3] 。这听起来非常棒 ， 我再也不用学习那么多后台调度的知识了 ， 只是 ， 不知道为什么 ， 我好像以前在哪儿听到过这句话……
我们不管将来是否会统一使用 WorkManager ， WorkManager 都还存在一些问题 ， 比如可靠性 。我不想在本文中解释为什么 ， 但是请你一定要记住 ， 如果你想在应用程序中使用 WorkManager ， 实现后台作业 ， 一定要去读一下 dontkillmyapp.com 上的所有内容 ， 并且要关注一下与 WorkManager 相关的 Google 问题列表[4] 。
Android 的后台作业由于碎片化等原因 ， 导致它们一团糟 ， 而且还很不可靠 。

• technican technocracy工具