首发于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