小編精選 - 技術文章翻譯 · 06月01日

GSY 史上最全跨平台／架構／語言的專案，七大專案召喚「神龍」

GSY 史上最完整跨平台／架構／語言的專案，七大專案召喚「神龍」

**這也算是「末法時代的殘響」**，GSYGithubApp 是從 9 年前第一個 RN 專案開始的，那時候 GitHub 還沒有官方 App，所以就想著替自己做一個手機 App。

自此第一個 RN 版本 的 GSYGithubApp 就誕生了，之後 Weex 版本、Flutter 版本、Kotlin XML 版本 也陸續作為學習對照專案發布，最後就是這一年的 Compose 版本，還有最近的 CMP 版本 和 OH ArkUI 版本，自此 GSYGithubApp 也算是集齊了「七顆龍珠」：

而最近除了完成 Compose Multiplatform 和 Harmony ArkUI 版本之外，也把其他專案都更新到了最新版本，特別是 Weex 這個已經被歸檔的專案，這次直接重構成了 Uni-App 版本：

Kotlin XML 版本升級適配 AGP 9，並適配了 16K page size，XML View Google 已經宣佈進入不再更新的維護模式，這次 Kotlin 的更新也算是最後的送終？
React Native 版本升級到 0.85 版本，實際上去年從 0.6x 版本升級到 0.8x 版本才是最難受的，這次更新到 0.85 倒沒有什麼問題，主要也是適配了 16K page size
Flutter 版本倒也沒有什麼特別變化，基本都有持續跟進新版本
Weex 版本只能說是時代的眼淚，作為第二代 GSYGithubApp，Weex 沒想到即使被阿里「捐」給 Apache，最後還是逃不過歸檔的命運，所以這次直接遷移重構成 uni-app 版本，至少還能繼續苟延殘喘
Compose 版本這次主要是透過 compose_skill 進行了效能優化，同時也升級到了新版本

然後就是 ArkUI 版本和 Compose MultiPlatform 版本，作為最後加入的「末法殘響」，一開始在 Harmony 平台時，本來是想乾脆試試 CJMP（倉頡 MultiPlatform），結果發現現在倉頡的跨平台 UI 適配太雜，而且實際真正能用的核心也依賴對齊 ArkUI-X，所以最後 GSYGithubAppOH 還是用 ArkUI 實作。

這裡不得不提一句，現在華為牽頭的 PMC 鴻蒙適配社群確實起來了，主流框架適配鴻蒙的支援也基本可用，另外 ArkUI 相較過去也穩定了不少，至少 API 23 上的體驗還過得去：

之後花最多時間的其實是 Compose MultiPlatform 版本，原本想著直接從 Compose 版本 Fork 一個分支出來應該很快，結果想像和實際還是有不少落差，這次遷移直接用了 AGP 9 + 新的 KMP 架構，但在把 Kotlin 程式碼沉澱到 shared 模組時卻遇到不少問題。

原本 Compose 專案要從 Android 支援到 Desktop JVM、iOS Kotlin Native 等場景，需要對既有的依賴和程式碼做不少調整，這個過程需要把所有業務從 Android runtime 裡抽出來，然後用 commonMain 寫真正的產品邏輯，同時用 expect/actual 或 host 層適配平台能力。

看起來 CMP 雖然是 Kotlin 從 Compose 變成 Compose MultiPlatform，但實際上很多實作架構不一定支援 Desktop JVM 和 iOS 的 Kotlin Native，所以為了讓 Compose MultiPlatform 能跑起來，就需要重構一些實作：

不能用 Retrofit / OkHttp，因為它不支援 Kotlin Native，所以需要改成 Ktor，而 Ktor 底層會透過不同 engine 完成網路請求，例如：
- Android：OkHttp engine
- Desktop JVM：CIO engine
- iOS / macOS：Darwin engine
- 還有一些小問題，例如 Android 裡 OkHttp interceptor 讀取 token 很自然，但換到 Ktor 後如果繼續用 bearer plugin，token 生命週期就變了
資料庫 Room 遇到多平台不適配問題，期間需要處理升級 Room 3 和 KSP 適配問題，要嘛編譯看不到 _Impl，要嘛 expect/actual 出現在同一個 source set 導致 K2 hard error，而且 Room commonMain DAO 對回傳型別更嚴格
Android resource 到 Compose Resources 的遷移，Android resource 和 Compose Resources 的套件名稱、生成時機、呼叫 API 都不同，只要 commonMain 裡殘留 R.string，iOS/JVM 編譯就會掛
Navigation 導航的 CMP 適配也是各種需要遷移適配
WebView 在多平台適配也是痛點，各端差異也比較大，特別是 Desktop 打包必須帶 JavaFX classifier
最後還有各種套件名稱不一致，Android API 如 Toast 的處理，Hilt 改成 Koin，Dispatchers.IO 在 Kotlin Native 上的問題等等
·····

所以把 Compose 轉成 CMP 的成本其實並不低，實際上 Compose 和 CMP 的割裂感還是存在的。

最後

其實在 AI 時代，GSYGithubApp 系列專案的價值已經不高了，因為基本沒幾個人還真的會去看程式碼學習，自己寫的程式碼都懶得 Review，怎麼還會去看別人的程式碼？

而 GSYGithubApp 系列對我來說最大的價值還是嘗試和對比，首先它是一個具有各類基本功能場景的完整 App，並且現在涵蓋不同平台、不同架構和不同語言，所以一些功能測試、更新迭代和可行性對照都能有一個相當不錯的容器，而且現在還有持續維護，同時支援跨這麼多框架和語言的專案確實也少見，也算是另一種形式的「自我滿足」，畢竟想想 GSYVideoPlayer 也要十年了。