这也算是「末法时代的残响」，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 谷歌已经宣布进入不更新的维护模式，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 也要十年了。
所以，虽然时代变了，但是希望这份热爱，还能保留。