當我還在上大學的時候，Android和iOS還是新興的平臺，每個人都對這兩項技術很感興趣。如果你參加一些當時的編程研討會，最後總會寫一個小型的Android應用。這就是我向Android生態系統邁出的第一步，也可能是我隨後成爲了一名移動開發者的原因。
在這篇文章中，我想要分享我關於Android SDK和Flutter的糟糕體驗。我提到的某些要點也適用於iOS SDK。我已經在幾年前放棄了移動開發的工作，希望後來許多事情已經在朝好的方向改進。但在當時，我發現移動生態系統是如此的令人感到困惑和挫敗，以至於我選擇了一條不同的職業路徑。
本文由原作者發表在medium.com，經原作者授權由InfoQ中文站翻譯並分享
設備的碎片化
對開發者而言，Android開發的最大痛點，就是設備配置的巨大差異。我一直都未能理解爲什麼SDK中大部分功能（尤其是用戶交互界面的部分）取決於設備，而不是我的應用。這從根本上導致我必須使用支持庫，針對每個目標API級別調試我的應用。除此之外，我還經常遇到在仿真器或者測試設備上好好的代碼，卻在某個三星或者華爲的設備上崩潰的情況。
質感設計（Material Design）
當我在HackerNews或者Reddit上讀到關於谷歌的Material Design的評論時，某些時刻會感到我是唯一真正喜歡它的人。我覺得它在視覺上很具吸引力，我通常很享受這樣的用戶體驗。官方的文檔網站發展得很快，也非常成功，我覺得這是優秀文檔的典範。當它被宣佈用於Android時，我感到非常興奮！
話雖如此，在Android平臺上從Holo過渡到Material Design並非一帆風順。因爲它好像是被急匆匆發佈出來似的。在接下來的幾年之中，官方的Material Design支持庫一直缺少一些非常基本的組件。雖然你有時可以在谷歌自有的應用上看到這些組件，但是它們並沒有真正被納入到支持庫中。開發者不得不構建自己的組件，或者使用GitHub上質量無法保證的實現作爲替代品。這次使用Material Design支持庫的經歷，再加上大量的不一致的視覺設計和實現錯誤，讓我第一次停下來真正地思考和質疑這個生態系統。
無人理會的最佳實踐
構建一個可靠的Android應用，是一項充滿挑戰的任務。這主要是因爲SDK對開發者並不友好。理論上，一個Android應用程序可以永遠掛在後臺不使用任何系統資源，然後在用戶需要時立即回到先前的狀態，這實在是令人驚訝。不過前提是開發者正確地實現了這個應用的狀態和生命週期管理機制。
開發者：你好，互聯網！我的應用在改變屏幕方向時崩潰了，該如何解決？
互聯網：這很簡單！禁止改變屏幕方向即可。
——啊哦，不幸的是，這種回覆很普遍。
你是否曾經使用過Java中的線程（Threads）？在可變變量隨處可見的的命令式代碼庫中，這件事變得非常困難。但你猜怎麼着？在Android SDK中使用線程更加困難。如果你想要在一個Activity中管理Thread，那你就只能自求多福了。幸運的是，我們最終保留了Fragments，這最終讓這件事變得容易了一些。但代價是在一開始就需要使用Fragments。
在我作爲一名移動開發者的職業生涯中，我面試了一些高級Android開發者。他們幾乎無一例外，都很難給出這些話題的正確答案。
我一直希望谷歌能更坦然地承認這些問題，並且和社區一起解決。這些問題可能隨着Kotlin的發佈有所改善，但Android生態系統的根基仍然存在很多潛在的問題。
無效的設計模式和對抽象的註解（Annotation）
開發者很快就意識到，在Android SDK提供的抽象之上，構建一個真實世界的應用是不可能的。對此的解決方案是層出不窮的設計模式，甚至每週可能都會出現新的設計模式，我記得的包括：MVC、MVP、MVVM和MVI。而且由於無法使用普通的構造函數調用來管理依賴項，我們不得不在代碼庫的每個地方使用註解。這些本來並沒有必要。Java，甚至Kotlin，本來就有足夠的能力可以對這些東西建模，更何況是以一種透明而直接的方式。但Android更喜歡XML定義和反射式實例化，因此開發者不得不在代碼中使用註解和各種設計模式。實話實說，我真的無法形容這到底有多麻煩。
從未利用過的平臺優勢
在某種程度上，原生iOS和Android開發都是作爲平臺在與網頁端競爭。但iOS和Android擁有隻屬於一家企業的巨大的平臺優勢，相比之下，網頁端有許多利益相關者，這些利益相關者都想要根據他們的需要來影響網頁端的開發。
然而，網頁端擁有更加活躍和創新的生態系統。只需要想想React的成功故事：基於組件的用戶界面，是我們目前提出的最簡潔的抽象方法，這是無可否認的。多年以來，Android並不理會這一趨勢，直到最近才宣佈推出“Jetpack Compose”，但是這仍然僅支持在開發者預覽模式下使用。同樣的事情也出現在iOS開發中。
所以，現狀是我們仍然需要繼承android.view.View類，這個類有1.5萬行代碼，和數十個生命週期函數，但同時我們還要嘗試注入自己的merge XML文件。iOS和Android本來可以成爲這個競爭中的引領者，但實際上，它們已經被遠遠甩在了後面。
請不要對UI開發抱以希望
一個精美的應用的關鍵在於用戶界面（UI）。我在上文已經吐槽了不少關於組件的問題，但這些還不是最嚴重的。你是否曾經調試過網站上的故障？通常的操作是：打開瀏覽器的開發工具，點擊有問題的元素，然後使用CSS和HTML的屬性來調試。與此相比，Android是一個無法訪問的黑盒。老實說，我一直沒有完全理解Android的主題和樣式機制，並且與Web相比，Android的工具顯得毫無用處。
想要在這個框周圍添加陰影嗎？沒問題，請使用這個奇怪的.9.png文件，或者依靠API Level 21，你就可以正確渲染陰影了（儘管只有凸形陰影）。
不好意思，你忘記實現自定義視圖四個構造函數的其中一個了。但我不會拋出編譯錯誤，我只會在運行時崩潰！
現在有支持超高屏幕密度的手機了。可以在應用裏添加 xxxhpi的assets嗎？不行，不支持矢量圖，我們做不了這個。
——來自Android SDK的深夜獨白
矢量圖
在Android 21（5.0）之前，Android平臺根本不支持正確的矢量圖。這背後的原因是，多樣的Android設備導致了多種不同的屏幕密度，這要求圖像針對每種屏幕密度都做仔細的調整。務實的開發者自然而然地開發了轉換矢量圖的工具，將logo.svg轉換成ldpi/logo.png，mdpi/logo.png，hdpi/logo.png，xhdpi/logo.png，xxhdpi/logo.png以及xxxhdpi/logo.png。幸運的是，最終谷歌改變了它們的想法，並提供了VectorDrawble來支持部分可縮放矢量圖形（SVG）。的確，這足夠減輕當時的痛苦。但仍然令我困惑的是，一個以能夠在任何設備配置上運行爲優勢的開發環境，是如何在這麼長時間都不支持矢量圖的情況下活下來的？
死局
這些年，我開始越來越擔心我的知識會在不遠的將來過時。我學到的大多數知識都是Android開發所特有的，很少適用於更廣泛的軟件開發領域。考慮到這些方面，我不認爲原生的移動開發會一直存在，所以我開始擔心所學到的技能的實用性。
Flutter
當Flutter發佈時，我非常激動。它承諾將解決一些主要的Android SDK的缺陷，同時無償提供跨平臺支持。所以在我上一份工作中，我們開始從原生Android遷移到Flutter上。我必須承認，Flutter信守了它的承諾：
- Flutter內置的渲染流水線完全解決了Android的碎片化問題。
- 從一開始，它就提供了詳盡的高質量的Material Design組件庫。
- 熱重載功能的靈活性完全顛覆了我的認知。
- 你能獲得前所未有的高質量界面外觀的跨平臺體驗。
但不幸的是，它也不完美。而且有點可惜的是，Flutter遇到的問題本可以通過一個全新的項目輕鬆避免。
- Dart很糟糕：它還是一門相對年輕的語言，但它重蹈了不少它的前輩的覆轍（錯誤的類型系統，Null，使用語句而不是表達式，等等）。
- Flutter SDK中讓人不解的設計決策：它們本應創造一個更好的React，但卻創造了一個更糟糕的。本可以通過簡單的函數調用解決的問題，往往需要通過有狀態的面向對象編程（OOP）機制才能解決。（我記得對話框的路由和處理在這個方面尤爲痛苦）
結論
在某一時刻，我清楚的意識到，我不想在這種技術上傾注心血了。我向自己許諾，絕不再在移動平臺上編程。一個設計精美的、響應式的網站在今天已經可以給你足夠好的體驗，所以這是我的不二之選。只需要一個代碼庫，它就能適用於每個客戶端。如果我還是不得不構建一個移動應用程序，我仍然會選擇Flutter，甚至是在我僅針對Android的情況下。我絕對不會再使用Android SDK。
話雖如此，但要澄清一點，我還是非常喜愛和欣賞精心製作的原生應用的（無論是在移動設備上還是桌面上）。我對那些使用現有工具就能創建出這樣的應用的開發者，致以崇高的敬意。只是，我不想再成爲他們中的一員。
原文鏈接：