Kotlin-风险高、RxJava-不老,Android-原生开发现状分析!(1)

本文分析了Android开发的现状,重点关注Kotlin和RxJava的使用。作者指出Kotlin逐渐成为主流,但其编译时间问题仍然存在。RxJava虽然常见,但可能正逐步退出历史舞台,被Kotlin的协程替代。数据库方面,Room占据主导,而SQLDelight在更新后更专注于Kotlin。外部存储、Shared Preferences、数据绑定等方面也有所变化,建议开发者关注新技术和最佳实践。
摘要由CSDN通过智能技术生成

在过去,我一直主张尽可能对数据和其它类型的后台处理进行同步。我或许是 SyncAdapter 最后的粉丝。今天,考虑到可靠性的问题,我建议,尽可能避免后台作业。如果你的老板一直坚持要使用这个功能,请将上面的链接发给他们,告诉他们,后台作业可能会需要数百小时的工作,才能实现,并且它带来的问题也会比它带来的好处多很多。

很多情况下,后台作业的需求是不可避免的。但是在大多数情况下,你都可以不使用它。虽然有时候会给用户带来一些不便,但是这可能是到目前为止的最佳方案。

数据库

在有关 SQLite ORMs 的内容里面,没有什么令人吃惊的内容—— Room 主宰着一切。Room 从 2.2.0 开始,添加增量注解解析支持。不过,请你一定要记住,你应用程序的架构不应该关心你使用的是什么样的 ORM 框架。说到 Room,“架构组件”也只是一个营销术语,并不是一个技术角色。

在 Android ORM 框架中,与 Room 竞争的主要是 SQLDelight。这是一个比 Room 老很多的库。但是据我所知,**在过去的一年里,它几乎被全部重写。****但新版本的 SQLDelight 只针对 Kotlin。**另一方面,SQLDelight 也支持 Kotlin Multiplatform,所以,随着 Kotlin 使用的增多,我预计, SQLDelight 的采用率也会随之增加。

顺便说一下,在 AndroidX 的命名空间下,也有 SQLite 的镜像。我不知道这个会有什么用处,但是如果你在应用程序中直接使用 SQLite,也可以对这个进行深入的研究。

此外,我们也不要忘记非关系型数据库,比如 Realm、Parse、Firebase、ObjectBox 等等 (其中一些,核心还是使用的 SQLite 来实现的),如果我没有记错的话,这些非关系型数据库中,大多数(甚至全部)都具有自动数据同步的功能。在之前有段时间里,它们非常地流行。但是现在,据我所知,已经不再流行了。也就是说,在短期内,我会持续关注非关系型数据库。

去年,我写了一个非常复杂的应用程序,对接了一个 Parse 的服务。这个 App 具有完全的离线支持,服务端本地化,用户指定的系统和语言设定,复杂的多媒体系统等功能。我在 Android 端上使用了 Parse 的 SDK。除了一些小的 WTF 以外,其他体验都非常棒。如果你们公司有很多后台开发人员,或者说你需要实现大量的服务端逻辑,这也许并不是最佳解决方案。但是对于仅仅只需要执行简单的 CRUD 操作的初创公司,这或许是一个不错的选择。

一个警告:如果你打算采用数据库即服务解决方案(如 Firebase),请你一定要关注长期使用的成本和影响。

外部存储

Android 外部存储发生了一个“很有意思”的变动。

如果,你在开发 App 的时候,把 Target API 调整为 29 及以上,之前获取 SD 卡文件的方法,现在都不能使用了,并且不会提示任何异常。现在,你需要使用 Android 存储访问框架来进行更细粒度的文件访问。不幸的是,Android 存储访问框架的工作原理与之前的读取方式完全不同,你可能需要对代码进行大量的重构,来实现新的文件访问和读取。

Google 原本希望在 Android 10 上,对所有的应用程序进行文件访问的限制,推广使用 Android 存储访问框架的方式进行文件访问。但是这个改动引起了社区内的强烈抗议,所以 Google 决定推迟推出这个功能。因此,现在即使你的应用程序在 Target API 29 及以上,也可以设置为在“Legacy”模式下可读取文件。不过,有可能在 Android 的下一个版本,不管你设置的 Target API 为多少,都会限制应用程序使用新的作用域访问模式。

到目前为止,我也还没有更新我应用程序的文件访问方式。但是从互联网上的讨论来看,实现新的文件访问方式是一项很具挑战的任务,虽然你的应用程序在“Legacy”模式下,没有任何异常,但是我建议你最好从现在开始,着手对代码进行重构和测试,以防发生不可控的事情。

Shared Preferences

在几周前,AndroidX 家族增加了一个新的库,这条提交信息写道:

新的库用来替换 SharedPreferences,新库的名称还没有确定下来,这次提交只是为了评审和设计文档(请自行申请设计文档)。

现在还没有什么值得担心的。不过,从长远来看,SharedPreferences 会被废弃掉,取而代之,使用新的库来实现类似的功能。

与 SharedPreferences 不同的是,这个新的库默认情况下使用的是异步的方式。换句话说,如果你需要取某个值,你需要实现回调,通过这个回调才能拿到值。

如果你对这种异步回调的原理感兴趣,你可以去看看 StackOverflow 上的这个回答。Reddit 的一个用户 Tolriq 分享了他们的 App 遇到的一个 SharedPreferences 的 Bug,这个问题影响了万分之一的月活用户。对于

  • 22
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值