Kotlin-风险高、RxJava-不老，Android-原生开发现状分析

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

Shared Preferences

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

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

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

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

如果你对这种异步回调的原理感兴趣，你可以去看看 StackOverflow 上的这个回答。Reddit 的一个用户 Tolriq 分享了他们的 App 遇到的一个 SharedPreferences 的 Bug，这个问题影响了万分之一的月活用户。对于一般的应用程序来说，这个问题并没有什么明显的影响。但在一些需要高可靠性的应用上，就显得很不可靠了。举个例子，如果在 Android 汽车上，应用程序的无响应和崩溃会引起驾驶员的注意力被分散，这将有可能导致出现交通意外。

依赖注入

在依赖注入领域，最大的新闻莫过于 Dagger-Android 被弃用，有两点需要强调一下，首先我所说的弃用，不是正式的弃用，因为官方并没有发布声明。其次，Dagger-Android 并不是指整个 Dagger 2 框架，只是指其中相对比较新的部分。详细细节可以看我的另一篇文章[8]。

在 Android 领域也存在其他的依赖注入框架，但是我不认为他们会比 Dagger 更好。值得一提的是，Koin 是一个不错的依赖注入框架，但是我依然觉得它也不会引起多大的潮流。它之所以会被采用，无非是这两个原因，一个是，它拥有比 Dagger 好很多的文档，降低了很大的学习成本。第二个是它基于 Kotlin 进行编写，因为 Kotlin 的热度，给它也带来了不少的关注。到目前为止，Kotlin 的热潮几乎已经全部过去了，所以，我预测，Koin 的关注也将会逐渐减少。

不管这些框架如何发展，手动依赖注入的发展都会很缓慢。

Google 声称：随着应用程序的增大，手动依赖注入的成本会出现指数级增长。但是我并不这么认为，我觉得 Google 既不了解 “指数” 的含义，也没有实际去“衡量”过任何东西。这个申明的内容是错误的，我希望 Google 不再使用这种方式误导社区。

事实上，这种手动依赖注入在后端比较常见（尤其是微服务中，你并不想在每个服务中都添加对注入框架的依赖），也可以正常的工作。在后端，反射被经常用到，所以后端的依赖注入框架并不需要解析编译时的代码。

在 Android 上，解决方案与后端有一些不同，我们几乎不会用反射方案的依赖注入框架，所以就只剩下 Dagger 可以用了。其实，反射虽然会影响性能，但是在大多数项目，都是可以用的。我的意思并不是建议你们使用反射方案的依赖注入框架，这个选择并非是非黑即白的，你需要按照你的要求来进行选择。

无论如何，Android 领域上， Dagger 作为依赖注入框架的现行标准，我们所有人都在使用它。尽管 Google 在宣传上，对 Dagger 的使用成本使用漂亮的绿色图形进行展示，但是 Dagger 使用成本在实际上依然会随着时间增长而快速增长。越来越多的代码，在编译构建的时候需要花费更多的时间；你的开发人员越多，代码编译的次数就越多。当然，所有的开发人员都需要学习如何使