你好不容易學(xué)會(huì)了某個(gè)框架或者工具，覺(jué)得它很好用的時(shí)候，它或許就要過(guò)時(shí)了。

作者 | Vasiliy Zukanov，已獲翻譯授權(quán)

譯者 | 羅昭成，Android 開(kāi)發(fā)者；責(zé)編 | 唐小引

封圖 | CSDN 付費(fèi)下載自東方 IC

出品 | CSDN（ID：CSDNnews）

許多 Android 開(kāi)發(fā)者經(jīng)常會(huì)問(wèn)我，要學(xué)會(huì)哪些東西才能成為一個(gè)優(yōu)秀的 Android 工程師？對(duì)于這個(gè)問(wèn)題，他們的描述或多或少都有些差異。但是，總體來(lái)說(shuō)，我們都需要學(xué)習(xí)一系列的技能，才能成為一個(gè)優(yōu)秀的 Android 工程師。

Android 原生開(kāi)發(fā)的生態(tài)系統(tǒng)變化得非常快。至少在過(guò)去的五年時(shí)間里，我經(jīng)歷過(guò)很多 Android 的變化，并且花費(fèi)大量的時(shí)間參與其中。這幾年里，Google 每?jī)傻饺辏蜁?huì)推出一組新的庫(kù)和框架作為官方 Android 原生開(kāi)發(fā)的指導(dǎo)方針。我花了大量的時(shí)間，回顧了這幾年的變化，希望從中找出好壞。我相信，有很多的 Android 開(kāi)發(fā)者，也和我一樣。

過(guò)去的一年，大量的內(nèi)容被添加、被廢棄或被刪除，文檔被更改，新的官方指導(dǎo)方針被引入等等。即使我以 Android 原生開(kāi)發(fā)生態(tài)系統(tǒng)的的標(biāo)準(zhǔn)來(lái)看待這些問(wèn)題，所發(fā)生的這些事情，都是非常瘋狂的。當(dāng)我開(kāi)始思考這些內(nèi)容的時(shí)候，我已經(jīng)無(wú)法在我的腦海中描繪出一個(gè)完整的、詳細(xì)的 Android 開(kāi)發(fā)環(huán)境。

因此，我決定要花一些時(shí)間去整理這些內(nèi)容，然后再來(lái)寫(xiě)這篇文章。本文中，我會(huì)試圖去總結(jié) Android 原生開(kāi)發(fā)的生態(tài)系統(tǒng)中發(fā)的事情，并且對(duì)原生開(kāi)發(fā)未來(lái)的走向做一些預(yù)測(cè)。我會(huì)將我的想法分成不同的章節(jié)去敘述，這些內(nèi)容沒(méi)有特定的順序，但我會(huì)把最有爭(zhēng)議的內(nèi)容放在文章最后。

我希望我的這篇文章可以給你帶來(lái)一些啟發(fā)和幫助，但是你需要記住，本文不可能包含所有的內(nèi)容，有可能會(huì)漏掉許多重要的觀點(diǎn)，并且本文中的內(nèi)容可能會(huì)包含我個(gè)人的一些偏見(jiàn)。

AndroidX

這個(gè)事情說(shuō)起來(lái)有點(diǎn)兒瘋狂，Google 官方在一年半前就發(fā)布了 AndroidX 的預(yù)覽版本。并且在一年前， AndroidX 庫(kù)就已經(jīng)很穩(wěn)定了，與此同時(shí)，Google 官方也宣布不再對(duì)遺留的庫(kù)進(jìn)行支持與開(kāi)發(fā)。（在我寫(xiě)這句話(huà)的時(shí)候，我想起我之前在 StackOverflow 上提的一個(gè)問(wèn)題：為什么要將新的 API 放在 Support 庫(kù)中，而不是 SDK 中？[1]）

用“穩(wěn)定”來(lái)描述 AndroidX 這個(gè)庫(kù)有點(diǎn)諷刺，現(xiàn)在關(guān)于 AndroidX 的任何東西都是不穩(wěn)定的。Google 不斷地在 AndroidX 下添加新的庫(kù)和框架，使用 androidx 作為命名空間。許多“老”的 API（目前還不到一年）以非常快的速度發(fā)展。

到目前為止，我已經(jīng)將兩個(gè)應(yīng)用程序遷移到了 AndroidX 上了。一切都很順利，我已經(jīng)不記得在這個(gè)過(guò)程中，帶給了我多少的“驚喜“。Google 也提供了一個(gè)工具，Jetifier 可將依賴(lài)于支持庫(kù)的庫(kù)遷移為依賴(lài)于等效的 AndroidX 軟件包，一個(gè)非常好用的工具。然而，即使是一個(gè)很小的工程，也不能實(shí)現(xiàn)“一鍵遷移”。

我也參與了沒(méi)有遷移 AndroidX 的項(xiàng)目（項(xiàng)目并不計(jì)劃遷移到 AndroidX）， 現(xiàn)在也沒(méi)有任何問(wèn)題，所以，不遷移 AndroidX， 在有些情況下，也是一種可行的方案。

總而言之，在新的 Android 項(xiàng)目中，建議直接使用 AndroidX。并且，針對(duì)老項(xiàng)目，我也推薦你們將遷移到 AndroidX 列到計(jì)劃中，雖然現(xiàn)在你看不到遷移 AndroidX 過(guò)后，帶來(lái)的任何收益。無(wú)論如何，你都有可能在某個(gè)時(shí)間點(diǎn)進(jìn)行 AndroidX 的遷移，所以最好能夠按照自己的進(jìn)度進(jìn)行遷移，而不是在 6 個(gè)月后，你需要使用某個(gè)新的 AndroidX 庫(kù)時(shí)，再進(jìn)行緊急遷移。

Jetpack

在討論 AndroidX 過(guò)后，還必須要提到 Jetpack。在我的印象中，Jetpack 開(kāi)始是作為“架構(gòu)組件”的一把保護(hù)傘推出的。但是到后面，引入了幾乎所有關(guān)于 AndroidX 的 API。因此，現(xiàn)在來(lái)看，我們看不到它與 AndroidX 之間的任何區(qū)別，除了 Marketing 和 PR（即市場(chǎng)和公關(guān)）。

當(dāng)你查看 Jetpack 主頁(yè)[2]時(shí)，會(huì)發(fā)現(xiàn)，這個(gè)頁(yè)面并不是一個(gè)技術(shù)文檔頁(yè)面。這個(gè)更像是一個(gè)早期的 SaaS 頁(yè)面。

看看例子，開(kāi)發(fā)者“贊譽(yù)”：

開(kāi)發(fā)者贊譽(yù)

或者“信賴(lài)應(yīng)用”列表：

信賴(lài)應(yīng)用

這些在市場(chǎng)公關(guān)層面更受關(guān)注，如果 Jetpack 在 2020 年申請(qǐng)獨(dú)立 IPO，我都不會(huì)感到驚訝。

不過(guò)，說(shuō)真的，嘗試向自己生態(tài)系統(tǒng)內(nèi)的開(kāi)發(fā)者“銷(xiāo)售”API 的想法，我覺(jué)得存在一些問(wèn)題，比如說(shuō)，誰(shuí)會(huì)想看搜索出來(lái)第一個(gè)就是 ViewModel 廣告呢？

Android ViewModel

總而言之，Jetpack 只是 AndroidX 庫(kù)的一個(gè)聚合，所以在前面寫(xiě)到的 AndroidX 的內(nèi)容，在很大的程度上也適用于 Jetpack。在后面的內(nèi)容中，我將單獨(dú)討論其中一些 API。

后臺(tái)作業(yè)

在 Android 應(yīng)用程序不在前臺(tái)執(zhí)行邏輯時(shí)，你可以有很多種方式來(lái)實(shí)現(xiàn)后臺(tái)運(yùn)行，這也是 Android 動(dòng)態(tài)化的用例之一。如果你不引入 doze , SyncAdapter , CGMNetworkManager , FirebaseJobDispatcher , JobScheuler 和最近的 WorkManager，可以使用常規(guī)的啟動(dòng)服務(wù)（非綁定服務(wù)）來(lái)實(shí)現(xiàn)。這些都是 Google 提供的 API ， 我可以說(shuō)出所有的使用方式。當(dāng)然，還有一些第三方庫(kù)可以使用， 例如：Android-Job。

不過(guò)，Google 最近宣布，他們將圍繞 WorkManager 來(lái)統(tǒng)一后臺(tái)任務(wù)調(diào)度[3]。這聽(tīng)起來(lái)非常棒，我再也不用學(xué)習(xí)那么多后臺(tái)調(diào)度的知識(shí)了，只是，不知道為什么，我好像以前在哪兒聽(tīng)到過(guò)這句話(huà)……

我們不管將來(lái)是否會(huì)統(tǒng)一使用 WorkManager，WorkManager 都還存在一些問(wèn)題，比如可靠性。我不想在本文中解釋為什么，但是請(qǐng)你一定要記住，如果你想在應(yīng)用程序中使用 WorkManager，實(shí)現(xiàn)后臺(tái)作業(yè)，一定要去讀一下 dontkillmyapp.com 上的所有內(nèi)容，并且要關(guān)注一下與 WorkManager 相關(guān)的 Google 問(wèn)題列表[4]。

Android 的后臺(tái)作業(yè)由于碎片化等原因，導(dǎo)致它們一團(tuán)糟，而且還很不可靠。

在過(guò)去，我一直主張盡可能對(duì)數(shù)據(jù)和其它類(lèi)型的后臺(tái)處理進(jìn)行同步。我或許是 SyncAdapter 最后的粉絲。今天，考慮到可靠性的問(wèn)題，我建議，盡可能避免后臺(tái)作業(yè)。如果你的老板一直堅(jiān)持要使用這個(gè)功能，請(qǐng)將上面的鏈接發(fā)給他們，告訴他們，后臺(tái)作業(yè)可能會(huì)需要數(shù)百小時(shí)的工作，才能實(shí)現(xiàn)，并且它帶來(lái)的問(wèn)題也會(huì)比它帶來(lái)的好處多很多。

很多情況下，后臺(tái)作業(yè)的需求是不可避免的。但是在大多數(shù)情況下，你都可以不使用它。雖然有時(shí)候會(huì)給用戶(hù)帶來(lái)一些不便，但是這可能是到目前為止的最佳方案。

數(shù)據(jù)庫(kù)

在有關(guān) SQLite ORMs 的內(nèi)容里面，沒(méi)有什么令人吃驚的內(nèi)容—— Room 主宰著一切。Room 從 2.2.0 開(kāi)始，添加增量注解解析支持。不過(guò)，請(qǐng)你一定要記住，你應(yīng)用程序的架構(gòu)不應(yīng)該關(guān)心你使用的是什么樣的 ORM 框架。說(shuō)到 Room，“架構(gòu)組件”也只是一個(gè)營(yíng)銷(xiāo)術(shù)語(yǔ)，并不是一個(gè)技術(shù)角色。

在 Android ORM 框架中，與 Room 競(jìng)爭(zhēng)的主要是 SQLDelight。這是一個(gè)比 Room 老很多的庫(kù)。但是據(jù)我所知，在過(guò)去的一年里，它幾乎被全部重寫(xiě)。但新版本的 SQLDelight 只針對(duì) Kotlin。另一方面，SQLDelight 也支持 Kotlin Multiplatform，所以，隨著 Kotlin 使用的增多，我預(yù)計(jì)， SQLDelight 的采用率也會(huì)隨之增加。

順便說(shuō)一下，在 AndroidX 的命名空間下，也有 SQLite 的鏡像。我不知道這個(gè)會(huì)有什么用處，但是如果你在應(yīng)用程序中直接使用 SQLite，也可以對(duì)這個(gè)進(jìn)行深入的研究。

此外，我們也不要忘記非關(guān)系型數(shù)據(jù)庫(kù)，比如 Realm、Parse、Firebase、ObjectBox 等等 （其中一些，核心還是使用的 SQLite 來(lái)實(shí)現(xiàn)的），如果我沒(méi)有記錯(cuò)的話(huà)，這些非關(guān)系型數(shù)據(jù)庫(kù)中，大多數(shù)（甚至全部）都具有自動(dòng)數(shù)據(jù)同步的功能。在之前有段時(shí)間里，它們非常地流行。但是現(xiàn)在，據(jù)我所知，已經(jīng)不再流行了。也就是說(shuō)，在短期內(nèi)，我會(huì)持續(xù)關(guān)注非關(guān)系型數(shù)據(jù)庫(kù)。

去年，我寫(xiě)了一個(gè)非常復(fù)雜的應(yīng)用程序，對(duì)接了一個(gè) Parse 的服務(wù)。這個(gè) App 具有完全的離線(xiàn)支持，服務(wù)端本地化，用戶(hù)指定的系統(tǒng)和語(yǔ)言設(shè)定，復(fù)雜的多媒體系統(tǒng)等功能。我在 Android 端上使用了 Parse 的 SDK。除了一些小的 WTF 以外，其他體驗(yàn)都非常棒。如果你們公司有很多后臺(tái)開(kāi)發(fā)人員，或者說(shuō)你需要實(shí)現(xiàn)大量的服務(wù)端邏輯，這也許并不是最佳解決方案。但是對(duì)于僅僅只需要執(zhí)行簡(jiǎn)單的 CRUD 操作的初創(chuàng)公司，這或許是一個(gè)不錯(cuò)的選擇。

一個(gè)警告：如果你打算采用數(shù)據(jù)庫(kù)即服務(wù)解決方案（如 Firebase），請(qǐng)你一定要關(guān)注長(zhǎng)期使用的成本和影響。

外部存儲(chǔ)

Android 外部存儲(chǔ)發(fā)生了一個(gè)“很有意思”的變動(dòng)。

如果，你在開(kāi)發(fā) App 的時(shí)候，把 Target API 調(diào)整為 29 及以上，之前獲取 SD 卡文件的方法，現(xiàn)在都不能使用了，并且不會(huì)提示任何異常[5]。現(xiàn)在，你需要使用 Android 存儲(chǔ)訪問(wèn)框架來(lái)進(jìn)行更細(xì)粒度的文件訪問(wèn)。不幸的是，Android 存儲(chǔ)訪問(wèn)框架的工作原理與之前的讀取方式完全不同，你可能需要對(duì)代碼進(jìn)行大量的重構(gòu)，來(lái)實(shí)現(xiàn)新的文件訪問(wèn)和讀取。

Google 原本希望在 Android 10 上，對(duì)所有的應(yīng)用程序進(jìn)行文件訪問(wèn)的限制，推廣使用 Android 存儲(chǔ)訪問(wèn)框架的方式進(jìn)行文件訪問(wèn)。但是這個(gè)改動(dòng)引起了社區(qū)內(nèi)的強(qiáng)烈抗議，所以 Google 決定推遲推出這個(gè)功能。因此，現(xiàn)在即使你的應(yīng)用程序在 Target API 29 及以上，也可以設(shè)置為在“Legacy”模式下可讀取文件。不過(guò)，有可能在 Android 的下一個(gè)版本，不管你設(shè)置的 Target API 為多少，都會(huì)限制應(yīng)用程序使用新的作用域訪問(wèn)模式。

到目前為止，我也還沒(méi)有更新我應(yīng)用程序的文件訪問(wèn)方式。但是從互聯(lián)網(wǎng)上的討論來(lái)看，實(shí)現(xiàn)新的文件訪問(wèn)方式是一項(xiàng)很具挑戰(zhàn)的任務(wù)，雖然你的應(yīng)用程序在“Legacy”模式下，沒(méi)有任何異常，但是我建議你最好從現(xiàn)在開(kāi)始，著手對(duì)代碼進(jìn)行重構(gòu)和測(cè)試，以防發(fā)生不可控的事情。

Shared Preferences

在幾周前，AndroidX 家族增加了一個(gè)新的庫(kù)，這條提交信息寫(xiě)道：

新的庫(kù)用來(lái)替換 SharedPreferences，新庫(kù)的名稱(chēng)還沒(méi)有確定下來(lái)，這次提交只是為了評(píng)審和設(shè)計(jì)文檔（請(qǐng)自行申請(qǐng)?jiān)O(shè)計(jì)文檔）。

現(xiàn)在還沒(méi)有什么值得擔(dān)心的。不過(guò)，從長(zhǎng)遠(yuǎn)來(lái)看，SharedPreferences 會(huì)被廢棄掉，取而代之，使用新的庫(kù)來(lái)實(shí)現(xiàn)類(lèi)似的功能。

與 SharedPreferences 不同的是，這個(gè)新的庫(kù)默認(rèn)情況下使用的是異步的方式[6]。換句話(huà)說(shuō)，如果你需要取某個(gè)值，你需要實(shí)現(xiàn)回調(diào)，通過(guò)這個(gè)回調(diào)才能拿到值。

如果你對(duì)這種異步回調(diào)的原理感興趣，你可以去看看 StackOverflow 上的這個(gè)回答[7]。Reddit 的一個(gè)用戶(hù) Tolriq 分享了他們的 App 遇到的一個(gè) SharedPreferences 的 Bug，這個(gè)問(wèn)題影響了萬(wàn)分之一的月活用戶(hù)。對(duì)于一般的應(yīng)用程序來(lái)說(shuō)，這個(gè)問(wèn)題并沒(méi)有什么明顯的影響。但在一些需要高可靠性的應(yīng)用上，就顯得很不可靠了。舉個(gè)例子，如果在 Android 汽車(chē)上，應(yīng)用程序的無(wú)響應(yīng)和崩潰會(huì)引起駕駛員的注意力被分散，這將有可能導(dǎo)致出現(xiàn)交通意外。

依賴(lài)注入

在依賴(lài)注入領(lǐng)域，最大的新聞莫過(guò)于 Dagger-Android 被棄用，有兩點(diǎn)需要強(qiáng)調(diào)一下，首先我所說(shuō)的棄用，不是正式的棄用，因?yàn)楣俜讲](méi)有發(fā)布聲明。其次，Dagger-Android 并不是指整個(gè) Dagger 2 框架，只是指其中相對(duì)比較新的部分。詳細(xì)細(xì)節(jié)可以看我的另一篇文章[8]。

在 Android 領(lǐng)域也存在其他的依賴(lài)注入框架，但是我不認(rèn)為他們會(huì)比 Dagger 更好。值得一提的是，Koin 是一個(gè)不錯(cuò)的依賴(lài)注入框架，但是我依然覺(jué)得它也不會(huì)引起多大的潮流。它之所以會(huì)被采用，無(wú)非是這兩個(gè)原因，一個(gè)是，它擁有比 Dagger 好很多的文檔，降低了很大的學(xué)習(xí)成本。第二個(gè)是它基于 Kotlin 進(jìn)行編寫(xiě)，因?yàn)?Kotlin 的熱度，給它也帶來(lái)了不少的關(guān)注。到目前為止，Kotlin 的熱潮幾乎已經(jīng)全部過(guò)去了，所以，我預(yù)測(cè)，Koin 的關(guān)注也將會(huì)逐漸減少。

不管這些框架如何發(fā)展，手動(dòng)依賴(lài)注入的發(fā)展都會(huì)很緩慢。

Google 聲稱(chēng)：隨著應(yīng)用程序的增大，手動(dòng)依賴(lài)注入的成本會(huì)出現(xiàn)指數(shù)級(jí)增長(zhǎng)。但是我并不這么認(rèn)為，我覺(jué)得 Google 既不了解 "指數(shù)" 的含義，也沒(méi)有實(shí)際去“衡量”過(guò)任何東西。這個(gè)申明的內(nèi)容是錯(cuò)誤的，我希望 Google 不再使用這種方式誤導(dǎo)社區(qū)。

事實(shí)上，這種手動(dòng)依賴(lài)注入在后端比較常見(jiàn)（尤其是微服務(wù)中，你并不想在每個(gè)服務(wù)中都添加對(duì)注入框架的依賴(lài)），也可以正常的工作。在后端，反射被經(jīng)常用到，所以后端的依賴(lài)注入框架并不需要解析編譯時(shí)的代碼。

在 Android 上，解決方案與后端有一些不同，我們幾乎不會(huì)用反射方案的依賴(lài)注入框架，所以就只剩下 Dagger 可以用了。其實(shí)，反射雖然會(huì)影響性能，但是在大多數(shù)項(xiàng)目，都是可以用的。我的意思并不是建議你們使用反射方案的依賴(lài)注入框架，這個(gè)選擇并非是非黑即白的，你需要按照你的要求來(lái)進(jìn)行選擇。

無(wú)論如何，Android 領(lǐng)域上， Dagger 作為依賴(lài)注入框架的現(xiàn)行標(biāo)準(zhǔn)，我們所有人都在使用它。盡管 Google 在宣傳上，對(duì) Dagger 的使用成本使用漂亮的綠色圖形進(jìn)行展示，但是 Dagger 使用成本在實(shí)際上依然會(huì)隨著時(shí)間增長(zhǎng)而快速增長(zhǎng)。越來(lái)越多的代碼，在編譯構(gòu)建的時(shí)候需要花費(fèi)更多的時(shí)間；你的開(kāi)發(fā)人員越多，代碼編譯的次數(shù)就越多。當(dāng)然，所有的開(kāi)發(fā)人員都需要學(xué)習(xí)如何使用 Dagger ， 這本身就是一項(xiàng)很大的成本。

換句話(huà)說(shuō)，雖然 Dagger 可以減少項(xiàng)目中編寫(xiě)的代碼，但是需要花更多的時(shí)間去培訓(xùn)新人，在編譯上花費(fèi)更多的時(shí)候。所以，對(duì)大型項(xiàng)目來(lái)說(shuō)，使用 Dagger 會(huì)更耗時(shí)。

在一個(gè)大型項(xiàng)目中，編譯耗時(shí)會(huì)逐漸成為生產(chǎn)力的瓶頸。當(dāng)然， Dagger 也提供了很多優(yōu)秀新的功能來(lái)幫助你優(yōu)化編譯時(shí)間，但前提是，你需要知道如何使用這些工具。讀到這里，我相信你對(duì)手動(dòng)依賴(lài)注入會(huì)很感興趣。

數(shù)據(jù)綁定

作為一個(gè) Android 開(kāi)發(fā)者，都知道在寫(xiě)布局的時(shí)候，會(huì)經(jīng)常調(diào)用 findViewById 這個(gè)方法。DataBinding 誕生就是為了取代掉這個(gè)模板方法。老實(shí)說(shuō)，在使用 findViewById 的時(shí)候，我并沒(méi)有遇到過(guò)任何問(wèn)題，雖然希望擺脫掉它，但我并不認(rèn)為使用 DataBinding 就是一個(gè)更合理的方式。有一個(gè)好消息，很快我們就可以使用 ViewBinding 來(lái)擺脫 findViewById 了，也不需要使用 DataBinding。

說(shuō)句實(shí)話(huà)，我不相信 DataBinding。對(duì)于它想解決的問(wèn)題來(lái)說(shuō)，這種方案在過(guò)于復(fù)雜。在使用 DataBinding 的時(shí)候，需要把代碼邏輯放到 XML 布局中，這聽(tīng)起來(lái)很不錯(cuò)，但是經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員都不會(huì)這么做，這個(gè)做法也是 Databinding 的另一個(gè)缺點(diǎn)。

早在 2016 年 11 月的時(shí)候，那個(gè)時(shí)候 Google 還在大肆宣傳 DataBinding。我在 StackOverflow 的回答中作了如下預(yù)測(cè)[9]：

我可以非常自信地預(yù)測(cè)：DataBinding 不會(huì)成為行業(yè)標(biāo)準(zhǔn)。DataBinding 可以帶來(lái)短期收益，但是從長(zhǎng)遠(yuǎn)來(lái)看，它將會(huì)使代碼變得不可維護(hù)。一旦 Databinding 被長(zhǎng)期使用，它的缺點(diǎn)就會(huì)暴露出來(lái)，將來(lái)它一定會(huì)被廢棄掉。

我沒(méi)有統(tǒng)計(jì)過(guò)使用 DataBinding 的項(xiàng)目，但是很明顯，它沒(méi)有成為行業(yè)標(biāo)準(zhǔn)。我從來(lái)沒(méi)有在自己的項(xiàng)目中使用過(guò)它，也很少看到其他開(kāi)發(fā)者使用。據(jù)我猜測(cè)，當(dāng) ViewBinding 逐漸成熟，并且被廣泛采用，DataBinding 將會(huì)作為一個(gè)“傳統(tǒng)”框架，大量地被引用到。

狀態(tài)保存

自從引入 ViewModel 架構(gòu)組件以來(lái)，在 Android 應(yīng)用程序中，當(dāng)配置發(fā)生更改，保存與恢復(fù)狀態(tài)的邏輯，就變成了一個(gè)爛攤子，沒(méi)有人去管理。雖然這樣子說(shuō)有點(diǎn)過(guò)分，但是我覺(jué)得，這已經(jīng)是我最溫和的表達(dá)方式了。

Gabor Varadi（又叫 Zhuinden）在 Reddit 論壇中描述了 ViewModel 引入帶來(lái)的問(wèn)題[10]，我不需要再去寫(xiě)一遍了。再次強(qiáng)調(diào)，不推薦使用 onRetainCustomNonConfigurationInstance，推薦使用 ViewModel。

在帖子的末尾，Gabor 作了一些預(yù)測(cè)：

你知道嗎？Fragment 狀態(tài)保存的方法已經(jīng)被棄用了[11]。

在我看來(lái)，廢棄 Fragment 狀態(tài)保存的方法是非常好的主意，眾所周知， Fragment 的 onAttach 和 onDetach 方法就是為了支持狀態(tài)保存的，現(xiàn)在廢棄了狀態(tài)保存的方法，那這兩個(gè)方法也可以被廢棄掉，并且這樣子可以簡(jiǎn)化 Fragment 的生命周期。我長(zhǎng)期以來(lái)都建議不保存 Fragments 的狀態(tài)，忽略掉 onAttach 和 onDetach 方法，和我之前寫(xiě)的處理 Framgent 生命周期方法一致[12]。

盡管有很多理由表明，要廢棄掉 Fragment 的狀態(tài)保存，但是也不可能廢棄掉 onRetainCustomNonConfigurationInstance，這個(gè)可不是我說(shuō)的，是 Jake Wharton 說(shuō)的。在上面 Gabor 的帖子上，他的回復(fù)獲得了最多的點(diǎn)贊。雖然我不太贊成 Jake 所說(shuō)的話(huà)，但是我找不到更好的理由去說(shuō)服自己。這個(gè)方法和 ViewModel 后臺(tái)使用的原理完全一致，完全沒(méi)有理由廢棄掉它。

那我們應(yīng)該怎么對(duì)待這些廢棄的方法呢？Google 不管這些方法使用的技術(shù)方案和優(yōu)勢(shì)，都強(qiáng)制所有的 Andorid 應(yīng)用遷移到 ViewModel。即使這些方案有可能優(yōu)于 ViewModel 本身，他們也愿意放棄。聽(tīng)起來(lái)有點(diǎn)像是陰謀論吧。

我確實(shí)不喜歡保存非配置的狀態(tài)，并且廢棄掉對(duì)我沒(méi)有任何影響，因?yàn)槲覐膩?lái)都沒(méi)有使用過(guò)它。事實(shí)上，大多數(shù)應(yīng)用程序都不需要這些方法，當(dāng)然，ViewModel 也不需要。我們需要處理狀態(tài)改變的方法僅僅只有 onSaveInstanceState(Bundle) 這個(gè)方法。這個(gè)方法非常簡(jiǎn)單明了，可以同時(shí)處理保存和恢復(fù)的邏輯。所以，只要能用這種方式保存狀態(tài)就可以了，我相信，我不是唯一一個(gè)使用這個(gè)方法的人。雖然 Google 對(duì) ViewModel 進(jìn)行了大量的營(yíng)銷(xiāo)宣傳，但是對(duì)于很多經(jīng)驗(yàn)豐富的開(kāi)發(fā)者來(lái)說(shuō)， ViewModel 還是太復(fù)雜了，我們有更簡(jiǎn)單有效的方法來(lái)處理狀態(tài)存儲(chǔ)。

如果 Google 別有用心，想強(qiáng)制所有項(xiàng)目使用 ViewModel ， 那么它還將廢棄掉 onSaveInstanceState(Bundle)方法。這聽(tīng)起來(lái)有點(diǎn)不可思議，如果將來(lái)真的這樣發(fā)展，那說(shuō)明我的基礎(chǔ)理論是正確的。

考慮到 Android 的內(nèi)存管理機(jī)制，Google 不可能在沒(méi)有穩(wěn)定的解決方案之前就廢棄掉 onSaveInstanceState(Bundle) 。“幸運(yùn)的是”，我們已經(jīng)可以使用 ViewModel 來(lái)完成相關(guān)工作了。

我想，在一兩年內(nèi)，就能看到我的理論是否正確。

總而言之，如在本節(jié)開(kāi)頭所說(shuō)，Android 狀態(tài)保存將變成一個(gè)爛攤子。兩年多前，我曾經(jīng)寫(xiě)過(guò) ViewModel 架構(gòu)組件有害的文章[13]時(shí)，我就預(yù)測(cè) ViewModel 會(huì)對(duì)保存與恢復(fù)狀態(tài)的一點(diǎn)點(diǎn)造成影響。我所預(yù)測(cè)的都變成了現(xiàn)實(shí)，而且現(xiàn)在的情況比我曾經(jīng)的預(yù)測(cè)更糟。

并發(fā)

在 Android 并發(fā)編程中，一個(gè)重要的 API 就是 AsyncTask， 不過(guò)它現(xiàn)在已經(jīng)被棄用掉了。我之前已經(jīng)寫(xiě)過(guò)很詳細(xì)的文章分析過(guò)它了[14]，在這里，將不再贅述。

下面我要說(shuō)的內(nèi)容，有可能會(huì)傷害很多讀者，但是，請(qǐng)不要“恨”我。

RxJava，是一個(gè) Andorid 中常見(jiàn)的多線(xiàn)程框架。但是它現(xiàn)在將逐漸退出歷史的舞臺(tái)。從 StackOverflow 的趨勢(shì)圖可以看出：

RxJava 使用趨勢(shì)

很多開(kāi)發(fā)者對(duì)這個(gè)說(shuō)法提出了質(zhì)疑，他們反駁說(shuō)這個(gè)數(shù)據(jù)不具有代表性，并且我們可以找到其它的理由來(lái)解釋圖上所發(fā)生的事情。他們所說(shuō)可能是正確的，我個(gè)人本身也不是數(shù)據(jù)科學(xué)家。但是從圖中我們可以看到，RxJava 與 AsnycTask 有相同的斜率。

如果你沒(méi)有時(shí)間去學(xué)習(xí) RxJava 如何使用，并且你的項(xiàng)目中也沒(méi)有使用過(guò) RxJava，我建議你不要在你的項(xiàng)目中使用 RxJava。事實(shí)上，我也一直不推薦使用 RxJava ，現(xiàn)在已經(jīng)有數(shù)據(jù)支持我的這個(gè)觀點(diǎn)了。

如果你的項(xiàng)目中使用了 RxJava，你也不用慌張，不需要緊急去重構(gòu)你的項(xiàng)目。如果你的項(xiàng)目只有你一個(gè)人，或者整個(gè)項(xiàng)目組成員基本不會(huì)變動(dòng)，保持項(xiàng)目現(xiàn)狀就好了。但是你需要記住，以后要招具有 RxJava 開(kāi)發(fā)經(jīng)驗(yàn)的人會(huì)越來(lái)越困難，新招開(kāi)發(fā)人員可能需要學(xué)習(xí)使用 RxJava。廣泛使用 RxJava 的項(xiàng)目，在以后也會(huì)被認(rèn)為"不酷"，就像今天還在使用 AsyncTask 和 Loader 的項(xiàng)目一樣。

我知道，很多 RxJava 的開(kāi)發(fā)者都是 RxJava 骨灰級(jí)的粉絲，他們花了數(shù)周的時(shí)間去學(xué)習(xí) RxJava，付出巨大的努力才說(shuō)服隊(duì)友在項(xiàng)目中使用 RxJava。現(xiàn)在我卻在這里說(shuō) RxJava 已經(jīng)過(guò)時(shí)了。我只能說(shuō)，這不是我的個(gè)人意見(jiàn)，我只是對(duì)現(xiàn)有的情況進(jìn)行分析，并根據(jù)我所看到的內(nèi)容做出預(yù)測(cè)。我也有可能是錯(cuò)的。兩軍交戰(zhàn)，不斬來(lái)使，請(qǐng)大家不要“攻擊”我。

在 Kotlin 中，使用協(xié)程來(lái)實(shí)現(xiàn)多并發(fā)。最近使用協(xié)程實(shí)現(xiàn)了一些簡(jiǎn)單的用例[15]，我發(fā)現(xiàn)它復(fù)雜、不穩(wěn)定，甚至還有一些 Bug。

所有的人都在說(shuō)，協(xié)程可以降低并發(fā)的復(fù)雜度，使用并發(fā)變得簡(jiǎn)單。我從來(lái)都不相信這句話(huà)，因?yàn)槲抑啦l(fā)從根本上來(lái)說(shuō)就是很復(fù)雜的。我動(dòng)手寫(xiě)過(guò)一些測(cè)試用例過(guò)后，據(jù)我的經(jīng)驗(yàn)，我可以很自信的告訴你，協(xié)程不能使并變得簡(jiǎn)單。我認(rèn)為，協(xié)程會(huì)增加復(fù)雜性，我建議你們謹(jǐn)慎使用他們。

在 Kotlin 中，協(xié)程將作為處理多線(xiàn)程的默認(rèn)方式，如果你已經(jīng)開(kāi)始使用 Kotlin 進(jìn)行開(kāi)發(fā)，那么你應(yīng)該花點(diǎn)時(shí)間，去學(xué)習(xí)一下，協(xié)程的使用。

據(jù)我所知，還有一個(gè) Flow 框架，它是基于協(xié)程，添加了流運(yùn)算符。在幾個(gè)月之前，已經(jīng)穩(wěn)定了。所以現(xiàn)在也沒(méi)啥好評(píng)價(jià)的。

Kotlin

現(xiàn)在，讓我們來(lái)討論一下 Kotlin 在 Android 領(lǐng)域的現(xiàn)狀。根據(jù)我個(gè)人的經(jīng)驗(yàn)來(lái)看，這是一個(gè)很敏感的話(huà)題，不論我所說(shuō)的話(huà)有多么公正客觀，都會(huì)有一些粉絲評(píng)價(jià)我所說(shuō)的話(huà)是“Shit”。但從專(zhuān)業(yè)的角度來(lái)說(shuō)，Kotlin 的話(huà)題是跳不過(guò)去的，所以，我要強(qiáng)調(diào)的是，這些內(nèi)容只是我的個(gè)人觀點(diǎn)，僅供參考。

在 Android 開(kāi)發(fā)中，使用 Kotlin，會(huì)大大地增加你的編譯時(shí)間。

在我的另一篇文章中[16]，我統(tǒng)計(jì)了使用 Kotlin 過(guò)后，編譯時(shí)間的增長(zhǎng)情況。結(jié)果是，全量編譯的情況下，會(huì)增加 18%左右的耗時(shí)，如果是增量編譯，則會(huì)增加 8% 左右的耗時(shí)。

Uber 和 JetBrains 聯(lián)合發(fā)表了他們有關(guān) Kotlin 對(duì)項(xiàng)目編譯時(shí)間的影響， 在文章中，顯示的結(jié)果非常的悲觀。他們表示，如果你不開(kāi)啟 IDE 中的 annotation processors ，引入 Kotlin 的項(xiàng)目，編譯構(gòu)建的時(shí)間大約會(huì)增加四倍，如果開(kāi)啟了 annotation processors，編譯構(gòu)建的時(shí)間也會(huì)增加 50% ~ 100%。

Uber 的結(jié)果與 OkHttp 遷移到 Kotlin 后得到的結(jié)果是一致的，都是編譯時(shí)長(zhǎng)都增加了 4 倍。

別擔(dān)心，雖然這個(gè)結(jié)果讓人吃驚，這個(gè)也不是你的錯(cuò)，很多人都和你一樣，正在使用 Kotlin。這個(gè)問(wèn)題，雖然很重要，但是它并沒(méi)有引起廣泛的關(guān)注。我覺(jué)得，Google 也在試圖解決這個(gè)問(wèn)題。我曾問(wèn)過(guò) Google 相關(guān)的開(kāi)發(fā)者，并進(jìn)行了深度的交流，他們?cè)谶@個(gè)問(wèn)題給我的回答是：“這是一個(gè)很棘手的問(wèn)題，我寧愿不做”。

Kotlin 除了會(huì)增加編譯時(shí)間，直到上周，才支持增量注解處理，而 Java ，在 10 個(gè)月以前就支持了。

在兩年前，我就寫(xiě)了篇文章用于告誡大家，過(guò)早使用 Kotlin 會(huì)存在很大的風(fēng)險(xiǎn)。你可以從評(píng)論中可以看出，我在很長(zhǎng)的一段時(shí)間里面，都是“Kotlin 的黑粉”。

在你的實(shí)際工作中，你會(huì)發(fā)現(xiàn)，與上面的數(shù)據(jù)相比，Kotlin 的問(wèn)題遠(yuǎn)不止于此。在大型的 Android 項(xiàng)目中，編譯構(gòu)建的時(shí)間會(huì)嚴(yán)重阻礙項(xiàng)目的發(fā)展。即使到了今天，Kotlin 已經(jīng)被正式使用兩年了，Kotlin 編譯效率依然比 Java 差很多。不管 Kotlin 能給你帶來(lái)多少優(yōu)點(diǎn)，編譯耗時(shí)的問(wèn)題，都有可能導(dǎo)致你不在使用它。

不管如何，Google 向整個(gè) Android 的開(kāi)發(fā)生態(tài)推出 Kotlin 作為第一首選語(yǔ)言，現(xiàn)在 Kotlin 的使用量也越來(lái)越大，我們也不得不進(jìn)行跟進(jìn)。就我個(gè)人而言，我還沒(méi)有在我的項(xiàng)目中使用 Kotlin。因?yàn)?Kotlin 還不夠成熟，并且我的客戶(hù)也不會(huì)為我的學(xué)習(xí)付費(fèi)，并且我也不希望在 Kotlin 上浪費(fèi)時(shí)間。但是從現(xiàn)在開(kāi)始，Kotlin 已經(jīng)逐漸穩(wěn)定，我也在我拿手的項(xiàng)目上嘗試過(guò)， 在新項(xiàng)目中，我也會(huì)考慮使用它進(jìn)行開(kāi)發(fā)。有一些開(kāi)發(fā)者認(rèn)為：“必須在新項(xiàng)目中使用 Kotlin 進(jìn)行開(kāi)發(fā)“，我不同意這個(gè)觀點(diǎn)，我覺(jué)得這是一個(gè)權(quán)衡的問(wèn)題，Kotlin 現(xiàn)在已經(jīng)成為了一個(gè)重要的選項(xiàng)，只要適合當(dāng)前的項(xiàng)目，就是最好的語(yǔ)言。

對(duì)于是否要將已有的項(xiàng)目遷移到 Kotlin 上， 我不能給你太好的建議。你需要根據(jù)你項(xiàng)目的情況，具體問(wèn)題具體分析。如果你一旦決定要進(jìn)行遷移，這篇文章中列舉的一些可能存在的問(wèn)題，可能對(duì)你有幫助。

總結(jié)

請(qǐng)?jiān)试S我用 Android 開(kāi)發(fā)者的背景，描述一下我這兩年所經(jīng)歷的事情：

在過(guò)去的兩年里，我啟動(dòng)了三個(gè)項(xiàng)目，我一直爭(zhēng)取，至少參與其中一個(gè)項(xiàng)目的開(kāi)發(fā)工作。我回過(guò)頭來(lái)看這些已經(jīng)存在的項(xiàng)目，并分析這些項(xiàng)目前期所做的技術(shù)決定對(duì)整個(gè)項(xiàng)目的影響。我寫(xiě)了這篇文章，也制作了很多 Android 開(kāi)發(fā)的高級(jí)課程，也花了很多時(shí)間在互聯(lián)網(wǎng)上討論 Android 相關(guān)的主題。

即使這樣，我今天依然感覺(jué)跟不上 Android 整個(gè)生態(tài)系統(tǒng)的變化。可想而知，對(duì)于那些經(jīng)驗(yàn)不足，需要指導(dǎo)的 Android 開(kāi)發(fā)者而言，是多么地絕望。我現(xiàn)在已經(jīng)無(wú)法想像，現(xiàn)在從頭開(kāi)始學(xué)習(xí) Android 的感覺(jué)。當(dāng)你好不容易學(xué)會(huì)了某個(gè)框架或者工具，覺(jué)得它很好用的時(shí)候，它或許就要過(guò)時(shí)了。現(xiàn)在也許是加入 Android 開(kāi)發(fā)大家庭最壞的時(shí)候。Google 正為他們的“包容性”沾沾自喜，但這一切，對(duì)初學(xué)者來(lái)說(shuō)，都是極其痛苦的。

Google 在 Android 框架中所做的事情，會(huì)導(dǎo)致大量的時(shí)間浪費(fèi)。我們需要花費(fèi)數(shù)小時(shí)的時(shí)間才能讀完所有更改的內(nèi)容，更別說(shuō)在項(xiàng)目中應(yīng)用它們了。我寧愿花時(shí)間來(lái)創(chuàng)造價(jià)值，而不是舍本逐末。

在本文中，我試圖總結(jié) Android 開(kāi)發(fā)的現(xiàn)狀，并對(duì)未來(lái)作出了一些預(yù)測(cè)。文章中，可能包含錯(cuò)誤和漏掉一些重要信息，請(qǐng)隨時(shí)在下面的評(píng)論中告知我。文章中的內(nèi)容都是客觀內(nèi)容，雖然我提出了一些有爭(zhēng)議觀點(diǎn)，但我相信我是對(duì)的。

還有，在文章中，我引用了很多之前寫(xiě)的帖子，我并不是為了炫耀。而是讓你能夠閱讀之前的預(yù)測(cè)與現(xiàn)在的狀況進(jìn)行對(duì)比，雖然那些文章在那個(gè)時(shí)候讀起來(lái)很瘋狂，就像現(xiàn)在你讀本文一樣，但是我的這些預(yù)測(cè)都是很準(zhǔn)確的。當(dāng)然，我也想說(shuō)：“看，我說(shuō)得對(duì)吧”。鑒于我發(fā)布的內(nèi)容具有爭(zhēng)議，當(dāng)?shù)弥獩](méi)有誤導(dǎo)讀者，我也會(huì)感到很欣慰。有時(shí)候，我也寧愿我的預(yù)測(cè)是錯(cuò)的，Google 正在為開(kāi)發(fā)者著想。但是到目前為止，情況并非如此。

一如既往，感謝你的閱讀。你可以在下面留言評(píng)論和提問(wèn)。

[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，獨(dú)立 Android 開(kāi)發(fā)及軟件顧問(wèn)

譯者：羅昭成，Android 開(kāi)發(fā)者

情期間，看病就醫(yī)如何保證安全？觀觀為您搜集了最強(qiáng)安全就醫(yī)攻略。

非急診分時(shí)段預(yù)約就診

疫情期間，川大華西醫(yī)院、四川省人民醫(yī)院、省腫瘤醫(yī)院等四川省內(nèi)各大醫(yī)院實(shí)行非急診分時(shí)段預(yù)約就診，需要提前掛號(hào)預(yù)約就診，患者可以通過(guò)網(wǎng)上預(yù)約、電話(huà)預(yù)約或者醫(yī)院自助機(jī)預(yù)約。疫情期間倡議患者減少陪同家屬，候診時(shí)需帶好口罩，保持1米間距。

住院病人“一人一陪護(hù)”

疫情期間全省各地醫(yī)院嚴(yán)格執(zhí)行疫情期間住院病人“一人一陪護(hù)”的規(guī)定，新入院病人須接受至少一次核酸檢查。住院患者原則上不留陪護(hù)；確因病情或手術(shù)需要必須陪護(hù)時(shí)，須一對(duì)一陪護(hù)且相對(duì)固定，做到“一患一陪一證”，禁止多人陪護(hù)或輪流陪護(hù)；探視人員可通過(guò)語(yǔ)音或視頻問(wèn)候患者。

發(fā)熱病人應(yīng)選擇發(fā)熱門(mén)診就近就診

體溫超過(guò)37.3℃的患者，去醫(yī)院就診時(shí)應(yīng)直接去發(fā)熱門(mén)診，避免出現(xiàn)交叉感染。到發(fā)熱門(mén)診就診時(shí)應(yīng)戴好口罩， 主動(dòng)告訴醫(yī)務(wù)人員近期是否去過(guò)有流感或不明原因肺炎疫情的地區(qū)，有無(wú)與發(fā)熱、咳嗽等癥狀的患者近距離接觸史，便于醫(yī)務(wù)人員準(zhǔn)確確定病情，采取及時(shí)適宜的治療。

點(diǎn)擊即可查看全省發(fā)熱門(mén)診名單：https://kscgc.sctv.com/sctv/redian/2021/02/10/1077725_shared.html

“黃碼”患者可到定點(diǎn)機(jī)構(gòu)看病就醫(yī)

目前各縣（市、區(qū)）均設(shè)有“黃碼”患者醫(yī)療服務(wù)定點(diǎn)醫(yī)院，最新名單可在四川省衛(wèi)生健康委員會(huì)官方網(wǎng)站和天府健康通“醫(yī)療防疫機(jī)構(gòu)查詢(xún)”模塊中查詢(xún)。

“黃碼”人員要規(guī)范佩戴好口罩，按“黃碼”人員管控規(guī)定就近前往醫(yī)療服務(wù)定點(diǎn)醫(yī)院。醫(yī)院為“黃碼”患者開(kāi)通綠色通道，由預(yù)檢分診工作人員引導(dǎo)至發(fā)熱門(mén)診，進(jìn)行詳細(xì)流行病學(xué)調(diào)查和核酸檢測(cè)。現(xiàn)場(chǎng)核酸檢測(cè)陰性的，可自行到相關(guān)臨床科室診治。現(xiàn)場(chǎng)核酸檢測(cè)陽(yáng)性的，就地留觀隔離，等待復(fù)核排查，確診后立即按規(guī)定轉(zhuǎn)新冠肺炎救治定點(diǎn)醫(yī)院治療。

附：“黃碼”患者醫(yī)療服務(wù)定點(diǎn)醫(yī)療機(jī)構(gòu)名單