整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
你好不容易學會了某個框架或者工具，覺得它很好用的時候，它或許就要過時了。
作者 | 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 開發者
城派記者 張豪 梁懌韜
通訊員 成廣偉
建鄉村公廁、裝配式公廁，開放公共機構廁所……今年以來，廣州已完成191座公共廁所建設任務，其中新建公廁62座，升級改造129座，推進公廁便民服務工作，打造廣州市智慧公廁，昨日（8月8日）廣州正式上線安卓版“廣州公廁”APP，使市民方便更輕松。
據介紹，截止7月31日，全市已完成191座公共廁所建設任務（新建公廁62座，升級改造129座），其中：環衛公廁34座、旅游公廁59座、鄉村公廁22廁、客運站公廁5座、加油站公廁10座、公園公廁9座、市場公廁3座、醫院公廁45座、體育場館公廁3座、地鐵公廁1座。
在完成的191座公廁中，均按照《廣州市公共廁所建設與管理標準指引》增設了“六小件”等人性化服務設施，修建了殘疾人、老年人廁位及通道和扶手，其中有34座一類公廁建設了第三衛生間、有10座建設了母嬰室。
打造廣州市智慧公廁
據了解，為進一步方便市民找公廁、用公廁，廣州城管部門在原有“廣州城管”微信公眾號“一鍵找公廁”的基礎上，8月8日正式上線安卓版廣州公廁APP（下載地址：https://shared-toilet.vanfangyun.com/app/download.html））
為配合“廣州公廁”APP的正式上線，廣州城管部門還對全市公廁云平臺點位進行了一次“大體檢”，截止日前已完成全市公廁云平臺點位核查任務，已核查公廁數量6895座，核準公廁數量5850座，核銷不存在公廁1045座，糾正不準確公廁點位349座，初步建成市、區后臺管理工作機制，實現了一張地圖找廁所、用廁所、評廁所，方便市民群眾和游客入廁。
如何使用廣州給公廁APP？
記者打開廣州公廁App，會彈出所在位置地圖，上面有系統自動查找的周邊廁所。
選擇其中一所公廁后，點擊導航地圖下方的公廁地址，可以查看公廁詳情，顯示這間公廁的設施設備，例如是否有廁紙配備，是否有母嬰室、殘疾人公廁、第三洗手間等功能。
點擊“到這去”按鈕，即可彈出導航，幫助市民準確找到目的地的洗手間。
在公廁詳情中，有評價欄，可以對公廁衛生、環境和氣味狀況進行評分，并可通過文字和照片對其進行評論描述。在周邊有多間廁所的情況下，市民根據他人的評分選擇合適的廁所，更是對進一步做好公廁保潔和管理工作的督促。
除了“找公廁”，市民和單位還能共享自家洗手間。在App界面的左上角有個“+”鍵，點擊進去后，可對廁所進行共享，填寫公廁名稱、詳細地址、所屬單位等相關資料后，點擊右上角的“√”鍵，提交成功并通過相關管理部門審核通過后的廁所會添加完善至系統內。
鼓勵沿街單位共享內設廁所，為市民打開方便之門。（更多新聞資訊，請關注羊城派 pai.ycwb.com）
來源｜羊城派
責編｜胡曉倩
情期間，看病就醫如何保證安全？觀觀為您搜集了最強安全就醫攻略。
非急診分時段預約就診
疫情期間，川大華西醫院、四川省人民醫院、省腫瘤醫院等四川省內各大醫院實行非急診分時段預約就診，需要提前掛號預約就診，患者可以通過網上預約、電話預約或者醫院自助機預約。疫情期間倡議患者減少陪同家屬，候診時需帶好口罩，保持1米間距。
住院病人“一人一陪護”
疫情期間全省各地醫院嚴格執行疫情期間住院病人“一人一陪護”的規定，新入院病人須接受至少一次核酸檢查。住院患者原則上不留陪護；確因病情或手術需要必須陪護時，須一對一陪護且相對固定，做到“一患一陪一證”，禁止多人陪護或輪流陪護；探視人員可通過語音或視頻問候患者。
發熱病人應選擇發熱門診就近就診
體溫超過37.3℃的患者，去醫院就診時應直接去發熱門診，避免出現交叉感染。到發熱門診就診時應戴好口罩， 主動告訴醫務人員近期是否去過有流感或不明原因肺炎疫情的地區，有無與發熱、咳嗽等癥狀的患者近距離接觸史，便于醫務人員準確確定病情，采取及時適宜的治療。
點擊即可查看全省發熱門診名單：https://kscgc.sctv.com/sctv/redian/2021/02/10/1077725_shared.html
“黃碼”患者可到定點機構看病就醫
目前各縣（市、區）均設有“黃碼”患者醫療服務定點醫院，最新名單可在四川省衛生健康委員會官方網站和天府健康通“醫療防疫機構查詢”模塊中查詢。
“黃碼”人員要規范佩戴好口罩，按“黃碼”人員管控規定就近前往醫療服務定點醫院。醫院為“黃碼”患者開通綠色通道，由預檢分診工作人員引導至發熱門診，進行詳細流行病學調查和核酸檢測。現場核酸檢測陰性的，可自行到相關臨床科室診治。現場核酸檢測陽性的，就地留觀隔離，等待復核排查，確診后立即按規定轉新冠肺炎救治定點醫院治療。
附：“黃碼”患者醫療服務定點醫療機構名單
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
