干了十年 Android 開發，為什么我再也不想繼續了

發布時間：2023-07-02 23:42:02 作者：網友整理

本文最初發布于 Level Up Coding 博客。

在這篇文章中，我將談談為什么我在這個行業工作了近十年之后，永遠地離開了 Android 開發。在開始之前，讓我簡單介紹下自己在這個領域的職業生涯。

美好時光

我從 2013 年開始接觸 Android 開發，在當時 Android 4.4 還是熱門的新事物。AsyncTasks 還是標準，還有 OttoEventBus 和其他令人討厭的東西。我見證了架構演進的過程，從 MVC 到 MVP/MVI，然后轉向 MVVM，最后是 MVVM 和 MVI 的混合。

我記得，當 RxJAVA 出現時，一切都突然變成了反應性的，變成了流。我記得，l33t Android Devs（Hi Jake Wharton）在談論那個新出現的黑馬 Kotlin。我記得，Kotlin 興起并接管了 Android 行業。我記得，Coroutines 出現了，并且起初被認為是“RxJava”的殺手（嘿，你現在可以用同步方式編寫所有異步代碼了！不需要流了！）。這個理念很吸引人，但很快就被證明，那僅僅是一個好主意而已，因此，像 Channels 這樣的底層異步原語成為 Kotlin 的 Rx-Way。不過事實證明，很多使用 Channels 的人都是自斷雙臂。不得已，精益冷流（Cold Streams）和熱流（Hot Streams）的概念被重新引入，請允許我向你介紹：StateFlows 和 SharedFlows，最后，我們得到了一個輕量級的、支持 Coroutines 的 Kotlin 版 RxJava2。

我記得，我和同事 David 圍繞狀態和事件展開的所有有趣的對話，到底什么是狀態，什么是事件？事件對狀態有什么作用，反之亦然？我記得，在 Dagger 2 被 Koin 和 Dagger Hilt 取代之前的幾年，我熬夜學習 Dagger 2。我還記得，第一次閱讀 Uncle Bob 的《架構整潔之道》，這是我在 Android 開發生涯中最開闊眼界的時刻之一。現在，我能夠設計和編寫幾乎所有應用程序，而不需要考慮 MVVM/MVP/MVC 或任何其他特定于平臺的細節。我知道為什么測試很重要，我嘗試了 TDD，對它是又愛又恨，我還學習了 DDD 和 BDD。

我的火車到達終點站了嗎？

（我選擇這個副標題是因為我現在正在從瑞士到德國的火車上寫這篇文章。）

后來，我加入了保時捷和 IBM 等大企業的領導團隊，這是一段很好的旅程，經過 6-7 年的經驗積累，我達到了目標。我曾開發過復雜的應用程序，涉及大量的 E2E 加密、傳感器通信、NFC 芯片、BLE Beacon、高流量聊天應用，還有非常有名的待辦事項應用，等等。

大約 6 年后，我開始以首席 Android 開發人員的身份參與項目。我學會了識別所參與的大多數項目的核心技術問題（架構和團隊成員對某些模式有不同的理解），我還學會了如何指導團隊解決這些問題，以及如何成功地完成項目。對我而言，現在新東西僅僅是學習新的 API 變化 / 框架，目的是解決我們已經解決了很多年的問題，只是新的框架 /API 做了更好的處理（不用再手動處理生命周期、Fragment Transaction、XML 布局等）。

我以前的后端經驗

很幸運，在過去的 4-5 年里，我在客戶項目中從事后端工作（根據要求）。我花了很多時間去了解后端開發的來龍去脈，編寫并發代碼，創建分布式系統，縱向和橫向擴展，處理分布式事務，編寫可配置的代碼，在不同階段的環境表現出預期的效果。我研究了不同類型的數據庫（圖、關系、文檔），以及什么樣的數據應該使用什么樣的數據庫，我學習了 Docker 和 K8s，我用 Go 重構 Java EE 系統。看著由 Go 編譯出來的二進制文件，它的內存使用率和幾乎為零的內存占用，我明白了為什么 Go 如此令人驚嘆。作為后端開發人員，我所解決的問題與我在 Android 開發中遇到的挑戰無法相提并論（我很快就會講到），作為后端開發者，我所解決的問題比在 Android 上推敲像素影響更大、更深遠。

Android 真的就那樣嗎？

最終，我厭倦了與 UI/UX 設計師的所有會議，厭倦了向他們解釋 Material Design 的基本原理，或者為什么我們不能觸發應用程序 Y（不是我們開發的）中那樣的行為 X，我記得，好幾個小時的設計討論都讓我的大腦直接宕機了。不少項目都會出現這種情況，其中一些項目具有一定的復雜性，一旦團隊理解了整潔架構和領域驅動開發，我們就能在很短的時間內寫出領域 + 數據層。一旦你向團隊解釋清楚了各種身份認證流程，恰當處理令牌刷新邏輯就變成小菜一碟了。主要的挑戰幾乎總是出現在 UI 層，由于框架 API 不斷發展變化，UI 層也在不斷變化。在很大程度上，UI 層受 UI/UX 設計師和 PO 影響。最近，幾乎所有的項目都變成了日常工作，對工程的關注少，對業務、實施的關注多，幾乎一直在擺弄 Android API。在最好的情況下，會有一個令人耳目一新的任務，如編寫一個自定義視圖，并使用一些線性代數的知識。但通常情況下，幾乎總是一些無聊的事情，反思這一切，我問自己：這對我有什么好處？當然我賺了很多錢，但我馬上就要 30 歲了，幾年后，我將在哪里？

作為一名經驗豐富的 Android 開發人員，我只適合 Android 職位。我所有的技能都是為了能開發出可維護的、整潔的、能在 Android 平臺上正常工作的代碼。有些代碼會被垃圾收集器如期殺死，而有些代碼能在垃圾收集器中存活下來，因為它本該如此。如果 Android 很快消失了怎么辦？看著像 Flutter 這樣優秀的技術，人們已經用它開發出了一些很棒的應用，我不會再把任何新項目作為單獨的原生 IOS 和原生 Android 應用來啟動。老實說，你的 Android 技能對于大多數公司的首席 / 資深軟件工程師職位來說價值并不高。

Android 開發日薄西山

我成功地完成了自己的最后一個項目。現在是時候做一些改變了。我不想再花幾天的時間討論 CardView 的邊框或反復出現的毫無意義的問題，比如是使用單選按鈕還是復選框。我不想再為了更好地處理 Android 生命周期或導航而學習新的 Android 庫，然后在未來 12 個多月內看它們再次被替換，在過去的 10 年里，這種事我已經做過好多次了。開發人員一代接一代，每一代中都會有人覺得自己有權力編寫一個新的庫來處理 UI 狀態，或者編寫一個新的導航庫。測試？不，沒有。可悲的是，有很多開發者會使用這些庫。Android 開發正慢慢被吞噬 Web 開發的混亂所吞噬（你試過安裝 create-react-App 嗎？你會下載數以千計的庫，包括一些易受攻擊的庫）。

幸運的是，在過去幾年里，我曾在幾個項目中從事后端工作，這使我有機會過渡到后端開發，徹底離開安卓，專注于開發每秒處理數十萬用戶請求的系統，這對我來說非常有吸引力。現在，路線圖上有一些我作為 Android 開發者不了解的新東西：獲得 K8s 認證，掌握多個云，深入學習特定數據庫，深入理解 DevOps。我感覺，編程的神秘性再次激發了我，有復雜的工程問題需要處理，這讓人興奮。

讓人難過的是，對于一個純粹的 Android 開發者來說，架構師或首席 / 資深工程師的道路是封閉的。純粹的 Android 開發人員根本不具備履行這些職位所需的技能。對我來說，這是一次很棒的旅程，但我再也不會以 Android 開發人員的身份參與項目了。