Android开发，你所不知道的Android原生开发的现状

此外还有许多针对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 design doc privately)[…]

目前我们无需担心，但从长远来看，似乎SharedPreferences会被重写，我们需要使用这种新的方法。

SharedPreferences和这个新框架之间的主要区别在于，[默认情况下后者是异步的](()。换句话说，您需要实现一个回调以获取特定键的值，该回调将在以后的某个时间收到通知。

如果您对这种异步通知的机制感到好奇，则可以阅读StackOverflow上的这个[答案](()。 Reddit用户Tolriq在这里分享了他们遇到此bug的概率。在他们的应用中，这个bug会影响1 / 10,000 / SESSIONS_PER_USER_PER_MONTH的用户。对于一般的应用程序，这可能微不足道。但是在需要高可靠性的情况下，这可能会引起严重的后果。例如，在装有Android Auto的汽车中，应用程序挂起和随后的崩溃会分散驾驶员的注意力，这可能会导致非常不幸的后果。

[](()Dependency Injection

在依赖注入方面，最大的变化就是Dagger-Android的弃用。这里我想解释两点：首先，我说的弃用并不是指“正式”弃用，因为它尚未正式弃用。其次，Dagger-Android并不是整个Dagger2框架，而只是相对较新的功能。我在这个主题上写了一篇非常详尽的[文章](()，所以我在这里不再重复。

至于其他依赖注入框架，我不认为它们是Dagger的真正竞争者。例如，Koin也许不错，但我认为它不会吸引 《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》无偿开源徽信搜索公众号【编程进阶路】 很多人。实际上，我相信它仅由于两个主要原因而得到了初步采用。第一个是Dagger的糟糕文档，Koin在这方面要比Dagger领先N光年。第二个原因是Koin是用Kotlin编写的，它借着kotlin发展的浪潮开始兴起。到目前为止，这波浪潮已经几乎消逝。

我认为可能会发生的情况是，纯依赖注入的框架（又称为手动依赖注入）会逐渐出现。

现在，谷歌声称[“随着应用程序的不断增大，手动依赖项注入成本呈指数增长”](()。我认为，这仅表明他们既不了解“指数”的含义，也没做过任何实际的“测量”。此声明是完全错误的，我希望Google不要以这种方式来误导社区里的开发者了。

事实上，纯依赖注入在后端开发中非常普遍（尤其是在开发微服务的时候，您不想在其中添加对每个服务的框架的依赖），反射也是后端开发中的一个有效的选项。因此，如果要使用依赖注入框架，他们通常不需要解析编译时代码。

但是，Android开发的情况有所不同。由于我们不能使用反射式DI框架，所以我们使用了Dagger。事实上，我们可以使用反射式DI框架，并且对于大多数项目来说都可以，但是却存在性能问题。我并不是说使用反射式DI框架是安全的，但它绝对不是一种非黑即白的方案。无论如何，Dagger已经是在Android开发中使用依赖注入的事实上的标准，我们都使用它。但使用Dagger的代价也很明显：

1）应用的代码越多，在构建过程中运行注解处理所花费的时间就越多。
2）应用参与的开发人员越多，他们需要执行的构建次数就越多。
3）所有开发人员都需要学习Dagger ，这需要很多时间。

换句话说，虽然Dagger确实允许您编写更少的代码，但由于它会影响构建时间和所需的培训时间，因此在大型项目上它会花费更多的时间。

在大型项目中，构建时间慢才是真正的问题，并成为主要的生产力瓶颈。因此，尽管Dagger确实提供了非常出色的功能来简化DI（当然，一旦您知道如何使用它），但我相信我们对纯依赖注入会产生越来越多的兴趣。

[](()DataBinding

开发人员采用DataBidning的主要原因之一是不再需要调用findViewById（）了。老实说，findViewById确实很冗余，我也不介意摆脱它们。但是，在我看来，调用findViewById（）带来的小麻烦并不能证明使用DataBinding是合理的。好消息是，很快我们将能够使用另一个新功能[ViewBinding](()来删除这些findViewById（）的调用。

实际上，我从来都不相信DataBinding。对于它（应该）解决的问题，我感觉太复杂了。此外，DataBinding允许开发人员将逻辑放入XML布局中。经验丰富的开发人员是不会使用这种方法的，因为这增加了项目维护的难度。这是DataBinding框架的另一个缺点。

早在2016年11月，当DataBinding正处于大肆宣传的顶峰时，我在StackOverflow上的一个[答案](()中做出了以下预测：

However, there is one prediction I can make with a high degree of confidence: Usage of the Data Binding library will not become an industry standard. I’m confident to say that because the Data Binding library (in its current implementation) provides short-term productivity gains and some kind of architectural guideline, but it will make the code non-maintainable in the long run. Once long-term effects of this library will surface – it will be abandoned.

现在，关于DataBinding的使用率，我没有任何统计数据，但是很明显，它并没有成为行业标准。我自己还从未见过使用DataBinding的专业项目，也很少见到在其应用中使用DataBinding的开发人员。据我估计，一旦ViewBinding成熟并被广泛采用，DataBinding将会更加流行，并成为“传统”框架。

[](()Preserving State on Configuration Changes

自从引入ViewModel之后，在Android应用中对于配置更改的处理就变得一团糟。我知道我的这种说法太苛刻了点，但实际上，这是我可以描述的最温和的表达方式。

对我来说幸运的是，Gabor Varadi（又名Zhuinden）已经在Reddit上的[这篇文章](()中对这一问题进行了总结，所以我不需要自己做。他的结论就是：不推荐使用onRetainCustomNonConfigurationInstance（），而推荐使用ViewModel。有趣的是，在该帖子的结尾，Gabor做了一些颇具嘲讽味道的预测：

你发现什么了吗？ [Retained Fragments现在已经被弃用了！](() 。

我认为，弃用Retained Fragments实际上是一个好主意。 Fragment的生命周期里具有onAttach（）和onDetach（）这两个方法的唯一原因就是为了支持Retained Fragments的使用。通过弃用Retained Fragments，这些方法也可以弃用，并且可以简化Fragment的生命周期。如果您使用[我的方法](()来处理Fragment的生命周期，那么这种弃用就不会让您感到困扰，因为我长期以来一直建议您避免Retained Fragments，忽略onAttach（）和onDetach（）方法。

尽管有充分的理由要弃用Retained Fragments，但弃用onRetainCustomNonConfigurationInstance（）却是胡说八道。这不是我说的，而是Jake Wharton说的（您可以在前面提到的Gabor在Reddit上的帖子下阅读他的原话）。

为什么要做这些变动呢？我只能看到一种解释：Google决定不管其它技术优势如何，都强制将所有Android项目迁移到ViewModel。他们愿意弃用所有现有的替代方案以实现其目标，即使这些替代方案实际上优于ViewModel本身。

听起来有点阴谋吧？我同意。但是，幸运的是，我们可以对此理论有一个简单的检验。

虽然我不喜欢Preserving State on Configuration Changes，但它不会以任何方式影响我，因为我没有使用它。实际上，绝大部分应用程序都不需要它。它们也不需要ViewModel。正确处理Configuration Changes的方式就是在onSaveInstanceState（Bundle）回调方法里增加处理逻辑。这是一种更简单，更好的方法，因为它还可以处理保存和恢复流程（也称为进程终止）。因此，只要我能以这种方式保存状态，就可以了。尽管Google进行了大量的营销和公关工作，但许多经验丰富的开发人员都意识到ViewModel太复杂了，并且有更好的方法来保留配置更改的状态。

因此，如果Google确实有别有用心，并且想迫使所有项目都使用ViewModel，那么他们还需要弃用onSaveInstanceState（Bundle）。我知道这听起来很疯狂，但这实际上是件好事，因为如果这种疯狂的预测成真，您就会知道基础理论是正确的。

但是，鉴于Android的内存管理机制，Google不能仅在不提供可靠替代方案的情况下就弃用onSaveInstanceState（Bundle）。 “幸运”的是，[这些变化已经应用在ViewModel的保存状态模块上了](()。

我想在一两年内我们就会知道这种做法是否有任何优点。‘

总而言之，正如我在本节开头所说的那样，自ViewModel发布以来，Android中的Configuration Changes就成了屎。两年多以前，当我撰写题为[“Android ViewModel Architecture Component Considered Harmful”](()的文章时，我预测ViewModels将是一种浪费。我的所有预测都是真实的，但不幸的是，事实证明真相比这还糟。

[](()Concurrency

在并发这方面，最大的变化就是AsyncTask的弃用。我已经写了一篇有关此主题的非常详细的[文章](()，并提出了具体建议，因此在此不再赘述。

接下来我说的话可能会使部分读者感到不满。拜托，别太把这事当真。

Android开发中另一个流行的多线程框架RxJava很快就会成为“过去式”。从下面这幅StackOverflow趋势图可以明显看出：

许多开发者会质疑我的观点，称该数据不具有代表性，并且还有其他方法的可以解释该图。他们可能是正确的，因为我自己也不是数据科学家。但是，在此图中，我看不到任何其他关于峰值的解释，而且RxJava的曲线与AsyncTask的曲线具有相同的斜率。

因此，如果您尚未花时间在学习RxJava上并且您的项目没有使用它，那么我建议您避免使用它。实际上，这一直是我的建议，今天它也得到了数据的支持。

如果您的项目已经使用了Rx，也请不要惊慌，您无需立即重构任何东西。但是，请记住，今后找到具有Rx经验的开发人员将越来越困难。因此，在项目中广泛使用Rx可能需要新的开发人员投入更多的时间。最终，广泛使用Rx的项目将被视为“not cool”（例如今天使用AsyncTask和Loaders的项目）。

我知道我的这些观点对于许多开发人员来说很不友好。他们花了数周时间来学习RxJava，甚至说服了同事在项目中使用RxJava，现在我却说它会成为“过去式”。我只想说我只是分析实际情况并根据我所看到的做出预测，我可能是错的，也可能是对的。

在Kotlin语言中，我们可以使用协程。我最近使用协程实现了[一些复杂的用例](()，发现此框架非常的细微和复杂，并且相对不成熟，我甚至发现了一个bug。

有一种流行的说法是，协程使得并发处理更简单。我从来不这样认为，因为我知道并发是非常复杂的，但是在我有了一些实践经验之后，我可以自信地说，协程并没有想像中的那么美好。在我看来，协程实际上增加了程序复杂性，所以我建议你们小心地使用它们。

另一方面，协程似乎将成为Kotlin语言里处理并发操作的默认方式。因此，我认为如果您编写Kotlin代码，您需要投入时间并学会使用它们。

据我所知，目前还有一个流式框架，它在协程之上添加了流处理操作符。几个月前才稳定下来，所以我现在还不能说什么。

[](()Kotlin

现在让我们来讨论一下Kotlin。根据以往的经验，我知道这是一个非常敏感的话题，而且不管我描述的多么客观，最终都会遭受一些开发者的攻击。然而，我认为在总结原生Android开发现状的时候跳过Kotlin是极不诚实的。因此，我再次请你不要把我说的话当真。

你所需要知道的一个重要的事实是：在Android开发中使用Kotlin会严重增加你的构建时间。

在这篇[文章](()中，您会了解到我在使用Kotlin进行开发时对构建时间所进行的统计测试的结果。clean build 增加了18%的构建时间，incremental build 增加了8%的构建时间。

[Uber与JetBrains也联合发表了他们自己的研究结果](()，他们的结果更为负面。如果您不在应用程序中使用注解处理器，那么引入Kotlin可能会使您的构建时间增加四倍！如果您使用了注解处理器，那么引入Kotlin会使您的构建时间增加50%-100%。

Uber的研究结果与[将OkHttp迁移到Kotlin版本](()后构建时间增加了4倍的结果是一致的。

如果您对这些数字感到惊讶，您不用担心-这不是您的错，而且您并不孤单。尽管这个事实极为重要，但它并未得到广泛讨论，并且我觉得Google也试图回避这个事实。我曾与Google内部一个熟悉此事的开发人员有过一次非常有趣的讨论，我问他是否可以讨论下这个话题，他说：“我不喜欢；我不喜欢；我不喜欢。这是一件很微妙的事情。”

除了增加构建时间之外，Kotlin还不支持增量注解处理，而在大约10个月前Java就已经支持增量注解处理了。

两年前，我写了一篇[文章](()来警告开发者们在早期使用Kotlin时可能会遇到的潜在风险。在很长一段时间内我被称为“kotlin的讨厌者”。

但是，如果您今天阅读这篇文章，您会发现我实际上低估了这些问题的严重性。在大型的Android项目上，构建时间是最糟糕的生产力杀手之一，而且即使在今天，即Kotlin被官方“正式采用”两年多之后的今天，Kotlin仍然不如Java。不管Kotlin带来什么其他好处，所有这些都可能由于更长的构建时间而被否定。

也就是说，我们不应改忽视这样一个事实：是谷歌将android开发的生态强行推向了kotlin，使得其使用率在稳步上升。

就我个人而言，我并没有在我目前已经开始的新项目中选择kotlin语言，我不想在kotlin上浪费我自己的时间。不过，从现在开始，我会认真考虑使用kotlin来开发新项目，我已经在几个demo上尝试过了。但是我不同意开发人员说你必须在新项目中使用Kotlin，这仍然是一种权衡。

Android开发，你所不知道的Android原生开发的现状相关推荐

android factory,“工厂映像”（factory image）是什么？你所不知道的Android问题
趋势网(微博|微信)讯: "工厂映像"(factory image)是什么?你所不知道的Android问题. 从多种选择中挑选自己喜欢的终端,从而使高度可定制成为可能,这便是And ...
Android 那些你所不知道的Bitmap对象详解
我们知道Android系统分配给每个应用程序的内存是有限的,Bitmap作为消耗内存大户,我们对Bitmap的管理稍有不当就可能引发OutOfMemoryError,而Bitmap对象在不同的Andr ...
阿里框架原声Android,阿里P8大佬亲自教你！你所不知道的Android原生开发的现状，含泪整理面经...
基本情况先说一下个人基本情况,计算机科学与技术专业.主要学的Android开发,所以投的岗位都是Android开发工程师.投了知乎,内推了阿里蘑菇街腾讯百度网易.腾讯百度都没有收到面试,知乎Skyp ...
大佬带你看源码！你所不知道的Android原生开发的现状，成功入职字节跳动
概述想了很久怎么样可以让文章的标题不那么悲观,但是各种文案都在我脑海里面不断的被否定,要么是不那么抓眼球,要么是立意不匹配.最后想了想,这个标题是真的符合我最近的感悟. 希望看过文章,能有同感的朋友 ...
你所不知道的 Android Studio 调试技巧
Android Studio目前已经成为开发Android的主要工具,用熟了可谓相当顺手.作为开发者,调试并发现bug,进而解决,可是我们的看家本领.正所谓,工欲善其事必先利其器,和其他开发工具一样, ...
你所不知道的Android Studio调试技巧
原文链接:简书@涅槃1992 http://www.jianshu.com/p/011eb88f4e0d Android Studio目前已经成为开发Android的主要工具,用熟了可谓相当顺手.作为 ...
android 开源高斯模糊_Android高斯模糊你所不知道的坑
原标题:Android高斯模糊你所不知道的坑本文作者作者:mandypig 链接: https://www.jianshu.com/p/d29841b1a4d5 本文由作者授权发布. 如果你想了解 ...
Android Context完全解析，你所不知道的Context的各种细节
转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/47028975 前几篇文章,我也是费劲心思写了一个ListView系列的三部曲,虽然 ...
android仿秒拍源码,你所不知道的程序员程序员其实真的很…【Bus Weekly】三十六期...
原标题:你所不知道的程序员程序员其实真的很-[Bus Weekly]三十六期快,点击蓝色"字体"关注这个公众号,一起涨姿势- 现如今,程序员在中国的科技圈可以说已经达到了举足 ...

Android开发，你所不知道的Android原生开发的现状

Android开发，你所不知道的Android原生开发的现状相关推荐

最新文章

热门文章