然而，2019年绝对是Android原生开发生态发生剧变的一年。在这一年里，Android sdk添加了许多新的内容、重写和移除了一些旧的内容，官方的开发者指南也进行了大幅度的更新。想要对Android开发有一种完整而又详细的认识实在是太难了。

于是我写下了这篇文章，我试图去总结Android生态系统中所发生的事情，并对原生开发的未来做出一些预测。接下来我会把我的观点分成不同的章节来进行具体的阐述，文章的最后我会分享一些极具争议的观点。

我希望这篇文章会对你们有所帮助，但是请记住，文章中肯定遗漏了许多重要的内容，而且其中的许多观点都是我个人的偏见。

AndroidX的预览版是在一年半前发布的。大约一年前它变得稳定了，与此同时Google也停止了对旧版Support Library的进一步开发。 当我写下这句话的那一刻，我想起了我之前在StackOverflow上提出的一个问题：Why does AOSP add new APIs to support libraries without adding them to SDK?，当时我是一个android开发新手，我想知道Support Library背后的动机，Googl为什么不直接把Support Library放到android sdk里呢？

不过使用“稳定”一词来描述AndroidX似乎有点讽刺，因为关于AndroidX的任何信息似乎都不是稳定的。 Google不断的在往AndroidX里添加新的库和框架。 命名空间和许多旧的API（目前还不到一年）正在以非常快的速度发展。

到目前为止，我已经将我的两个应用迁移到了AndroidX。 一切都很顺利，但我也不觉得有多惊喜。 Jetifier是一种将Support Library上的依赖项重定向到其AndroidX对等项的工具，转换效果令人惊讶。 但是即使应用程序不大，也并不是“一键式迁移”。

我还参与了一个尚未迁移到AndroidX的项目，没有任何问题。在某些情况下，似乎我完全不需要AndroidX。

总而言之，我想说的是：如果是开启新的Android项目，那么肯定是应该使用AndroidX；对于现有的项目，我也建议您做好迁移到AndroidX的计划，即使您现在看不到明显的好处。 无论如何，您很可能都需要迁移，因此最好按自己的计划进行迁移，而不是以后当你需要一些新的AndroidX库时进行紧急的迁移

在讨论完AndroidX之后，就不得不提到Jetpack了。 据我所知，Jetpack最初只是“architecture components”的工具集合，但是后来扩展为包含了AndroidX的大多数（甚至所有）API的工具集合。 因此，到目前为止，我还没有看到AndroidX和Jetpack之间有任何有意义的区别，市场营销和公关宣传除外。

当您访问Jetpack的官方网站时，它看起来不像是技术文档，更像是早期SaaS初创公司的主页。

看看这些“感言”：

再看看下面这些app：

如果Jetpack申请2020年独立IPO，我不会感到惊讶，因为他们是如此的专注于营销和公关。

不过说真的，这种向自己的生态系统中的开发人员“销售”api的做法存在一些深层次的问题。比如，为什么有人真的想在搜索中宣传ViewModel？

总而言之，由于Jetpack的大部分内容都是来源于AndroidX，所以我之前写的有关AndroidX的内容在很大程度上也适用于Jetpack。

下面，我将分别讨论其中一些具体的API。

当应用程序不在前台时让应用也能执行操作是Android开发中最常见的场景之一。 在引入doze模式、SyncAdapter、GCMNetworkManager、FirebaseJobDispatcher、JobScheduler以及最近的WorkManager之前，您可以通过启动服务（而不是绑定服务）来实现。 这些都是Google自己的API，不过也有很多第三方解决方案，比如Android-Job。

但是，Google最近宣布，他们将通过WorkManager A