作者 | Vasiliy Zukanov，已获翻译授权
译者 | 罗昭成，Android 开拓者；责编 | 唐小引
封图 | CSDN 付费下载自东方 IC
出品 | CSDN（ID：CSDNnews）
许多 Android 开拓者常常会问我，要学会哪些东西才能成为一个精良的 Android 工程师？对付这个问题，他们的描述或多或少都有些差异。但是，总体来说，我们都须要学习一系列的技能，才能成为一个精良的 Android 工程师。
Android 原生开拓的生态系统变革得非常快。至少在过去的五年韶光里，我经历过很多 Android 的变革，并且花费大量的韶光参与个中。这几年里，Google 每两到三年，就会推出一组新的库和框架作为官方 Android 原生开拓的辅导方针。我花了大量的韶光，回顾了这几年的变革，希望从中找出好坏。我相信，有很多的 Android 开拓者，也和我一样。
过去的一年，大量的内容被添加、被废弃或被删除，文档被变动，新的官方辅导方针被引入等等。纵然我以 Android 原生开拓生态系统的的标准来看待这些问题，所发生的这些事情，都是非常猖獗的。当我开始思考这些内容的时候，我已经无法在我的脑海中描述出一个完全的、详细的 Android 开拓环境。
因此，我决定要花一些韶光去整理这些内容，然后再来写这篇文章。本文中，我会试图去总结 Android 原生开拓的生态系统中发的事情，并且对原生开拓未来的走向做一些预测。我会将我的想法分身分歧的章节去阐述，这些内容没有特定的顺序，但我会把最有争议的内容放在文章末了。
我希望我的这篇文章可以给你带来一些启示和帮助，但是你须要记住，本文不可能包含所有的内容，有可能会漏掉许多主要的不雅观点，并且本文中的内容可能会包含我个人的一些偏见。
AndroidX
这个事情提及来有点儿猖獗，Google 官方在一年半前就发布了 AndroidX 的预览版本。并且在一年前， AndroidX 库就已经很稳定了，与此同时，Google 官方也宣告不再对遗留的库进行支持与开拓。（在我写这句话的时候，我想起我之前在 StackOverflow 上提的一个问题：为什么要将新的 API 放在 Support 库中，而不是 SDK 中？[1]）
用“稳定”来描述 AndroidX 这个库有点讽刺，现在关于 AndroidX 的任何东西都是不稳定的。Google 不断地在 AndroidX 下添加新的库和框架，利用 androidx 作为命名空间。许多“老”的 API（目前还不到一年）以非常快的速率发展。
到目前为止，我已经将两个运用程序迁移到了 AndroidX 上了。统统都很顺利，我已经不记得在这个过程中，带给了我多少的“惊喜“。Google 也供应了一个工具，Jetifier 可将依赖于支持库的库迁移为依赖于等效的 AndroidX 软件包，一个非常好用的工具。然而，纵然是一个很小的工程，也不能实现“一键迁移”。
我也参与了没有迁移 AndroidX 的项目（项目并不操持迁移到 AndroidX）， 现在也没有任何问题，以是，不迁移 AndroidX， 在有些情形下，也是一种可行的方案。
总而言之，在新的 Android 项目中，建议直策应用 AndroidX。并且，针对老项目，我也推举你们将迁移到 AndroidX 列到操持中，虽然现在你看不到迁移 AndroidX 过后，带来的任何收益。无论如何，你都有可能在某个韶光点进行 AndroidX 的迁移，以是最好能够按照自己的进度进行迁移，而不是在 6 个月后，你须要利用某个新的 AndroidX 库时，再进行紧急迁移。
Jetpack
在谈论 AndroidX 过后，还必须要提到 Jetpack。在我的印象中，Jetpack 开始是作为“架构组件”的一把保护伞推出的。但是到后面，引入了险些所有关于 AndroidX 的 API。因此，现在来看，我们看不到它与 AndroidX 之间的任何差异，除了 Marketing 和 PR（即市场和公关）。
当你查看 Jetpack 主页[2]时，会创造，这个页面并不是一个技能文档页面。这个更像是一个早期的 SaaS 页面。
看看例子，开拓者“赞誉”：
开拓者赞誉
或者“相信运用”列表：
相信运用
这些在市场公关层面更受关注，如果 Jetpack 在 2020 年申请独立 IPO，我都不会感到惊异。
不过，说真的，考试测验向自己生态系统内的开拓者“发卖”API 的想法，我以为存在一些问题，比如说，谁会想看搜索出来第一个便是 ViewModel 广告呢？
Android ViewModel
总而言之，Jetpack 只是 AndroidX 库的一个聚合，以是在前面写到的 AndroidX 的内容，在很大的程度上也适用于 Jetpack。在后面的内容中，我将单独谈论个中一些 API。
后台作业
在 Android 运用程序不在前台实行逻辑时，你可以有很多种办法来实现后台运行，这也是 Android 动态化的用例之一。如果你不引入 doze , SyncAdapter , CGMNetworkManager , FirebaseJobDispatcher , JobScheuler 和最近的 WorkManager，可以利用常规的启动做事（非绑定做事）来实现。这些都是 Google 供应的 API ， 我可以说出所有的利用办法。当然，还有一些第三方库可以利用， 例如：Android-Job。
不过，Google 最近宣告，他们将环绕 WorkManager 来统一后台任务调度[3]。这听起来非常棒，我再也不用学习那么多后台调度的知识了，只是，不知道为什么，我彷佛以前在哪儿听到过这句话……
我们不管将来是否会统一利用 WorkManager，WorkManager 都还存在一些问题，比如可靠性。我不想在本文中阐明为什么，但是请你一定要记住，如果你想在运用程序中利用 WorkManager，实现后台作业，一定要去读一下 dontkillmyapp.com 上的所有内容，并且要关注一下与 WorkManager 干系的 Google 问题列表[4]。
Android 的后台作业由于碎片化等缘故原由，导致它们一团糟，而且还很不可靠。
在过去，我一贯主见尽可能对数据和其它类型的后台处理进行同步。我或许是 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 卡文件的方法，现在都不能利用了，并且不会提示任何非常[5]。现在，你须要利用 Android 存储访问框架来进行更细粒度的文件访问。不幸的是，Android 存储访问框架的事情事理与之前的读取办法完备不同，你可能须要对代码进行大量的重构，来实现新的文件访问和读取。
Google 原来希望在 Android 10 上，对所有的运用程序进行文件访问的限定，推广利用 Android 存储访问框架的办法进行文件访问。但是这个改动引起了社区内的强烈抗议，以是 Google 决定推迟推出这个功能。因此，现在纵然你的运用程序在 Target API 29 及以上，也可以设置为在“Legacy”模式下可读取文件。不过，有可能在 Android 的下一个版本，不管你设置的 Target API 为多少，都会限定运用程序利用新的浸染域访问模式。
到目前为止，我也还没有更新我运用程序的文件访问办法。但是从互联网上的谈论来看，实现新的文件访问办法是一项很具寻衅的任务，虽然你的运用程序在“Legacy”模式下，没有任何非常，但是我建议你最好从现在开始，动手对代码进行重构和测试，以防发生不可控的事情。
Shared Preferences
在几周前，AndroidX 家族增加了一个新的库，这条提交信息写道：
新的库用来更换 SharedPreferences，新库的名称还没有确定下来，这次提交只是为了评审和设计文档（请自行申请设计文档）。
现在还没有什么值得担心的。不过，从长远来看，SharedPreferences 会被废弃掉，取而代之，利用新的库来实现类似的功能。
与 SharedPreferences 不同的是，这个新的库默认情形下利用的是异步的办法[6]。换句话说，如果你须要取某个值，你须要实现回调，通过这个回调才能拿到值。
如果你对这种异步回调的事理感兴趣，你可以去看看 StackOverflow 上的这个回答[7]。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 利用本钱在实际上依然会随着韶光增长而快速增长。越来越多的代码，在编译构建的时候须要花费更多的韶光；你的开拓职员越多，代码编译的次数就越多。当然，所有的开拓职员都须要学习如何利用 Dagger ， 这本身便是一项很大的本钱。
换句话说，虽然 Dagger 可以减少项目中编写的代码，但是须要花更多的韶光去培训新人，在编译上花费更多的时候。以是，对大型项目来说，利用 Dagger 会更耗时。
在一个大型项目中，编译耗时会逐渐成为生产力的瓶颈。当然， Dagger 也供应了很多精良新的功能来帮助你优化编译韶光，但条件是，你须要知道如何利用这些工具。读到这里，我相信你对手动依赖注入会很感兴趣。
数据绑定
作为一个 Android 开拓者，都知道在写布局的时候，会常常调用 findViewById 这个方法。DataBinding 出身便是为了取代掉这个模板方法。诚笃说，在利用 findViewById 的时候，我并没有碰着过任何问题，虽然希望摆脱掉它，但我并不认为利用 DataBinding 便是一个更合理的办法。有一个好，很快我们就可以利用 ViewBinding 来摆脱 findViewById 了，也不须要利用 DataBinding。
说句实话，我不相信 DataBinding。对付它想办理的问题来说，这种方案在过于繁芜。在利用 DataBinding 的时候，须要把代码逻辑放到 XML 布局中，这听起来很不错，但是履历丰富的开拓职员都不会这么做，这个做法也是 Databinding 的另一个缺陷。
早在 2016 年 11 月的时候，那个时候 Google 还在大肆宣扬 DataBinding。我在 StackOverflow 的回答中作了如下预测[9]：
我可以非常自傲地预测：DataBinding 不会成为行业标准。DataBinding 可以带来短期收益，但是从长远来看，它将会使代码变得不可掩护。一旦 Databinding 被长期利用，它的缺陷就会暴露出来，将来它一定会被废弃掉。
我没有统计过利用 DataBinding 的项目，但是很明显，它没有成为行业标准。我从来没有在自己的项目中利用过它，也很少看到其他开拓者利用。据我预测，当 ViewBinding 逐渐成熟，并且被广泛采取，DataBinding 将会作为一个“传统”框架，大量地被引用到。
状态保存
自从引入 ViewModel 架构组件以来，在 Android 运用程序中，当配置发生变动，保存与规复状态的逻辑，就变成了一个烂摊子，没有人去管理。虽然这样子说有点过分，但是我以为，这已经是我最温和的表达办法了。
Gabor Varadi（又叫 Zhuinden）在 Reddit 论坛中描述了 ViewModel 引入带来的问题[10]，我不须要再去写一遍了。再次强调，不推举利用 onRetainCustomNonConfigurationInstance，推举利用 ViewModel。
在帖子的末端，Gabor 作了一些预测：
你知道吗？Fragment 状态保存的方法已经被弃用了[11]。
在我看来，废弃 Fragment 状态保存的方法是非常好的主张，众所周知， Fragment 的 onAttach 和 onDetach 方法便是为了支持状态保存的，现在废弃了状态保存的方法，那这两个方法也可以被废弃掉，并且这样子可以简化 Fragment 的生命周期。我长期以来都建议不保存 Fragments 的状态，忽略掉 onAttach 和 onDetach 方法，和我之前写的处理 Framgent 生命周期方法同等[12]。
只管有很多情由表明，要废弃掉 Fragment 的状态保存，但是也不可能废弃掉 onRetainCustomNonConfigurationInstance，这个可不是我说的，是 Jake Wharton 说的。在上面 Gabor 的帖子上，他的回答得到了最多的点赞。虽然我不太附和 Jake 所说的话，但是我找不到更好的情由去说服自己。这个方法和 ViewModel 后台利用的事理完备同等，完备没有情由废弃掉它。
那我们该当怎么对待这些废弃的方法呢？Google 不管这些方法利用的技能方案和上风，都逼迫所有的 Andorid 运用迁移到 ViewModel。纵然这些方案有可能优于 ViewModel 本身，他们也乐意放弃。听起来有点像是阴谋论吧。
我确实不喜好保存非配置的状态，并且废弃掉对我没有任何影响，由于我从来都没有利用过它。事实上，大多数运用程序都不须要这些方法，当然，ViewModel 也不须要。我们须要处理状态改变的方法仅仅只有 onSaveInstanceState(Bundle) 这个方法。这个方法非常大略明了，可以同时处理保存和规复的逻辑。以是，只要能用这种办法保存状态就可以了，我相信，我不是唯一一个利用这个方法的人。虽然 Google 对 ViewModel 进行了大量的营销宣扬，但是对付很多履历丰富的开拓者来说， ViewModel 还是太繁芜了，我们有更大略有效的方法来处理状态存储。
如果 Google 别有用心，想逼迫所有项目利用 ViewModel ， 那么它还将废弃掉 onSaveInstanceState(Bundle)方法。这听起来有点不可思议，如果将来真的这样发展，那解释我的根本理论是精确的。
考虑到 Android 的内存管理机制，Google 不可能在没有稳定的办理方案之前就废弃掉 onSaveInstanceState(Bundle) 。“幸运的是”，我们已经可以利用 ViewModel 来完成干系事情了。
我想，在一两年内，就能看到我的理论是否精确。
总而言之，如在本节开头所说，Android 状态保存将变成一个烂摊子。两年多前，我曾经写过 ViewModel 架构组件有害的文章[13]时，我就预测 ViewModel 会对保存与规复状态的一点点造成影响。我所预测的都变成了现实，而且现在的情形比我曾经的预测更糟。
并发
在 Android 并发编程中，一个主要的 API 便是 AsyncTask， 不过它现在已经被弃用掉了。我之前已经写过很详细的文章剖析过它了[14]，在这里，将不再赘述。
下面我要说的内容，有可能会侵害很多读者，但是，请不要“恨”我。
RxJava，是一个 Andorid 中常见的多线程框架。但是它现在将逐渐退出历史的舞台。从 StackOverflow 的趋势图可以看出：
RxJava 利用趋势
很多开拓者对这个说法提出了质疑，他们回嘴说这个数据不具有代表性，并且我们可以找到其它的情由来阐明图上所发生的事情。他们所说可能是精确的，我个人本身也不是数据科学家。但是从图中我们可以看到，RxJava 与 AsnycTask 有相同的斜率。
如果你没有韶光去学习 RxJava 如何利用，并且你的项目中也没有利用过 RxJava，我建议你不要在你的项目中利用 RxJava。事实上，我也一贯不推举利用 RxJava ，现在已经有数据支持我的这个不雅观点了。
如果你的项目中利用了 RxJava，你也不用慌张，不须要紧急去重构你的项目。如果你的项目只有你一个人，或者全体项目组成员基本不会变动，保持项目现状就好了。但是你须要记住，往后要招具有 RxJava 开拓履历的人会越来越困难，新招开拓职员可能须要学习利用 RxJava。广泛利用 RxJava 的项目，在往后也会被认为\"大众不酷\"大众，就像本日还在利用 AsyncTask 和 Loader 的项目一样。
我知道，很多 RxJava 的开拓者都是 RxJava 骨灰级的粉丝，他们花了数周的韶光去学习 RxJava，付出巨大的努力才说服队友在项目中利用 RxJava。现在我却在这里说 RxJava 已经由时了。我只能说，这不是我的个人见地，我只是对现有的情形进行剖析，并根据我所看到的内容做出预测。我也有可能是错的。两军征战，不斩来使，请大家不要“攻击”我。
在 Kotlin 中，利用协程来实现多并发。最近利用协程实现了一些大略的用例[15]，我创造它繁芜、不稳定，乃至还有一些 Bug。
所有的人都在说，协程可以降落并发的繁芜度，利用并发变得大略。我从来都不相信这句话，由于我知道并发从根本上来说便是很繁芜的。我动手写过一些测试用例过后，据我的履历，我可以很自傲的见告你，协程不能使并变得大略。我认为，协程会增加繁芜性，我建议你们谨慎利用他们。
在 Kotlin 中，协程将作为处理多线程的默认办法，如果你已经开始利用 Kotlin 进行开拓，那么你该当花点韶光，去学习一下，协程的利用。
据我所知，还有一个 Flow 框架，它是基于协程，添加了流运算符。在几个月之前，已经稳定了。以是现在也没啥好评价的。
Kotlin
现在，让我们来谈论一下 Kotlin 在 Android 领域的现状。根据我个人的履历来看，这是一个很敏感的话题，不论我所说的话有多么公道客不雅观，都会有一些粉丝评价我所说的话是“Shit”。但从专业的角度来说，Kotlin 的话题是跳不过去的，以是，我要强调的是，这些内容只是我的个人不雅观点，仅供参考。
在 Android 开拓中，利用 Kotlin，会大大地增加你的编译韶光。
在我的另一篇文章中[16]，我统计了利用 Kotlin 过后，编译韶光的增长情形。结果是，全量编译的情形下，会增加 18%旁边的耗时，如果是增量编译，则会增加 8% 旁边的耗时。
Uber 和 JetBrains 联合揭橥了他们有关 Kotlin 对项目编译韶光的影响， 在文章中，显示的结果非常的悲观。他们表示，如果你不开启 IDE 中的 annotation processors ，引入 Kotlin 的项目，编译构建的韶光大约会增加四倍，如果开启了 annotation processors，编译构建的韶光也会增加 50% ~ 100%。
Uber 的结果与 OkHttp 迁移到 Kotlin 后得到的结果是同等的，都是编译时长都增加了 4 倍。
别担心，虽然这个结果让人吃惊，这个也不是你的错，很多人都和你一样，正在利用 Kotlin。这个问题，虽然很主要，但是它并没有引起广泛的关注。我以为，Google 也在试图办理这个问题。我曾问过 Google 干系的开拓者，并进行了深度的互换，他们在这个问题给我的回答是：“这是一个很棘手的问题，我甘心不做”。
Kotlin 除了会增加编译韶光，直到上周，才支持增量表明处理，而 Java ，在 10 个月以前就支持了。
在两年前，我就写了篇文章用于告诫大家，过早利用 Kotlin 会存在很大的风险。你可以从评论中可以看出，我在很长的一段韶光里面，都是“Kotlin 的黑粉”。
在你的实际事情中，你会创造，与上面的数据比较，Kotlin 的问题远不止于此。在大型的 Android 项目中，编译构建的韶光会严重阻碍项目的发展。纵然到了本日，Kotlin 已经被正式利用两年了，Kotlin 编译效率依然比 Java 差很多。不管 Kotlin 能给你带来多少优点，编译耗时的问题，都有可能导致你不在利用它。
不管如何，Google 向全体 Android 的开拓生态推出 Kotlin 作为第一首选措辞，现在 Kotlin 的利用量也越来越大，我们也不得不进行跟进。就我个人而言，我还没有在我的项目中利用 Kotlin。由于 Kotlin 还不足成熟，并且我的客户也不会为我的学习付费，并且我也不肯望在 Kotlin 上摧残浪费蹂躏韶光。但是从现在开始，Kotlin 已经逐渐稳定，我也在我拿手的项目上考试测验过， 在新项目中，我也会考虑利用它进行开拓。有一些开拓者认为：“必须在新项目中利用 Kotlin 进行开拓“，我不同意这个不雅观点，我以为这是一个权衡的问题，Kotlin 现在已经成为了一个主要的选项，只要适宜当前的项目，便是最好的措辞。
对付是否要将已有的项目迁移到 Kotlin 上， 我不能给你太好的建议。你须要根据你项目的情形，详细问题详细剖析。如果你一旦决定要进行迁移，这篇文章中列举的一些可能存在的问题，可能对你有帮助。
总结
请许可我用 Android 开拓者的背景，描述一下我这两年所经历的事情：
在过去的两年里，我启动了三个项目，我一贯争取，至少参与个中一个项目的开拓事情。我回过分来看这些已经存在的项目，并剖析这些项目前期所做的技能决定对全体项目的影响。我写了这篇文章，也制作了很多 Android 开拓的高等课程，也花了很多韶光在互联网上谈论 Android 干系的主题。
纵然这样，我本日依然觉得跟不上 Android 全体生态系统的变革。可想而知，对付那些履历不敷，须要辅导的 Android 开拓者而言，是多么地绝望。我现在已经无法想像，现在从头开始学习 Android 的觉得。当你好不容易学会了某个框架或者工具，以为它很好用的时候，它或许就要过期了。现在大概是加入 Android 开拓大家庭最坏的时候。Google 正为他们的“原谅性”志得意满，但这统统，对初学者来说，都是极其痛楚的。
Google 在 Android 框架中所做的事情，会导致大量的韶光摧残浪费蹂躏。我们须要花费数小时的韶光才能读完所有变动的内容，更别说在项目中运用它们了。我甘心花韶光来创造代价，而不是舍本逐末。
在本文中，我试图总结 Android 开拓的现状，并对未来作出了一些预测。文章中，可能包含缺点和漏掉一些主要信息，请随时不才面的评论中奉告我。文章中的内容都是客不雅观内容，虽然我提出了一些有争议不雅观点，但我相信我是对的。
还有，在文章中，我引用了很多之前写的帖子，我并不是为了炫耀。而是让你能够阅读之前的预测与现在的状况进行比拟，虽然那些文章在那个时候读起来很猖獗，就像现在你读本文一样，但是我的这些预测都是很准确的。当然，我也想说：“看，我说得对吧”。鉴于我发布的内容具有争议，当得知没有误导读者，我也会感到很欣慰。有时候，我也甘心我的预测是错的，Google 正在为开拓者着想。但是到目前为止，情形并非如此。
一如既往，感谢你的阅读。你可以不才面留言评论和提问。
[1] https://stackoverflow.com/questions/29197821/why-does-aosp-add-new-apis-to-support-libraries-without-adding-them-to-sdk
[2] https://developer.android.com/jetpack
[3] https://android-developers.googleblog.com/2019/11/unifying-background-task-scheduling-on.html
[4] https://issuetracker.google.com/issues/122098785
[5] https://youtu.be/UnJ3amzJM94
[6] https://android-review.googlesource.com/c/platform/frameworks/support/+/1169184/3/applicationpreferences/src/main/java/androidx/applicationpreferences/ApplicationPreferences.java
[7] https://stackoverflow.com/a/37551254/2463035
[8] https://www.techyourchance.com/dagger-android-dead/
[9] https://stackoverflow.com/a/30628530/2463035
[10] https://www.reddit.com/r/androiddev/comments/b908fr/can_someone_explain_to_me_why_aac_is_trying_to/
[11] https://android-review.googlesource.com/c/platform/frameworks/support/+/1159084
[12] https://www.techyourchance.com/android-fragment-lifecycle
[13] https://www.techyourchance.com/android-viewmodel-architecture-component-harmful/
[14] https://www.techyourchance.com/asynctask-deprecated/
[15] https://www.techyourchance.com/kotlin-coroutines-in-complex-scenarios/
[16] https://www.techyourchance.com/migrate-android-applications-to-kotlin-with-caution/
英文：The State of Native Android Development
链接：https://www.techyourchance.com/the-state-of-native-android-development-november-2019/
作者：Vasiliy Zukanov，独立 Android 开拓及软件顾问
译者：罗昭成，Android 开拓者
