[[313474]]

前言

Android原生開發(fā)的生態(tài)一直在不斷地發(fā)展變化，過去5年從事android開發(fā)的經(jīng)歷讓我深刻的體會到了這一點。每隔2到3年，谷歌就會發(fā)布一些的新的開發(fā)指導建議、libraries、frameworks，我花了很多時間來認真審查這些變化并從中找出可能存在的問題。我相信許多Android開發(fā)者都有我這樣類似的經(jīng)歷。

然而，2019年絕對是Android原生開發(fā)生態(tài)發(fā)生劇變的一年。在這一年里，Android sdk添加了許多新的內(nèi)容、重寫和移除了一些舊的內(nèi)容，官方的開發(fā)者指南也進行了大幅度的更新。想要對Android開發(fā)有一種完整而又詳細的認識實在是太難了。

于是我寫下了這篇文章，我試圖去總結(jié)Android生態(tài)系統(tǒng)中所發(fā)生的事情，并對原生開發(fā)的未來做出一些預測。接下來我會把我的觀點分成不同的章節(jié)來進行具體的闡述，文章的最后我會分享一些極具爭議的觀點。

我希望這篇文章會對你們有所幫助，但是請記住，文章中肯定遺漏了許多重要的內(nèi)容，而且其中的許多觀點都是我個人的偏見。

AndroidX

AndroidX的預覽版是在一年半前發(fā)布的。大約一年前它變得穩(wěn)定了，與此同時Google也停止了對舊版Support Library的進一步開發(fā)。當我寫下這句話的那一刻，我想起了我之前在StackOverflow上提出的一個問題：Why does AOSP add new APIs to support libraries without adding them to SDK?（https://stackoverflow.com/questions/29197821/why-does-aosp-add-new-apis-to-support-libraries-without-adding-them-to-sdk），當時我是一個android開發(fā)新手，我想知道Support Library背后的動機，Googl為什么不直接把Support Library放到android sdk里呢？

不過使用“穩(wěn)定”一詞來描述AndroidX似乎有點諷刺，因為關(guān)于AndroidX的任何信息似乎都不是穩(wěn)定的。 Google不斷的在往AndroidX里添加新的庫和框架。 命名空間和許多舊的API（目前還不到一年）正在以非?？斓乃俣劝l(fā)展。

[[313475]]

到目前為止，我已經(jīng)將我的兩個應用遷移到了AndroidX。 一切都很順利，但我也不覺得有多驚喜。 Jetifier是一種將Support Library上的依賴項重定向到其AndroidX對等項的工具，轉(zhuǎn)換效果令人驚訝。 但是即使應用程序不大，也并不是“一鍵式遷移”。

我還參與了一個尚未遷移到AndroidX的項目，沒有任何問題。在某些情況下，似乎我完全不需要AndroidX。

總而言之，我想說的是：如果是開啟新的Android項目，那么肯定是應該使用AndroidX；對于現(xiàn)有的項目，我也建議您做好遷移到AndroidX的計劃，即使您現(xiàn)在看不到明顯的好處。 無論如何，您很可能都需要遷移，因此最好按自己的計劃進行遷移，而不是以后當你需要一些新的AndroidX庫時進行緊急的遷移

Jetpack

在討論完AndroidX之后，就不得不提到Jetpack了。 據(jù)我所知，Jetpack最初只是“architecture components”的工具集合，但是后來擴展為包含了AndroidX的大多數(shù)（甚至所有）API的工具集合。 因此，到目前為止，我還沒有看到AndroidX和Jetpack之間有任何有意義的區(qū)別，市場營銷和公關(guān)宣傳除外。

當您訪問Jetpack（https://developer.android.com/jetpack）的官方網(wǎng)站時，它看起來不像是技術(shù)文檔，更像是早期SaaS初創(chuàng)公司的主頁。

看看這些“感言”：

再看看下面這些app：

如果Jetpack申請2020年獨立IPO，我不會感到驚訝，因為他們是如此的專注于營銷和公關(guān)。

不過說真的，這種向自己的生態(tài)系統(tǒng)中的開發(fā)人員“銷售”api的做法存在一些深層次的問題。比如，為什么有人真的想在搜索中宣傳ViewModel？

總而言之，由于Jetpack的大部分內(nèi)容都是來源于AndroidX，所以我之前寫的有關(guān)AndroidX的內(nèi)容在很大程度上也適用于Jetpack。

下面，我將分別討論其中一些具體的API。

Background Work

當應用程序不在前臺時讓應用也能執(zhí)行操作是Android開發(fā)中最常見的場景之一。 在引入doze模式、SyncAdapter、GCMNetworkManager、FirebaseJobDispatcher、JobScheduler以及最近的WorkManager之前，您可以通過啟動服務（而不是綁定服務）來實現(xiàn)。 這些都是Google自己的API，不過也有很多第三方解決方案，比如Android-Job。

但是，Google最近宣布，他們將通過WorkManager API來統(tǒng)一后臺任務的調(diào)度（https://android-developers.googleblog.com/2019/11/unifying-background-task-scheduling-on.html）。聽起來很不錯，但是由于某種原因，當我聽到這樣的聲音時，我總有種似曾相識的感覺……

無論最終能否統(tǒng)一，WorkManager都無法解決在執(zhí)行后臺任務過程中存在的一個最嚴重的問題：可靠性。我在這里不做解釋，但是請記住，如果您需要在應用程序中執(zhí)行后臺任務，請先閱讀dontkillmyapp.com（https://dontkillmyapp.com）上的所有信息。此外，請在Google的issue tracker中閱讀并加注星標。

Android系統(tǒng)的后臺任務執(zhí)行與調(diào)度是一團糟，碎片化使得它非常細微且不可靠。

過去，我一直主張盡可能的將數(shù)據(jù)同步等類似的工作放在后臺來執(zhí)行，我可能是SyncAdapter的最后一批粉絲。 但是今天，鑒于可靠性問題，我主張相反的做法：盡可能避免在后臺執(zhí)行操作。 如果您的PM堅持使用此功能，請向他們展示以上鏈接，并向他們解釋，后臺任務需要花費數(shù)百小時的時間來實現(xiàn)，而且?guī)淼穆闊┒嘤谑找妗?/p>

有些時候執(zhí)行后臺任務是不可避免的，但是在大多數(shù)情況下，您可以不這樣做。即使以給用戶帶來一些不便為代價，它也可能是最佳選擇。

Databases

毫無疑問，Room在眾多SQLite的ORM框架中占據(jù)著主導地位。從2.2.0開始，Room支持增量注解處理。不過請記住，您的應用架構(gòu)不應過于關(guān)心使用了哪種ORM框架。因此，作為architecture components的一員，Room只是市場術(shù)語，而不是技術(shù)角色。

Android開發(fā)中ORM框架的主要競爭者是SQLDelight。 這個庫比Room還要老，但是據(jù)我了解，在過去的一年左右的時間里，它已經(jīng)被重寫了很多。 不幸的是，它現(xiàn)在只針對Kotlin。 另一方面，SQLDelight支持Kotlin跨平臺。 因此，隨著Kotlin使用率的增加，我預計SQLDelight的使用率也會隨之增加。

順便說一下，AndroidX中有對原生SQLite的使用說明，我還不知道該怎么使用。但是如果您想在應用中使用原生SQLite，那么你或許需要去認真的研究下這個主題。

[[313476]]

此外還有許多針對Android的非關(guān)系型的數(shù)據(jù)庫，例如Realm，Parse，F(xiàn)irebase，ObjectBox等（其中有些仍在使用SQLite）。如果我沒記錯的話，它們中的大多數(shù)（甚至全部）都具有自動數(shù)據(jù)同步功能。 一段時間以來，這些解決方案比較流行，但據(jù)我所知，它們已經(jīng)不復存在了。但是我并不會馬上認為非關(guān)系型的數(shù)據(jù)庫不再重要了。

去年，我編寫了一個非常復雜的集成了Parse Server的Android應用。 我使用了Android版本的的Parse SDK，體驗都非常好。如果您的公司已經(jīng)雇用了許多后端開發(fā)人員，或者您需要實現(xiàn)許多服務器端邏輯，這可能不是最佳解決方案，但是對于僅在后端執(zhí)行CRUD操作的初創(chuàng)企業(yè)和個人來說，這可能會是一種好的選擇。

但是我必須提醒的一點是：如果您要采用數(shù)據(jù)庫即服務的解決方案（例如Firebase），那么請務必了解其長期的成本和影響。

External Storage

關(guān)于外部存儲的開發(fā)，這里有許多有“意思”的事情。

如果您應用的target sdk版本等于或者大于29，那么你的應用將無法再正常訪問手機外部存儲上的文件，除了少數(shù)幾種明顯的情況。 相反，您需要使用SAF框架（據(jù)說），該框架允許用戶進行更精細的訪問管理。不幸的是，SAF的工作方式與之前完全不同，因此某些應用程序可能需要進行重大重構(gòu)。

Google希望從Android 10開始對所有的應用程序都實行這一要求，但它引起了開發(fā)者社區(qū)的強烈抗議，于是他們決定推遲此功能。 因此，即使您的應用設置target sdk版本為 29，它仍可以在“舊版”模式下工作。 但是，無論目標API級別是多少，下一版的Android系統(tǒng)都將對所有應用的存儲訪問范圍做更加嚴格的限制。

到目前為止，我還沒有使用SAF框架，但是從我在互聯(lián)網(wǎng)上閱讀的許多討論中看來，這可能是一項艱巨的任務。因此，如果您的應用程序還在以“舊版”模式使用外部存儲，那么最好立即開始進行重構(gòu)和測試。

Shared Preferences

幾周前，AndroidX系列中添加了一個新框架（https://www.techyourchance.com/the-state-of-native-android-development-november-2019）。它的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和這個新框架之間的主要區(qū)別在于，默認情況下后者是異步的。 換句話說，您需要實現(xiàn)一個回調(diào)以獲取特定鍵的值，該回調(diào)將在以后的某個時間收到通知。

如果您對這種異步通知的機制感到好奇，則可以閱讀StackOverflow上的這個答案（https://stackoverflow.com/questions/37549578/how-to-get-something-useful-from-this-anr-log/37551254#37551254）。Reddit用戶Tolriq在這里分享了他們遇到此bug的概率。在他們的應用中，這個bug會影響1 / 10,000 / SESSIONS_PER_USER_PER_MONTH的用戶。對于一般的應用程序，這可能微不足道。但是在需要高可靠性的情況下，這可能會引起嚴重的后果。例如，在裝有Android Auto的汽車中，應用程序掛起和隨后的崩潰會分散駕駛員的注意力，這可能會導致非常不幸的后果。

Dependency Injection

在依賴注入方面，最大的變化就是Dagger-Android的棄用。這里我想解釋兩點：首先，我說的棄用并不是指“正式”棄用，因為它尚未正式棄用。其次，Dagger-Android并不是整個Dagger2框架，而只是相對較新的功能。我在這個主題上寫了一篇非常詳盡的文章（https://www.techyourchance.com/dagger-android-dead/），所以我在這里不再重復。

至于其他依賴注入框架，我不認為它們是Dagger的真正競爭者。 例如，Koin也許不錯，但我認為它不會吸引很多人。 實際上，我相信它僅由于兩個主要原因而得到了初步采用。 第一個是Dagger的糟糕文檔，Koin在這方面要比Dagger領先N光年。 第二個原因是Koin是用Kotlin編寫的，它借著kotlin發(fā)展的浪潮開始興起。 到目前為止，這波浪潮已經(jīng)幾乎消逝。

我認為可能會發(fā)生的情況是，純依賴注入的框架（又稱為手動依賴注入）會逐漸出現(xiàn)。

現(xiàn)在，谷歌聲稱“隨著應用程序的不斷增大，手動依賴項注入成本呈指數(shù)增長”。 我認為，這僅表明他們既不了解“指數(shù)”的含義，也沒做過任何實際的“測量”。 此聲明是完全錯誤的，我希望Google不要以這種方式來誤導社區(qū)里的開發(fā)者了。

事實上，純依賴注入在后端開發(fā)中非常普遍（尤其是在開發(fā)微服務的時候，您不想在其中添加對每個服務的框架的依賴），反射也是后端開發(fā)中的一個有效的選項。 因此，如果要使用依賴注入框架，他們通常不需要解析編譯時代碼。

但是，Android開發(fā)的情況有所不同。由于我們不能使用反射式DI框架，所以我們使用了Dagger。事實上，我們可以使用反射式DI框架，并且對于大多數(shù)項目來說都可以，但是卻存在性能問題。我并不是說使用反射式DI框架是安全的，但它絕對不是一種非黑即白的方案。無論如何，Dagger已經(jīng)是在Android開發(fā)中使用依賴注入的事實上的標準，我們都使用它。但使用Dagger的代價也很明顯：

• 1）應用的代碼越多，在構(gòu)建過程中運行注解處理所花費的時間就越多。

• 2）應用參與的開發(fā)人員越多，他們需要執(zhí)行的構(gòu)建次數(shù)就越多。

• 3）所有開發(fā)人員都需要學習Dagger ，這需要很多時間。

換句話說，雖然Dagger確實允許您編寫更少的代碼，但由于它會影響構(gòu)建時間和所需的培訓時間，因此在大型項目上它會花費更多的時間。

在大型項目中，構(gòu)建時間慢才是真正的問題，并成為主要的生產(chǎn)力瓶頸。 因此，盡管Dagger確實提供了非常出色的功能來簡化DI（當然，一旦您知道如何使用它），但我相信我們對純依賴注入會產(chǎn)生越來越多的興趣。

DataBinding

開發(fā)人員采用DataBidning的主要原因之一是不再需要調(diào)用findViewById了。 老實說，findViewById確實很冗余，我也不介意擺脫它們。 但是，在我看來，調(diào)用findViewById帶來的小麻煩并不能證明使用DataBinding是合理的。 好消息是，很快我們將能夠使用另一個新功能ViewBinding來刪除這些findViewById的調(diào)用。

實際上，我從來都不相信DataBinding。對于它（應該）解決的問題，我感覺太復雜了。 此外，DataBinding允許開發(fā)人員將邏輯放入XML布局中。 經(jīng)驗豐富的開發(fā)人員是不會使用這種方法的，因為這增加了項目維護的難度。這是DataBinding框架的另一個缺點。

早在2016年11月，當DataBinding正處于大肆宣傳的頂峰時，我在StackOverflow上的一個答案（https://stackoverflow.com/questions/4916209/which-architecture-patterns-are-used-on-android/30628530#30628530）中做出了以下預測：

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.

現(xiàn)在，關(guān)于DataBinding的使用率，我沒有任何統(tǒng)計數(shù)據(jù)，但是很明顯，它并沒有成為行業(yè)標準。 我自己還從未見過使用DataBinding的專業(yè)項目，也很少見到在其應用中使用DataBinding的開發(fā)人員。據(jù)我估計，一旦ViewBinding成熟并被廣泛采用，DataBinding將會更加流行，并成為“傳統(tǒng)”框架。

Preserving State on Configuration Changes

自從引入ViewModel之后，在Android應用中對于配置更改的處理就變得一團糟。 我知道我的這種說法太苛刻了點，但實際上，這是我可以描述的最溫和的表達方式。

對我來說幸運的是，Gabor Varadi（又名Zhuinden）已經(jīng)在Reddit上的這篇文章（https://www.reddit.com/r/androiddev/comments/b908fr/can_someone_explain_to_me_why_aac_is_trying_to）中對這一問題進行了總結(jié)，所以我不需要自己做。他的結(jié)論就是：不推薦使用onRetainCustomNonConfigurationInstance，而推薦使用ViewModel。有趣的是，在該帖子的結(jié)尾，Gabor做了一些頗具嘲諷味道的預測：

你發(fā)現(xiàn)什么了嗎？ Retained Fragments現(xiàn)在已經(jīng)被棄用了！。

我認為，棄用Retained Fragments實際上是一個好主意。Fragment的生命周期里具有onAttach和onDetach這兩個方法的唯一原因就是為了支持Retained Fragments的使用。通過棄用Retained Fragments，這些方法也可以棄用，并且可以簡化Fragment的生命周期。如果您使用我的方法(https://www.techyourchance.com/android-fragment-lifecycle-for-professional-developers)來處理Fragment的生命周期，那么這種棄用就不會讓您感到困擾，因為我長期以來一直建議您避免Retained Fragments，忽略onAttach和onDetach方法。

盡管有充分的理由要棄用Retained Fragments，但棄用onRetainCustomNonConfigurationInstance卻是胡說八道。 這不是我說的，而是Jake Wharton說的（您可以在前面提到的Gabor在Reddit上的帖子下閱讀他的原話）。

為什么要做這些變動呢？我只能看到一種解釋：Google決定不管其它技術(shù)優(yōu)勢如何，都強制將所有Android項目遷移到ViewModel。 他們愿意棄用所有現(xiàn)有的替代方案以實現(xiàn)其目標，即使這些替代方案實際上優(yōu)于ViewModel本身。

聽起來有點陰謀吧？ 我同意。 但是，幸運的是，我們可以對此理論有一個簡單的檢驗。

雖然我不喜歡Preserving State on Configuration Changes，但它不會以任何方式影響我，因為我沒有使用它。 實際上，絕大部分應用程序都不需要它。 它們也不需要ViewModel。正確處理Configuration Changes的方式就是在onSaveInstanceState（Bundle）回調(diào)方法里增加處理邏輯。 這是一種更簡單，更好的方法，因為它還可以處理保存和恢復流程（也稱為進程終止）。 因此，只要我能以這種方式保存狀態(tài)，就可以了。 盡管Google進行了大量的營銷和公關(guān)工作，但許多經(jīng)驗豐富的開發(fā)人員都意識到ViewModel太復雜了，并且有更好的方法來保留配置更改的狀態(tài)。

因此，如果Google確實有別有用心，并且想迫使所有項目都使用ViewModel，那么他們還需要棄用onSaveInstanceState（Bundle）。 我知道這聽起來很瘋狂，但這實際上是件好事，因為如果這種瘋狂的預測成真，您就會知道基礎理論是正確的。

但是，鑒于Android的內(nèi)存管理機制，Google不能僅在不提供可靠替代方案的情況下就棄用onSaveInstanceState（Bundle）。 “幸運”的是，這些變化已經(jīng)應用在ViewModel的保存狀態(tài)模塊上了。

我想在一兩年內(nèi)我們就會知道這種做法是否有任何優(yōu)點。‘

總而言之，正如我在本節(jié)開頭所說的那樣，自ViewModel發(fā)布以來，Android中的Configuration Changes就成了屎。兩年多以前，當我撰寫題為“Android ViewModel Architecture Component Considered Harmful”(https://www.techyourchance.com/android-viewmodel-architecture-component-harmful)的文章時，我預測ViewModels將是一種浪費。我的所有預測都是真實的，但不幸的是，事實證明真相比這還糟。

Concurrency

在并發(fā)這方面，最大的變化就是AsyncTask的棄用。我已經(jīng)寫了一篇有關(guān)此主題的非常詳細的文章(https://www.techyourchance.com/asynctask-deprecated)，并提出了具體建議，因此在此不再贅述。

接下來我說的話可能會使部分讀者感到不滿。拜托，別太把這事當真。

Android開發(fā)中另一個流行的多線程框架RxJava很快就會成為“過去式”。 從下面這幅StackOverflow趨勢圖可以明顯看出：

許多開發(fā)者會質(zhì)疑我的觀點，稱該數(shù)據(jù)不具有代表性，并且還有其他方法的可以解釋該圖。他們可能是正確的，因為我自己也不是數(shù)據(jù)科學家。但是，在此圖中，我看不到任何其他關(guān)于峰值的解釋，而且RxJava的曲線與AsyncTask的曲線具有相同的斜率。

因此，如果您尚未花時間在學習RxJava上并且您的項目沒有使用它，那么我建議您避免使用它。實際上，這一直是我的建議，今天它也得到了數(shù)據(jù)的支持。

如果您的項目已經(jīng)使用了Rx，也請不要驚慌，您無需立即重構(gòu)任何東西。但是，請記住，今后找到具有Rx經(jīng)驗的開發(fā)人員將越來越困難。 因此，在項目中廣泛使用Rx可能需要新的開發(fā)人員投入更多的時間。最終，廣泛使用Rx的項目將被視為“not cool”（例如今天使用AsyncTask和Loaders的項目）。

我知道我的這些觀點對于許多開發(fā)人員來說很不友好。他們花了數(shù)周時間來學習RxJava，甚至說服了同事在項目中使用RxJava，現(xiàn)在我卻說它會成為“過去式”。我只想說我只是分析實際情況并根據(jù)我所看到的做出預測，我可能是錯的，也可能是對的。

在Kotlin語言中，我們可以使用協(xié)程。我最近使用協(xié)程實現(xiàn)了一些復雜的用例(https://www.techyourchance.com/kotlin-coroutines-in-complex-scenarios)，發(fā)現(xiàn)此框架非常的細微和復雜，并且相對不成熟，我甚至發(fā)現(xiàn)了一個bug。

有一種流行的說法是，協(xié)程使得并發(fā)處理更簡單。我從來不這樣認為，因為我知道并發(fā)是非常復雜的，但是在我有了一些實踐經(jīng)驗之后，我可以自信地說，協(xié)程并沒有想像中的那么美好。在我看來，協(xié)程實際上增加了程序復雜性，所以我建議你們小心地使用它們。

另一方面，協(xié)程似乎將成為Kotlin語言里處理并發(fā)操作的默認方式。因此，我認為如果您編寫Kotlin代碼，您需要投入時間并學會使用它們。

據(jù)我所知，目前還有一個流式框架，它在協(xié)程之上添加了流處理操作符。幾個月前才穩(wěn)定下來，所以我現(xiàn)在還不能說什么。

Kotlin

現(xiàn)在讓我們來討論一下Kotlin。根據(jù)以往的經(jīng)驗，我知道這是一個非常敏感的話題，而且不管我描述的多么客觀，最終都會遭受一些開發(fā)者的攻擊。然而，我認為在總結(jié)原生Android開發(fā)現(xiàn)狀的時候跳過Kotlin是極不誠實的。因此，我再次請你不要把我說的話當真。

你所需要知道的一個重要的事實是：在Android開發(fā)中使用Kotlin會嚴重增加你的構(gòu)建時間。

在這篇文章(https://eng.uber.com/measuring-kotlin-build-performance)中，您會了解到我在使用Kotlin進行開發(fā)時對構(gòu)建時間所進行的統(tǒng)計測試的結(jié)果。clean build 增加了18%的構(gòu)建時間，incremental build 增加了8%的構(gòu)建時間。

Uber與JetBrains也聯(lián)合發(fā)表了他們自己的研究結(jié)果，他們的結(jié)果更為負面。如果您不在應用程序中使用注解處理器，那么引入Kotlin可能會使您的構(gòu)建時間增加四倍！如果您使用了注解處理器，那么引入Kotlin會使您的構(gòu)建時間增加50%-100%。

Uber的研究結(jié)果與將OkHttp遷移到Kotlin版本后構(gòu)建時間增加了4倍的結(jié)果是一致的。

如果您對這些數(shù)字感到驚訝，您不用擔心-這不是您的錯，而且您并不孤單。盡管這個事實極為重要，但它并未得到廣泛討論，并且我覺得Google也試圖回避這個事實。我曾與Google內(nèi)部一個熟悉此事的開發(fā)人員有過一次非常有趣的討論，我問他是否可以討論下這個話題，他說：“我不喜歡；我不喜歡；我不喜歡。這是一件很微妙的事情。”

[[313477]]

除了增加構(gòu)建時間之外，Kotlin還不支持增量注解處理，而在大約10個月前Java就已經(jīng)支持增量注解處理了。

兩年前，我寫了一篇文章(https://www.techyourchance.com/kotlin-vs-java-whole-story)來警告開發(fā)者們在早期使用Kotlin時可能會遇到的潛在風險。在很長一段時間內(nèi)我被稱為“kotlin的討厭者”。

但是，如果您今天閱讀這篇文章，您會發(fā)現(xiàn)我實際上低估了這些問題的嚴重性。在大型的Android項目上，構(gòu)建時間是最糟糕的生產(chǎn)力殺手之一，而且即使在今天，即Kotlin被官方“正式采用”兩年多之后的今天，Kotlin仍然不如Java。不管Kotlin帶來什么其他好處，所有這些都可能由于更長的構(gòu)建時間而被否定。

也就是說，我們不應改忽視這樣一個事實：是谷歌將android開發(fā)的生態(tài)強行推向了kotlin，使得其使用率在穩(wěn)步上升。

就我個人而言，我并沒有在我目前已經(jīng)開始的新項目中選擇kotlin語言，我不想在kotlin上浪費我自己的時間。不過，從現(xiàn)在開始，我會認真考慮使用kotlin來開發(fā)新項目，我已經(jīng)在幾個demo上嘗試過了。但是我不同意開發(fā)人員說你必須在新項目中使用Kotlin，這仍然是一種權(quán)衡。

至于你們是否應該將現(xiàn)有項目遷移到Kotlin，我無法提供任何一般性建議，您需要根據(jù)具體的情況進行仔細的分析。但是，如果您確實決定開始（或已經(jīng)開始）遷移，那么這個帖子可能會對您有用。

Summary

在過去的兩年中，我開發(fā)了三個新的應用程序。我認真研究了現(xiàn)有的項目并分析了早期技術(shù)決策所帶來的長期影響。我寫了一些博客，提供有關(guān)Android開發(fā)的高級課程。我花了很多時間在互聯(lián)網(wǎng)上討論Android開發(fā)相關(guān)主題。

盡管如此，我還是感覺自己無法跟上Android生態(tài)系統(tǒng)的變化。

如果是這樣的話，對于那些缺乏經(jīng)驗、需要指導的Android開發(fā)人員，我深表歉意，而且我至今無法想象從頭開始學習Android開發(fā)的感覺。當您對框架和工具感到滿意的時候，其中許多將已過時或即將過時。加入這個原本很棒的社區(qū)可能是最糟糕的時刻。Google為他們的“包容性”感到非常自豪，但看起來它不適用于經(jīng)驗不足的開發(fā)新手。

我個人認為Google對Android框架所做的更改會導致巨大的人類潛力浪費。閱讀所有這些更改需要花費數(shù)小時，更不用說實際實施它們了。我寧愿花更多的時間來創(chuàng)造價值，而不是追逐自己的尾巴。

在這篇文章中，我試圖總結(jié)有關(guān)Android原生開發(fā)現(xiàn)狀的一些重要的內(nèi)容，我還對未來做了一些預測。這篇文章并不完美：它可能包含一些錯誤，而且還錯過了一些其他重要內(nèi)容。請隨時在下面的評論中糾正我。但是請記住，本文沒有任何私人內(nèi)容。我知道我提出了一些非常有爭議的觀點，但是我相信這是對的。

我還在本文的多個地方引用了我之前寫的一些文章。我這樣做并不是為了炫耀并說“看，我是正確的！”，而是讓您能夠了解我過去的預測并將其與實際發(fā)生的情況進行比較。當我寫這些文章時，他們讀起來就像您今天讀本篇文章一樣瘋狂。但是我所做的預測卻非常準確。

當然，我也想說：“看，我是對的！”。我冒著巨大的專業(yè)風險發(fā)表了這些有爭議的預測，在得知自己沒有誤導讀者后我感到非常的欣慰。即使有時候我寧愿自己是錯的，也希望Google成為真正的合作伙伴。但是到目前為止，情況并非如此。

最后附上文章作者對于跨平臺開發(fā)的一些看法，僅供參考。

• 學不動也要學！深入了解ViewPager2

• Effective Java in Kotlin:2. 遇到多個構(gòu)造器參數(shù)時，考慮用構(gòu)建者

• 誰天生就是干程序員的料？

大家覺得哪個趨勢更先普及呢？