沒用的前言
其實自從 Jetpack Compose 面世以來，關於 Flutter 與 Compose 之間的選擇問題就開始在 Android 開發中出現，就如同之前有 iOSer 糾結在 Flutter 和 SwiftUI 之間選誰一樣，對於 Android 開發來說似乎“更頭痛”的是 Flutter 與 Compose “同出一爹”。
本來關於這個話題沒什麼好寫的，因為這個話題屬於“吃力不討好”的型別 ，畢竟被原生開發看到了，可能就有人就要痛批我：
“是我 Andorid 提不動刀了，還是這些一兩年的’小框架‘飄了，搞不好我們再等等它們就都涼了，你整天就知道’販賣焦慮’收割流量。”
但是看你們討論得熱火朝天，加之時不時要回答類似的問題，實在憋不住了，所以最終還是選擇“冒死”輸出一波，從我的觀點來介紹它們之間的關係和如何選擇。
當然，有人說我都不選不行嗎？當然可以，因為在目前階段 Flutter 和 Compose 都不影響你的 Android 開發地位，它們最多隻是屬於競爭工具。
Flutter 和 Compose 初衷
Flutter 和 Compose 的未來目標會比較一致，但是至少它們出現的初衷是不一樣。
首先 Compose 是 Jetpack 系列的全新 UI 庫，理解下這點！Compose 是 Jetpack 系列的成員之一，所以可以被應用到 Android 介面開發中，所以你也可以選擇不用，用不用都能開發 Android 的 UI 。
然後再說 Compose 出生的目的：就是為了重新定義 Android 上 UI 的編寫方式，為了提高 Android 原生的 UI 開發效率，讓 Android 的 UI 開發方式能跟上時代的步伐。
不管你喜不喜歡，宣告式的介面開發就是如今的潮流，不管是 React 、SwiftUI 、Flutter 等都在表明這一點。
而對於 Flutter 而言就是跨平臺，因為 Flutter 沒有自己的平臺 ，有人說 Fuchsia 會是 Flutter 的家，但那已經屬於後話，畢竟 Fuchsia 要先能養活自己。
因為 Flutter 出生就是為了跨平臺存在的全新 UI 框架，從底層到上層都是“創新”和“大膽”的設計，就選擇 Dart 本身就是一項很“大膽”的決定，甚至在 Web 平臺都敢支援選用 Canvaskit 的 WebAssembly 模式。
所以 Flutter 的“任性”從一出來就不被看好，當然至今也有不看好它的人，因為它某種程度很“偏激”和不友好。
所以扯了那麼多，總結下就是：
-
Compose 是 Android UI 的未來，現階段你可以不會，但是如果未來你會繼續在 Android 平臺的話，你就必須會。
-
Flutter 的未來在於多平臺，更穩定可靠的多平臺 UI 框架。如果你的路線方向不是大前端或者多端開發者，那你不需要會。
對了，鴻蒙上也是有類似 Flutter 的實現，感興趣的可以自己關注下。
Compose 和 Flutter 未來一致
雖然 Compose 和 Flutter 初始服務的物件並不一致，但是它們未來目標肯定是一致。
為什麼這麼說？《Jetpack Compose for Desktop: 里程碑1釋出》 不就表明了這一態度麼？ Compose 雖然只是作為 Jetpack 的一個 UI 子集，但是它設計的理念和架構本身就帶有跨平臺支援的潛力。
本質是 Compose 也是類似於一個編譯器加上一個 Skia 的工作模式，這和 Flutter 沒有什麼區別，不說開發方式，僅從控制元件命名上 Flutter 和 Compose 就不會讓你感覺陌生。
不說控制元件，就說這次 Flutter 2.0 更新中 Dart 1.12 的 null-safety 和 Kotlin 像不像？
所以迴歸到主題的另外一個問題， Flutter 和 Compose 衝突嗎？
從立項的意義上看 Flutter 和 Compose 好像是衝突的，但是從使用者的角度看，它們並不衝突。
因為對於開發者而言，不管你是先學會 Compose 還是先學會 Flutter，對於你掌握另外一項技能都有幫助，相當於學會一種就等於學會另一種的 70%
從未來的角度看：
-
如果你是原生開發，還沒接觸過 Flutter ， 那先去學 Compose ，這對你的 Android 生涯更有幫助，然後再學 Flutter 也不難。
-
如果你已經在使用或者學習 Flutter ，那麼請繼續深造，不必因為擔心 Compose 而停滯不前，當你掌握了 Flutter 後其實離 Compose 也不遠了。
它們二者的未來都會是多平臺，而我認為的衝突主要是在於動手學起來，而不是在二者之間徘徊糾結。
從現實角度出發：目前 Flutter 2.0 下的 Android 和 iOS 已經趨向穩定，Web 已經進入 Stable 分支，而 Macos/Linux/Win 也進入了 Beta 階段，並且可以在 Stable 分支通過 snapshot 預覽。所以從這個階段考慮，如果你需要跨平臺開發，甚至 PC 平臺，那麼優先考慮 Flutter 吧。
你選擇 React Native 也沒問題，說起來最近 React Native 的版本號已經到了 0.64 了?
當然大家可能會關心框架是否有坑的問題，本質上所有框架都有坑，甚至網路因素都可能會成為你的痛點，問題在於你是否接受這些坑。
跨平臺的背後本身就是“髒活”和“累活”， Flutter 的全平臺之路很艱難，就像之前寫的《解讀 Flutter 全平臺開發的誤解與偏見》， 現階段 Flutter 全平臺更多隻是噱頭，只是提供了“多一種可能”的階段。
最後還是要例行補充這一點：
跨平臺之所以是跨平臺，首先就是要有對應原生平臺的存在， 很多原生平臺的問題都需要回歸到平臺去解決，那些喜歡吹 xxx 制霸原生要涼的節奏，僅僅是因為“你的焦慮會成為它們的利潤”。
聊點廢話
說點“道理我都懂”的實話，本質是我們作為開發者，其實並不應該把自己歸納為於某種語言和特定的框架之下，我們現在被歸納在某個領域僅僅是因為工作需要，而對於未來我們的發展，其實更應該注重的是程式設計基礎和動手能力。
我本身是通過 Weex 接觸的 Vue ，也用過 uni-app 做個簡單的小程式，用 React Native 開發過兩端 App ，也用 Flutter 寫過 Web ，甚至手賤地在 SpringBoot 上用 Kotlin 寫 API。
所以在我眼中，現在客戶端和前端之間的劃分已經越來越模糊，我遇到不少 Android 開發寫過小程式或者 Vue ，不少前端也通過 uni-app， RN 和 Flutter 在寫 App ，這是很正常的趨勢，因為平臺成熟了，越成熟的平臺就會開始和相近的領域融合貫通。
你想說“卷”也行，這種趨勢會讓一些簡單、重複或者需要共享的內容通過跨平臺來得到落地，我相信有的人不看好跨平臺，但是它存在的場景確實有它關鍵的價值。
也許某些領域我的認識不是很深，但是在需要的時候我可以動手滿足需求，甚至去深入探索一下，而我也有自己精通的領域，二次並不衝突。
當然你說我只想在某個平臺深入研究有沒有問題？那肯定沒有問題，這是好事，因為精通某個領域本來就是非常好的一件事。
但是！對，我還是要說這個但是，因為很多時候精通某項技術，是需要業務場景去驗證和推進的，如果不是大體量的業務場景，沒有經歷過各種極端的考驗，很多時候所謂的精通只是表層精通。
為什麼說這個？因為在交流過程中經常有一些人說：想要深入xxx去精通某項技術或者領域，但是最終還是“三過門而不入”。
最後的最後，我想說學習其實本身是一件長期投資的事情，我們追求“價效比”和“高回報”很正常，但是這和投資金融一樣，如果一直想要通過“投機”來獲利，那就要有做好韭菜的準備。