看看这些“感言”:
再看看下面这些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来统一后台任务的调度。听起来很不错,但是由于某种原因,当我听到这样的声音时,我总有种似曾相识的感觉……
无论最终能否统一,WorkManager都无法解决在执行后台任务过程中存在的一个最严重的问题:可靠性。我在这里不做解释,但是请记住,如果您需要在应用程序中执行后台任务,请先阅读dontkillmyapp.com上的所有信息。此外,请在Google的issue tracker中阅读并加注星标。
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,体验都非常好。如果您的公司已经雇用了许多后端开发人员&#x