本文原作者: 戀貓de小郭，原文發(fā)布于: GSYTech

又到了喜聞樂見的環(huán)節(jié)，「本篇主要是科普 KMM、Compose 和 Flutter 的最新現(xiàn)狀」，對于 Compose 和 Flutter 大家可能并不陌生，但是對于 KMM 也許會存在疑惑，KMM 全稱 Kotlin Multiplatform Mobile，顧名思義它是用 Kotlin 實現(xiàn)的跨平臺框架，那為什么今天突然會聊到它？

起因如下圖所示，最近有人提及了 KMM，并且用了 "變天" 的詞匯，頓時就勾起了我的興趣，因為 KMM 這些年來一直 "不溫不火"，可以說很多使用 Kotlin 開發(fā)的 "Androider" 對它都很陌生，難道最近它又有了什么突破性的進展？

而在求證一番之后，原來起因來自 10 月初「Android 官方宣布Jetpack 開始要支持 KMM」了，目前Collections和DataStore已經(jīng)可以通過依賴-dev01版本在多平臺上使用，同時「KMM 進入 Beta 版本階段」。 「所以目前 KMM 變不了天，至少它還處于 Beta 階段，但是 Jetpack 開始支持 KMM 是個很好的消息，這意味著 KMM 的社區(qū)支持有了官方保證」。

好了，介紹完起因，接下來開始進入今天的主題，什么是 KMM、Compose 和 Flutter。

KMM

Kotlin Multiplatform Mobile – KMM 是基于 Kotlin 并應用在 iOS 和 Android 的一種跨平臺技術(shù)，它的特點是結(jié)合了跨平臺和原生開發(fā)協(xié)同開發(fā)的模式，如下圖所示，簡單的理解就是:「從純原生開發(fā)變成了 KMM + 原生 UI 開發(fā)」。

「使用 KMM 可以把您的業(yè)務邏輯和基建部分的能力跨平臺化」，例如網(wǎng)絡請求、數(shù)據(jù)存儲，狀態(tài)上報等模塊通過 KMM 實現(xiàn) Android 和 iOS 通用，例如前面介紹的 DataStore 就可以在 iOS 上支持使用。

在官方的介紹里 KMM 的早期使用者有百度、Netflix、VMWare、Philips 等，目前收到的反饋都挺不錯，而 Beta 版本也意味著現(xiàn)在 KMM 已經(jīng)具備了使用的基礎(chǔ)。

那您可能會好奇，KMM 支持 Web 嗎？

聊到這個話題就很有趣，從我的角度上看，我會說 Kotlin Multiplatform 支持，但是 KMM 不支持。 如果您安裝過 KMM 插件和創(chuàng)建過 KMM 項目，您會看到 KMM 不管是從 logo 還是項目創(chuàng)建都只有 Android 和 iOS，但是，Kotlin Multiplatform 是支持 Web 的，通過 Kotlin JS。

如果接觸 Kotlin Multiplatform 比較早，那您可能還聽說過 KMP，KN 之類的縮寫，那它們和 KMM 又是什么關(guān)系？簡單來說:

• KMP 一般指的就是 Kotlin Multiplatform，我依稀記得 KMP 這個概念是在 Kotlin 1.2 的時候被提出，可以將 Kotlin 運行到特定平臺的 JVM 和 JS 代碼上
• KN 一般指的是 Kotlin Native，KN 屬于是將 Kotlin 編譯為 Native 二進制文件的技術(shù)，甚至可以在沒有虛擬機的情況下運行，例如 KMM 上的 iOS 就是使用了 KN 的能力
• KMM 是利用了 JVM 和 KN 能力實現(xiàn)的針對 Android 和 iOS 平臺的 Kotlin 框架: Android (Kotlin/JVM) 和 iOS (Kotlin/Native)

另外還有 Kotlin JS 用于 Web 平臺，「所以 KMP 可以看作是大集合，而 KMM 是其中針對 Android 和 iOS 的支持，另外通過 Kotlin Native 和 Kotlin JS 也可以支持拓展到 PC 端和 Web 端」。

那么到這里您應該理解:「KMM 主要是用來寫跨平臺邏輯，涉及到 UI 部分您還是需要通過原生實現(xiàn)」，如果您從另外一個角度看，用 KMM 對于 Android 開發(fā)來說幾乎等于白送的能力，因為它只需要 Kotlin。

至少 Compose 您還需要適應下響應式開發(fā)模式。

那或者有人就問:那 KMM 的意義何在？ 事實上還真有，「KMM 在 App 的基建上會很實用，比如做數(shù)據(jù)上報，崩潰統(tǒng)計，數(shù)據(jù)分析等等」，純邏輯的跨平臺不影響 UI 部分，目前也是在這些場景上 KMM 應用較多。

另外還有人問我，KMM 可以用 Java 開發(fā)嗎？嗯，這是個好問題，下次不要再問了。

當然，KMM 也存在一些局限，比如使用 ViewModel 和協(xié)程如何在 iOS 上運行的問題，不過社區(qū)針對這部分也有一些第三方支持，所以對于 KMM 的未來還是值得期待。

Compose

Compose 相信大家不會陌生，「其實 Compose 也可以分兩部分看待，Jetpack Compose 和 Compose Multiplatform」:

• 由 Android 官方維護的 Jetpack Compose

• 由 JetBrains 維護的compose-jb實現(xiàn)的 Compose Multiplatform

「如果說 KMM 是用于實現(xiàn)跨平臺的業(yè)務邏輯，那么 Compose Multiplatform 就是專注于跨平臺 UI 上的支持」，那 KMM 和 Compose Multiplatform 是什么關(guān)系呢？ 從項目角度看，compose-jb 和 KMM 其實沒有關(guān)系，因為 KMM 還在 beta，但是 Compose Multiplatform 正式發(fā)布已經(jīng)接近一年的時間。

但是要說完全沒關(guān)系顯然是不可能，畢竟 Kotlin Native 和 Kotlin JS 的能力其實在 Compose Multiplatform 里很重要。

當然，如下圖所示，Compose Multiplatform 在跨平臺開發(fā)體驗上還是有所區(qū)別，「Compose 目前是通過多個模塊不同實現(xiàn)來支持多平臺，所以目前 Jetpack Compose 和 Compose Multiplatform 有一些 "割裂"」，特別是在 Web 端，想要達到 Flutter 一樣共享代碼的比例還需要繼續(xù)努力。

?

PS: 圖比較老，iOS 其實目前已經(jīng)進入實驗階段， androidx.compose.ui.main.defaultUIKitMain 相關(guān)的支持距離正式發(fā)布可以期待。

另外 Compose Multiplatform 還有的問題就是缺少插件社區(qū)，這其實是跨平臺領(lǐng)域必不可少的配置:「前端有 npm、Flutter 有 pub，您可以通過它們的中央官網(wǎng)搜索您想要的庫，查看它們的熱度，版本，兼容和使用量等等信息，設置官方認證和安全保障，但是 Maven 時代在這方面一直很弱」。

另一方面 Compose 的優(yōu)勢也很明顯:

• Kotlin 生態(tài)
• Android 開發(fā)友好
• 打包體積增長不大，代碼壓縮比例高
• 性能不錯，compose-android 和 compose-desktop 都使用 Skia

「而隨著 Jetpack 開始支持 KMM，那么 Compose Multiplatform 的社區(qū)支持力度將得到進一步提升，因為變相 Compose Multiplatform 也可以支持 Jetpack」。 至于前面所說的 "割裂" 問題，目前可以看到官方也在有序推進，其中就有 desktop 的部分代碼已經(jīng)挪到了androidx 上，從這里看或者統(tǒng)一的 Compose lib 并不遙遠。

PS: JetBrains 目前就已經(jīng)將 Toolbox 應用通過 Compose Multiplatform 實現(xiàn)并且發(fā)布使用。

Flutter

現(xiàn)在 Flutter 已經(jīng)是 3.3 的版本，F(xiàn)lutter 的特點就是跨平臺，因為它并沒有自己的平臺，同時它也是 single codebase 的跨平臺實現(xiàn)。

?

關(guān)于 Flutter 和其他框架的對比或者使用數(shù)據(jù)就不多贅述，這里介紹一些其他比較有意思的話題。

1. FlutterVSOther量化對比 2. 國內(nèi)大廠應用在移動端Flutter框架使用分析 3. 國內(nèi)大廠在移動端跨平臺的框架接入分析

「在 Jetbrains 的開源項目里有一個叫skiko的項目」，Skiko (Kotlin 的 Skia 的縮寫) 是一個圖形庫，它支持 Kotlin/JVM、Kotlin/JS、Kotlin/Native 等相關(guān)實現(xiàn)，目前支持有:

• Kotlin/JVM - Linux、Windows、macOS、Android
• Kotlin/JS - web
• Kotlin/Native - iOS 、macOS

如果從這個角度看 Compose Multiplatform 未來的方向會和 Flutter 很像，甚至因為 Flutter 走過更多的坑，所以 Compose Multiplatform 在對接 Skia 上可以有更多的參考。

其實未來 Linux、Windows 等平臺也完全可以脫離 JVM 通過 Kotlin/Native + Skiko 實現(xiàn)支持，只是維護成本會變高。

而「Flutter 在自建渲染引擎上其實已經(jīng)越來越激進，因為直接使用 Skia 已經(jīng)無法滿足日益增長的 Bug 和性能極限，所以官方開始了自研渲染引擎 Impeller」。 因為 Flutter 團隊現(xiàn)在出現(xiàn)問題每次都要和 Skia 團隊溝通，然后等跟進，這樣的節(jié)奏太慢了，從官方的更新日志上就可以看出目前 Flutter 的迭代速度依然很夸張。

所以「這次自研的 Impeller 本質(zhì)上是為了解決 Skia 需要運行時遇到的問題，Impeller 可以直接在編譯器就完成 GLSL 和 MSL，不需要 SKSL 從而提高了性能和運行時的穩(wěn)定性」，目前優(yōu)先在 iOS 平臺上開始支持，配合 Metal 做優(yōu)化，后續(xù)如果沒問題也會同步支持 Android 和 Vulkan。

從這個角度猜測，F(xiàn)lutter 在 Skia 遇到的問題 Compose Multiplatform 也很可能會遇上，而如果后續(xù) Impeller 項目進展順利，那它或者并不會局限在 Flutter，也許也可以拓展支持到 Compose Multiplatform 上。

其實自研發(fā)引擎并不奇怪，隨著項目的發(fā)展和深入，很多底層問題沒辦法快速推進就會反推自研，例如Hermes 在 RN 0.7 成為默認 Engine也是類似問題的體現(xiàn)，「自研底層屬于是一個負責任的開源團隊的必經(jīng)之路」。

最后

今天這篇文章的內(nèi)容更多的是科普性質(zhì)而非技術(shù)性，主要是針對目前 KMM、Compose 和 Flutter 的現(xiàn)狀做一個陳述，其實很多時候它們之間并不沖突，但是作為開發(fā)者很經(jīng)常就像開頭一樣，用 "對立" 的角度來看 A 火了 B 就要掛，這種心態(tài)大可不必。

---

長按右側(cè)二維碼

查看更多開發(fā)者精彩分享

"開發(fā)者說·DTalk" 面向中國開發(fā)者們征集 Google 移動應用 (apps & games)?相關(guān)的產(chǎn)品/技術(shù)內(nèi)容。歡迎大家前來分享您對移動應用的行業(yè)洞察或見解、移動開發(fā)過程中的心得或新發(fā)現(xiàn)、以及應用出海的實戰(zhàn)經(jīng)驗總結(jié)和相關(guān)產(chǎn)品的使用反饋等。我們由衷地希望可以給這些出眾的中國開發(fā)者們提供更好展現(xiàn)自己、充分發(fā)揮自己特長的平臺。我們將通過大家的技術(shù)內(nèi)容著重選出優(yōu)秀案例進行谷歌開發(fā)技術(shù)專家 (GDE)?的推薦。

?點擊屏末|閱讀原文|即刻報名參與 "開發(fā)者說·DTalk"

---