首发于Android架构解析写文章Android开发，你所不知道的Android原生开发的现状奶盖Android高级开发工程师15 人赞同了该文章原文地址：The State of Native Android Development, November 2019原文作者：Vasiliy Zukanov
Android原生开发的生态一直在不断地发展变化，过去5年从事android开发的经历让我深刻的体会到了这一点。每隔2到3年，谷歌就会发布一些的新的开发指导建议、libraries、frameworks，我花了很多时间来认真审查这些变化并从中找出可能存在的问题。我相信许多Android开发者都有我这样类似的经历。然而，2019年绝对是Android原生开发生态发生剧变的一年。在这一年里，Android sdk添加了许多新的内容、重写和移除了一些旧的内容，官方的开发者指南也进行了大幅度的更新。想要对Android开发有一种完整而又详细的认识实在是太难了。
于是我写下了这篇文章，我试图去总结Android生态系统中所发生的事情，并对原生开发的未来做出一些预测。接下来我会把我的观点分成不同的章节来进行具体的阐述，文章的最后我会一些极具争议的观点。
我希望这篇文章会对你们有所帮助，但是请记住，文章中肯定遗漏了许多重要的内容，而且其中的许多观点都是我个人的偏见。
AndroidXAndroidX的预览版是在一年半前发布的。大约一年前它变得稳定了，与此同时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库时进行紧急的迁移
Jetpack在讨论完AndroidX之后，就不得不提到Jetpack了。 据我所知，Jetpack最初只是“architecture components”的工具集合，但是后来扩展为包含了AndroidX的大多数（甚至所有）API的工具集合。 因此，到目前为止，我还没有看到AndroidX和Jetpack之间有任何有意义的区别，市场营销和公关宣传除外。
再看看下面这些app：
如果Jetpack申请2020年独立IPO，我不会感到惊讶，因为他们是如此的专注于营销和公关。
不过说真的，这种向自己的生态系统中的开发人员“销售”api的做法存在一些深层次的问题。比如，为什么有人真的想在搜索中宣传ViewModel？
总而言之，由于Jetpack的大部分内容都是来源于AndroidX，所以我之前写的有关AndroidX的内容在很大程度上也适用于Jetpack。
下面，我将分别讨论其中一些具体的API。
Background Work当应用程序不在前台时让应用也能执行操作是Android开发中最常见的场景之一。 在引入doze模式、SyncAdapter、GCMNetworkManager、FirebaseJobDispatcher、JobScheduler以及最近的WorkManager之前，您可以通过启动服务（而不是绑定服务）来实现。 这些都是Google自己的API，不过也有很多第三方解决方案，比如Android-Job。
但是，Google最近宣布，他们将通过WorkManager API来统一后台任务的调度。 听起来很不错，但是由于某种原因，当我听到这样的声音时，我总有种似曾相识的感觉……
Android系统的后台任务执行与调度是一团糟，碎片化使得它非常细微且不可靠。
过去，我一直主张尽可能的将数据同步等类似的工作放在后台来执行，我可能是SyncAdapter的最后一批粉丝。 但是今天，鉴于可靠性问题，我主张相反的做法：尽可能避免在后台执行操作。 如果您的PM坚持使用此功能，请向他们展示以上链接，并向他们解释，后台任务需要花费数百小时的时间来实现，而且带来的麻烦多于收益。
有些时候执行后台任务是不可避免的，但是在大多数情况下，您可以不这样做。即使以给用户带来一些不便为代价，它也可能是最佳选择。
Databases毫无疑问，Room在众多SQLite的ORM框架中占据着主导地位。从2.2.0开始，Room支持增量注解处理。不过请记住，您的应用架构不应过于关心使用了哪种ORM框架。因此，作为architecture components的一员，Room只是市场术语，而不是技术角色。
Android开发中ORM框架的主要竞争者是SQLDelight。 这个库比Room还要老，但是据我了解，在过去的一年左右的时间里，它已经被重写了很多。 不幸的是，它现在只针对Kotlin。 另一方面，SQLDelight支持Kotlin跨平台。 因此，随着Kotlin使用率的增加，我预计SQLDelight的使用率也会随之增加。
顺便说一下，AndroidX中有对原生SQLite的使用说明，我还不知道该怎么使用。但是如果您想在应用中使用原生SQLite，那么你或许需要去认真的研究下这个主题。
此外还有许多针对Android的非关系型的数据库，例如Realm，Parse，Firebase，ObjectBox等（其中有些仍在使用SQLite）。如果我没记错的话，它们中的大多数（甚至全部）都具有自动数据同步功能。 一段时间以来，这些解决方案比较流行，但据我所知，它们已经不复存在了。但是我并不会马上认为非关系型的数据库不再重要了。
去年，我编写了一个非常复杂的集成了Parse Server的Android应用。 我使用了Android版本的的Parse SDK，体验都非常好。如果您的公司已经雇用了许多后端开发人员，或者您需要实现许多服务器端逻辑，这可能不是最佳解决方案，但是对于仅在后端执行CRUD操作的初创企业和个人来说，这可能会是一种好的选择。
但是我必须提醒的一点是：如果您要采用数据库即服务的解决方案（例如Firebase），那么请务必了解其长期的成本和影响。
External Storage关于外部存储的开发，这里有许多有“意思”的事情。
如果您应用的target sdk版本等于或者大于29，那么你的应用将无法再正常访问手机外部存储上的文件，除了少数几种明显的情况。 相反，您需要使用SAF框架（据说），该框架允许用户进行更精细的访问管理。不幸的是，SAF的工作方式与之前完全不同，因此某些应用程序可能需要进行重大重构。
Google希望从Android 10开始对所有的应用程序都实行这一要求，但它引起了开发者社区的强烈抗议，于是他们决定推迟此功能。 因此，即使您的应用设置target sdk版本为 29，它仍可以在“旧版”模式下工作。 但是，无论目标API级别是多少，下一版的Android系统都将对所有应用的存储访问范围做更加严格的限制。
到目前为止，我还没有使用SAF框架，但是从我在互联网上阅读的许多讨论中看来，这可能是一项艰巨的任务。因此，如果您的应用程序还在以“旧版”模式使用外部存储，那么最好立即开始进行重构和测试。
Shared Preferences几周前，AndroidX系列中添加了一个新框架。 它的commit message是这么说的：
New library meant to replace SharedPreferences. The name is not final, this is just for implementation review and to support the design doc (feel free to request the