近日 JetBrains 正式發布了 Compose Multiplatform 1.0 版，這標志其在生產環境中使用的時機已經成熟，相信有不少人對它還不太熟悉，本文通過下面 10 個熱門問題帶大家認識這一最新的跨平臺技術，

FAQ：

1. 與 Jetpack Compose 的關系?
   
2. 是否會取代 Flutter ?
   
3. 有何技術優勢？1.0是否已穩定？
   
4. Android Studio 還能使用嗎？
   
5. 性能怎么樣？
   
6. 生態建設如何？
   
7. 桌面應用開發是否要引入 JVM ？
   
8. Web 端開發是否已經成熟？
   
9. 未來是否支持 iOS ？
   
10. Jetpack 是否會跨平臺？
    

正文開始前先統一一下文中的用語：

• compose-jb：Compose Multiplatform 簡稱，包含下面三者
• compose-android：Jetpack Compose
• compose-desktop：Compose for Desktop
• compose-web： Compose for Web

1. 與 Jetpack Compose 的關系?

Jetpack Compose 是 Google 針對 Android 推出的新一代宣告式 UI 工具包，完全基于 Kotlin 打造，天然具備了跨平臺的使用基礎，JetBrains 以 Jetpack Compose（后文簡稱 compose-android）為基礎，相繼發布了 compose-desktop 和 compose-web ，使 Compose 可以運行在更多不同平臺，

Compose Multiplatform （后文簡稱 compose-jb）本質上是將 compose-desktop，compose-web 以及 compose-android 三者進行了整合，開發者可以在單個工程中使用同一套 Artifacts 開發出運行在 Android，Desktop（Windows, macOS, LInux）以及 Web 等多端的應用程式，工程中可以實作大部分代碼的共享以此達到跨平臺開發的目的，

所以在概念上 compose-jb 可以看做是 compose-android 的超集；在具體實作上 compose-jb 則是在 fork 了 compose-android 的原始碼基礎上增加了對 Desktop 和 Web 側的 API，
compose-jb 與 compose-android 同步更新，compose-jb 的 1.0 版本目前對應到 compose-android 1.1.0-beta02，因此在通用的 API 上 compose-jb 與 compose-android 時刻保持一致，不同的只是包名發生了變化，所以你可以將你的 compose-android 代碼低成本地遷移到 compose-jb 工程中，

2. 是否會取代 Flutter ?

compose-jb 雖由 JetBrains 發布，但是作為 Flutter 的開發者 Google 對其也是樂見其成，因為 Compose 與 Flutter 雖然都是跨平臺技術，但是兩者定位不同所以不存在直接競爭關系，

Flutter 的定位就是移動端跨平臺解決方案，它的一切能力建設都是圍繞如何更好地“一次撰寫、隨處運行”，首要目標就是為了降低移動應用的開發成本（雖然最近也擴展到 Desktop 以及 Desktop），

compose-jb 的首要定位是一個宣告式 UI 工具包，它的目標是通過更先進的開發范式提升 UI 開發效率，由于宣告式開發思想適應性廣泛，所以借助 Kotlin 成為一個跨平臺框架便是水到渠成的事情， 如果說是 Flutter 成就了 Dart，那么 Kotlin 則成就了 Compose ，借助 Kotlin 近年來持續高漲的的人氣，Compose 的未來也充滿想象空間，

compose-jb 的受眾主要有兩類，首先是熟悉 Kotlin 與 Compose 的 Android 開發者，他們可以把自己的產品交付至更多平臺；其次是 Kotlin 經驗者，他們可以使用熟悉的語言更高效地開發包含 UI 的應用程式，像 JetBrains 這樣的 IDE 公司就屬于后者，他們迫切希望使用 Compose 替換 Swing 和 AWT 等基于 Java 的陳舊的技術堆疊，這也正是 compose-desktop 誕生的初衷，

3. 有何技術優勢？1.0是否已穩定？

應用開發無非關注三件事：資料獲取，狀態管理，界面渲染，
JetBrains 推出 Kotlin Multiplatform Mobile （簡稱 KMM） 實作了資料獲取部分的跨平臺，而 compose-jb 將跨平臺的范圍進一步覆寫到狀態管理甚至界面渲染（基于 Skia），

在一個 compose-jb 工程中，邏輯層（狀態管理）以及資料層的代碼在幾乎可以完全共享，在表現層，常用的組件和布局例如 Text，Button，Column/Row 等都可以跨越 compose-android 與 compsose-desktop 通用，此外 compose-desktop 針對桌面系統的特性還提供了專用能力，比如可以感知滑鼠行為和視窗大小、創建 Scrollbars，Tooltips，Tray 等

fun main() {
   Window {
       var windowSize by remember { mutableStateOf(IntSize.Zero) }
       var windowLocation by remember { mutableStateOf(IntOffset.Zero) }
       AppWindowAmbient.current?.apply {
           events.onResize = { windowSize = it }
           events.onRelocate = { windowLocation = it }
       }
       Text(text = "Location: ${windowLocation}\nSize: ${windowSize}")
   }
}

compose-desktop 還提供了 SwingPanel 用來嵌入使用既有的 Swing 組件，compose-desktop 在能力上完全可以替代 AWT 和 Swing 等現有 UI 框架，

compose-web 為 Web 開發者提供了專門的 DOM API，針對常用的 HTML 標簽實作了對應的 Composable 組件，例如 Div，P，A 等等 ，同時提供了 attrs 方法以 key-value 的形式設定標簽屬性，一些常用屬性也有專屬方法；另外，基于 CSS-in-JS 技術 compose-web 允許開發者基于 DSL 定義 Style 樣式，

fun main() {
    renderComposable("root") {
        var platform by remember { mutableStateOf("a platform") }
        P {
            Text("Welcome to Compose for $platform! ")
            Button(attrs = { onClick { platform = "Web" } }) {
                Text("...for what?")
            }
        }
        A("https://www.jetbrains.com/lp/compose-web") {
            Text("Learn more!")
        }
    }
}

compose-web 擁有 HTML 或 JSX 那樣的結構化的變現能力，同時有具備了回應式狀態管理能力，在 compose-jb 中還可以與 Desktop 和 Android 側共享邏輯層代碼，

穩定性方面，compose-jb 的大部分代碼來自 Jetpack Compose，在 Android 端已經有上千款 App 接入，這足以保證其在 Android 端上的穩定性，

JetBrains 在幾個月之前就將 Toolbox 應用從 C++ 和 Electron 遷移到了 compose-jb，并一直平穩運行，服務著超過 100 萬的月活用戶，常規的 UI 開發得到了檢驗，但是一些復雜功能可能還不夠穩定，目前還有不少 issue 有待解決，

4. Android Studio 還能使用嗎？

compose-jb 1.0 可以運行在 IntelliJ IDEA 2021.1 之后的版本中，IDEA 專門為其提供了工程向導和專案模板，指導開發者快速新建一個 compose-jb 專案，

開發者還可以通過插件市場下載 compose-desktop 側的專用預覽插件，在 Desktop 端實時預覽添加 @Preview 的 Composalbe，提高開發效率，

Andorid Studio 作為 IntelliJ 平臺下的 IDE ，自然也可以用于 compose-jb 專案的開發（ IDEA 2021.1 對應 Android Studio Bumblebee 之后的版本），AS 自帶 Andoid 側的預覽能力，可以實時預覽 UI 代碼效果，此外 AS 對 Compose 的代碼提示也更友好，比如非法呼叫 @Composable 函式時， IDE 會標紅提示錯誤，而 IDEA 則只能在編譯時發現錯誤，

5. 性能怎么樣？

compose-android 和 compose-desktop 都使用 Skia 這一開源圖形庫進行渲染，Skia 在 Chrome，Flutter 等多個專案中廣泛使用，性能方面得到了驗證，Skia 還能支持平臺特有的硬體加速技術，例如 DirectX，Metal 和 OpenGL 等，compose-jb 為沒有硬體加速的設備也提供了優化的軟體渲染方案，曾經有人將 compose-desktop 與 JavaFX 進行過實際對比測驗，在通常情況下兩者渲染性能相當，盡在極端情況下會略遜于 JavaFX，不過已經足夠優秀了，

https://dev.to/gz_k/jetpack-compose-desktop-rendering-performances-4992

Web 側 compose-jb 會通過 Kotlin/JS 編譯器將代碼仍然編譯成 JS 代碼在瀏覽器運行，所以理論上與傳統的 Web 開發方式在性能上沒有區別，由于 CSS-in-JS 實作都是在運行時生成 CSS，僅僅在這一點上相對于直接使用 CSS 前端專案可能略有一點性能損耗，

而在邏輯代碼由于使用 Kotlin 作為開發語言，代碼的執行效率要明顯優于基于 Node 的 Electron 等同類跨平臺框架，Kotlin/JVM 也保證了在桌面側至少有與 Java 同樣的運行時性能，

6. 生態建設如何？

compose-jb 依托 Kotin Multiplatform 的豐富類別庫，滿足各種層面的能力開發，比如在架構、網路、資料存盤等各方面都有不少優秀的的解決方案，一些代表性的專案如下：

More libraries：https://libs.kmp.icerock.dev/

7. 桌面應用開發是否要引入 JVM ？

compose-jb 在桌面端需要支持 Windows，macOS，Linux 等多套作業系統，基于 Kotlin/Native 的實作成本較高，因此現階段 compose-desktop 仍然依賴 Kotlin/JVM 編譯成 Java 位元組碼后再發布到各桌面系統，

compose-desktop 提供了專用的 Gradle 插件可以基于 jpackage 將 JVM 一同打包進各種格式的安裝包，例如 Mac 的 dmg, Windows 的 msi，exe 以及 Linnux 的 deb 等，使用者無需額外安裝 JDK ，可以像二進制程式一樣開箱即用，此外還通過使用 jlink 技術只對 Java 模塊的最小依賴進行打包以最大限度降低包體積，

$ ./gradlew package

> Task :packageDmg
WARNING: Using incubator modules: jdk.incubator.jpackage
The distribution is written to build/compose/binaries/main/dmg/DesktopApp-1.0.0.dmg

BUILD SUCCESSFUL in 11s
5 actionable tasks: 3 executed, 2 up-to-date

目前對 Kotlin/Native 編譯器的適配作業也在進行中，未來 compose-desktop 有望通過切換到 Kotlin/Native 進一步提高應用的執行速度，

8. Web 端開發是否已經成熟？

compose-jb 中整合 compose-web 的最主要意義是幫助 Kotlin 開發者擴大應用的發布場景，如果你已經有一個 compose-desktop 或者 compose-android 專案，那么基于 compose-web 可以把產品快速發布到 Web 端，并共享其中大部分的邏輯代碼，

compose-web 提供的宣告式 DOM API 相對于 HTML+JS+CSS 這一傳統技術堆疊在開發范式上更加先進，但如果你已經有 React 等前端框架的使用經驗那么此項優勢就不存在了，而且 compose-web 在建設速度上要落后于 compose-desktop，部分 HTML 標簽以及屬性還缺少對應的 DSL 實作，所以從單純開發一個前端應用的角度看，如果你對 Kolin 沒有執念的話，更推薦使用 React 等已有的成熟框架，

即使從跨平臺的角度看， desktop-web 也仍然有改善空間，desktop-web 在 API 設計上尊重原有的 HTML 開發習慣，這也導致其 DSL 上與 compose-android 和 compose-desktop 的差異較大，不利于 UI 代碼的共享，據悉 JetBrains 團隊已經著手開發與其他兩端風格一致的 DSL ，屆時可以通過 HTML5 Canvas 實作 UI 統一繪制，提高跨平臺的開發體驗，

9. 未來是否支持 iOS？

compose-jb 目前沒有對 iOS 端的支持，這是其成長為主流跨平臺框架道路上的一個嚴重阻礙，因此可以大膽猜想 compose-jb 在未來一定會增加對 iOS 的支持，而且有跡象表明 JetBrains 已經偷偷開始了這方面作業，

有人就曾經在 compose-jb 工程中也發現過針對 iOS 的開發分支，而且 compose-ui 依賴的 Skiko 庫也已經增加了對 iOS 的支持，理論上完全可以實作 iOS 側渲染，由于 iOS 不使用 Kotlin/JVM ，所以在 Kotlin/Native 編譯器以及 iOS 工具鏈等方面存在大量適配作業，畢竟 KMM 本身也還處于 alpha 階段，iOS 端的開發體驗還不理想，這可能就是 compose-ios 遲遲未發布的原因，但是未來是可以期待的，

那么在 compose-ios 還未出現的當下，如果你的應用有發布到 iOS 側的需求，作為一個過渡方案可以先借助 KMM 推薦 D-KMP 架構實作邏輯層和資料層的代碼共享，UI 側現階段可以使用 Swift-UI 等平臺語言進行開發，等待 compose-ios 真正到來時再對 UI 代碼進行遷移，

https://github.com/dbaroncelli/D-KMP-sample

10. Jetpack 是否會跨平臺？

很多 Android 開發者習慣于 Compose 搭配 Android 的 Jetpack 系列組件一同使用，所以當一個 compose-android 專案被遷移到 compose-jb 時，不少人希望有對應的 KMP 版本 Jetpack 庫可供使用，

在前不久 Android Dev Summit 上 Andorid Jetpack 團隊就這個問題進行了回答，答案是暫時沒有相關計劃，

https://www.youtube.com/watch?v=QreLkok3Euk&t=565s

首先 Jetpack 中一些重度依賴 Andorid 平臺特性的組件不適合發布 KMP 版本，而一些平臺無關的組件例如 Hilt，Room 等，雖然具備 KMP 化的基礎但仍然會謹慎啟動，因為當前首要任務還是保證其在 Android 端的穩定使用，雖然當前沒有計劃但是 Jetpack 團隊也表示了未來會嘗試對部分 Jetpack 庫進行 KMP 改造，他們很樂于幫助開發者能更低成本地完成專案向 KMP 的遷移，

對于開發者來說，如果你的專案近期有跨平臺的需求，那么在技術選型上就要避免過度依賴 Jetpack ，而要像 KMP 的 Library 傾向，比如在邏輯層優先使用 Flow 而非 LiveData 等；在資料層也可以考慮使用 SQLDelight 替代 Room ，