1. 从鸿蒙到双端一次跨平台迁移的真实决策现场去年下半年我们团队手里有一个已经跑了大半年的 Grok Bot 项目最初是完整基于鸿蒙生态做的。当时选鸿蒙的理由很直接目标用户群集中系统级能力调用顺手分布式软总线在设备协同场景下几乎不需要额外造轮子。但到了今年年初业务侧提了一个新需求——同一套 Bot 能力要覆盖 iOS 和 Android 两端而且希望尽量复用已有的业务逻辑而不是三端各写一套。这个需求一出来团队内部第一反应是那就分别用 Swift 和 Kotlin 重写一遍 UI 层核心逻辑抽成独立模块。听起来很合理但真正动手评估之后我们发现事情没那么简单。Grok Bot 这类应用的核心复杂度不在界面而在于会话状态管理、流式响应处理、本地缓存策略、以及和多个后端服务的交互编排。这些逻辑如果要在三个平台上各维护一份长期成本会高得离谱。于是我们开始认真评估跨平台方案。市面上主流的选择无非几类React Native、Flutter、Kotlin Multiplatform以及后来进入视野的 CJMP。前三个大家都很熟CJMP 相对来说知名度低一些但恰恰是它在这次迁移中成了我们的最终选择。这篇内容就把我们整个评估、试错、迁移、上线的过程完整拆开讲包括为什么放弃了一些看起来更稳的方案以及 CJMP 在实际落地中到底解决了什么问题、又带来了哪些新的坑。如果你也面临类似的多端迁移决策或者正在纠结跨平台技术选型这篇应该能帮你少走一些弯路。我不会只讲结论而是把每个决策背后的权衡逻辑都摊开说毕竟技术选型这件事脱离具体场景谈优劣基本没有意义。2. 为什么三端各写一套在 Grok Bot 场景下直接出局2.1 核心逻辑的耦合度远超预期很多人对跨平台迁移的想象是UI 层各写各的业务逻辑抽成 SDK 就行。但 Grok Bot 的实际代码结构告诉我们这个假设在复杂应用里往往不成立。我们的会话管理模块里状态机的流转和 UI 的渲染节奏是深度耦合的——比如流式响应到达时UI 需要根据当前会话状态决定是追加气泡、还是替换占位符、还是触发滚动。这种耦合如果强行拆开要么在每端重写一套状态同步逻辑要么把 UI 状态也塞进共享层后者又会导致共享层变得极其臃肿。我们做过一个粗略统计如果走三端各写一套的路线核心逻辑的重复代码比例大约在 65% 到 70% 之间。这意味着每修一个 bug要在三个地方各修一遍每加一个功能要在三个地方各测一遍。团队当时只有两个移动端开发这个维护成本根本扛不住。2.2 鸿蒙端的既有资产不能浪费另一个关键约束是鸿蒙端的代码不能推倒重来。那个版本已经上线有真实用户在用业务侧明确要求鸿蒙端保持稳定iOS 和 Android 作为增量。这就排除了那些需要完全重写业务层的方案。我们需要的是一个能尽量复用现有逻辑、同时又能覆盖 iOS 和 Android 的方案。这里有个细节值得说鸿蒙端的代码是用 ArkTS 写的语言层面和 TypeScript 有亲缘关系。这个事实后来在评估 CJMP 时成了一个加分项因为 CJMP 的语法风格和 TypeScript 也比较接近迁移时的认知负担相对小。当然这是后话当时我们还没意识到这一点。2.3 团队技术栈的现实约束我们团队的技术背景是两个移动端开发一个偏 AndroidKotlin 熟一个偏前端TypeScript 熟鸿蒙端的 ArkTS 是边学边做的。没有人有 Flutter 或 React Native 的生产经验。这个现实意味着如果选 Flutter我们要么招人要么花几周时间让现有成员从零学 Dart如果选 React Native前端那位同学上手会快一些但 Android 那位就要重新适应 JS 生态。技术选型从来不只是技术问题团队的学习曲线和现有技能栈的匹配度往往比方案本身的纸面参数更重要。这一点在后来的决策中反复被验证。3. 四个候选方案的横向拆解与淘汰过程3.1 React Native生态成熟但桥接层是隐患React Native 是我们最先看的方案。优势很明显生态成熟、社区庞大、招人容易。但我们在做技术预研时重点测了它的桥接性能。Grok Bot 的核心场景是流式对话对消息到达的实时性要求比较高。React Native 的 JS 桥接在大量小消息高频传输时会出现明显的延迟抖动。我们做了一个模拟测试每秒推送 20 条流式片段React Native 在低端 Android 设备上的渲染延迟比原生方案高出 40% 到 60%。这个数据不一定适用于所有场景但对我们的流式对话来说体验差距是肉眼可见的。另外React Native 的新架构Fabric 和 TurboModules虽然理论上解决了桥接问题但当时我们的预研版本里新架构的稳定性还不够让人放心社区里关于新架构踩坑的讨论也很多。综合考虑我们把它排在了第二位。3.2 Flutter渲染一致性好但 Dart 是门槛Flutter 的渲染一致性确实没得说自绘引擎让它在两端的表现几乎完全一致。我们试做了一个对话列表的 Demo滚动流畅度、动画表现都很出色。但问题出在团队技能栈上没有人写过 Dart而 Flutter 的生态虽然大但很多第三方库的质量参差不齐遇到问题时要自己啃源码。更关键的是Flutter 和鸿蒙端的 ArkTS 在语言层面几乎没有可复用性。这意味着鸿蒙端的业务逻辑要全部重写一遍这违背了我们复用既有资产的核心诉求。如果团队里有 Flutter 熟手这个方案可能会重新考虑但在当时的条件下学习成本太高了。3.3 Kotlin Multiplatform逻辑共享强但 UI 层仍需各写Kotlin MultiplatformKMP是我们认真评估过的方案。它的核心思路是共享业务逻辑UI 层各端用原生写。这个思路和我们的需求其实很契合——我们本来就不指望 UI 层能完全共享能把会话管理、网络层、缓存层这些核心逻辑共享掉就已经解决了大部分问题。但 KMP 的问题在于它的共享层是用 Kotlin 写的而我们的鸿蒙端是 ArkTS。这意味着鸿蒙端的逻辑没法直接复用要么用 Kotlin 重写鸿蒙端逻辑不现实要么让 KMP 的共享层同时支持 ArkTS 调用当时没有成熟方案。另外KMP 在 iOS 端的互操作虽然能用但 Objective-C 互操作的体验并不算丝滑调试起来比较痛苦。我们评估下来KMP 更适合从零开始的新项目而不是已有鸿蒙端要迁移的场景。3.4 CJMP一个被低估的选项CJMP 进入视野其实有点偶然。团队里那位前端背景的同学在一次技术社区分享里看到了它回来提了一嘴。我们一开始没太当回事因为它的知名度确实不如前三个。但仔细研究之后发现它的设计思路恰好击中了我们的几个痛点。CJMP 的核心特点是它提供了一套跨平台的运行时和编译工具链支持将同一套业务逻辑编译到多个平台而且在语言层面和 TypeScript 有较好的兼容性。这意味着鸿蒙端的 ArkTS 逻辑有很大一部分可以经过适配后直接复用。同时它对 iOS 和 Android 的原生互操作支持比较完整UI 层可以继续用 Swift 和 Kotlin 写共享层则用 CJMP 统一管理。我们做了一个对比表格把四个方案在我们关心的几个维度上做了打分评估维度React NativeFlutterKotlin MultiplatformCJMP鸿蒙端逻辑复用度低低低高流式场景性能中高高高团队学习成本中高中低iOS/Android 互操作中高中高生态成熟度高高中中长期维护成本中中低低这张表不是绝对结论只是我们当时基于自身场景的判断。最终 CJMP 胜出的核心原因就是它在鸿蒙端逻辑复用和团队学习成本这两项上的优势恰好是我们最看重的。4. CJMP 落地实操从环境搭建到首个共享模块跑通4.1 环境准备中最容易忽略的两个细节CJMP 的环境搭建本身不算复杂但有两个细节我们踩了坑。第一个是编译工具链的版本匹配问题。CJMP 的编译器对 Node.js 版本有要求我们一开始用的是比较新的版本结果编译时报了一些奇怪的错。后来降到官方文档推荐的 LTS 版本问题就消失了。这个坑很典型——很多人习惯用最新版本但跨平台工具链往往对版本比较敏感。第二个是 iOS 端的签名配置。CJMP 在编译 iOS 产物时需要调用 Xcode 的构建流程如果你的签名证书配置有问题编译会在最后一步失败而且报错信息不太直观。我们的建议是先把一个纯原生的 iOS Demo 跑通确认签名没问题再接入 CJMP。这样能把问题隔离在更小的范围内。4.2 共享层的目录结构设计CJMP 的共享层代码组织方式直接影响到后续的维护效率。我们最终采用的目录结构是这样的shared/ src/ core/ # 核心会话状态机 network/ # 网络请求与流式处理 cache/ # 本地缓存策略 adapter/ # 各平台适配层 utils/ # 通用工具函数 platform/ ios/ # iOS 特有实现 android/ # Android 特有实现 harmony/ # 鸿蒙特有实现这个结构的关键在于adapter层。CJMP 允许你为不同平台提供不同的实现而共享层通过统一的接口调用。比如网络请求iOS 端可能用 URLSessionAndroid 端用 OkHttp鸿蒙端用系统网络库但共享层只关心发一个请求、拿到流式响应这个抽象。适配层的存在让平台差异被隔离在很小的范围内。4.3 首个共享模块的跑通过程我们选的第一个共享模块是会话状态机。选它的原因是这个模块逻辑相对独立不依赖 UI而且鸿蒙端已经有一版经过验证的实现迁移过来可以直接对比行为是否一致。迁移过程比预想的顺利。鸿蒙端的 ArkTS 代码里状态机的核心逻辑大约 800 行其中约 600 行可以直接复用剩下 200 行主要是平台相关的部分比如时间戳获取、日志输出改成 CJMP 的适配层接口就行。整个迁移加调试花了大约两天时间跑通后的行为对比测试也通过了。这里有个经验值得分享迁移时不要追求一次全迁而是按模块逐个迁移每迁一个就做一次行为对比。这样一旦出问题排查范围很小。我们见过一些团队一上来就全量迁移结果出了问题根本不知道是哪个模块的锅。5. 迁移过程中真正让人头疼的三个坑5.1 流式响应的背压处理Grok Bot 的流式对话有一个特点后端推送速度可能快于 UI 消费速度。在鸿蒙端我们用的是系统提供的流式 API背压处理比较自然。但迁移到 CJMP 共享层后流式数据的缓冲和消费需要自己管理。我们最初的实现是简单的队列结果在低端 Android 设备上出现了内存增长过快的问题。后来改成了带背压的环形缓冲区当缓冲区满时主动向上游施加压力让后端推送慢一点。这个改动让内存占用稳定了下来。具体来说我们把缓冲区大小设为 64 条消息超过这个阈值就触发背压信号。这个数值不是拍脑袋定的而是根据低端设备的单条消息平均处理耗时约 15ms和可接受的最大延迟约 1 秒反推出来的。5.2 iOS 端的后台保活限制iOS 对后台任务的限制比 Android 严格得多。我们的 Bot 需要在后台保持一定的连接活性以便用户切回来时能快速恢复会话。在鸿蒙端这个需求通过系统提供的后台任务机制解决。但 iOS 上后台执行时间非常有限超过就会被系统挂起。我们的解决方案是在 iOS 端不追求后台保持连接而是改为切回前台时快速重连 增量同步。具体做法是应用进入后台时记录当前会话的最后一条消息 ID切回前台时用这个 ID 向后端请求增量消息。这样既符合 iOS 的后台策略又能保证用户切回来时看到完整的会话。这个改动虽然增加了同步逻辑的复杂度但实测下来体验反而更稳定因为不用担心后台被系统杀掉。5.3 鸿蒙端与共享层的类型对齐鸿蒙端的 ArkTS 是强类型的CJMP 共享层也是强类型的但两者的类型系统并不完全一致。比如 ArkTS 里的Recordstring, Object在 CJMP 里没有直接对应需要转换成Map或者自定义结构。这类问题在迁移初期频繁出现每次都要手动处理。我们的应对策略是在适配层里做一层类型转换把平台特有的类型统一转换成共享层能识别的类型。这层转换虽然增加了一些代码量但把类型差异隔离在了适配层共享层的代码可以保持干净。另外我们写了一套类型转换的工具函数常用的转换场景基本都覆盖了后续迁移新模块时直接复用就行。6. 上线后的性能表现与长期维护观察6.1 两端性能数据对比上线后我们做了一轮性能对比重点看几个关键指标冷启动时间、流式消息首字延迟、内存占用峰值。测试设备选的是各平台的中端机型避免用旗舰机得出过于乐观的结论。指标鸿蒙端原生iOS 端CJMPAndroid 端CJMP冷启动时间1.2s1.4s1.6s流式首字延迟180ms210ms240ms内存峰值120MB135MB150MB从数据看CJMP 方案相比原生鸿蒙端有轻微的性能损耗但幅度在可接受范围内。iOS 端表现比 Android 端好一些这主要得益于 iOS 的设备一致性更高而 Android 设备碎片化严重低端机上的表现会差一些。不过整体来说这个性能差距没有影响到用户体验用户反馈里也没有关于卡顿的集中投诉。6.2 维护成本的实际情况迁移完成后的三个月里我们统计了一下维护成本的变化。最直观的感受是修 bug 的效率大幅提升。以前鸿蒙端修一个逻辑 bug要单独发版现在共享层的 bug 修一次三端同时生效。功能迭代的速度也快了以前加一个会话相关的小功能三端各写一遍要三天现在共享层改完两端适配层稍微调整一下一天就能搞定。当然CJMP 也带来了新的维护点适配层的代码需要针对不同平台分别维护。但适配层的代码量很小大约只占共享层的 15% 左右而且大部分是稳定的不需要频繁改动。整体算下来维护成本比三端各写一套低了至少一半。6.3 什么情况下不建议选 CJMP说了这么多 CJMP 的好话也得客观讲一下它的局限。如果你的项目满足以下条件可能不适合选 CJMP第一团队里完全没有 TypeScript 或类似语言的经验学习成本会比较高第二项目对性能极度敏感比如高频交易、实时游戏这类场景原生方案仍然是更稳妥的选择第三项目只需要覆盖单一平台那跨平台方案的价值就体现不出来。技术选型没有银弹CJMP 在我们这个场景下表现很好不代表它在所有场景下都是最优解。关键是想清楚自己的核心约束是什么然后找最匹配的方案。7. 给正在做类似迁移决策的团队几点实在建议如果你也在考虑从单一平台迁移到多端或者正在评估跨平台方案我有几个从这次实践中总结出来的建议。第一先做技术预研但预研的重点不是跑通 Demo而是验证核心场景。很多团队预研时只跑一个 Hello World觉得能跑起来就选它结果上线后才发现核心场景有性能问题。我们的预研重点就是流式对话因为这个场景最能暴露方案的短板。第二迁移要按模块推进每个模块迁移后都要做行为对比测试。不要相信逻辑一样所以行为一定一样平台差异往往藏在细节里。我们每个模块迁移后都会跑一套对比用例确保新旧实现的行为一致。第三适配层的设计要提前规划。跨平台方案的核心难点往往不在共享层而在适配层。适配层设计得好平台差异就被隔离在很小的范围内设计得不好共享层就会被平台特有的逻辑污染最后变得和各写一套差不多。第四不要忽视团队的学习曲线。技术方案再优秀如果团队上手成本太高落地效果也会打折扣。我们选 CJMP 的一个重要原因就是它和团队现有技能栈的匹配度高这让迁移过程顺利了很多。最后分享一个我们踩过的小坑CJMP 的编译缓存有时候会失效导致全量编译耗时很长。后来我们发现是某个中间产物的时间戳被意外修改了。解决办法是在 CI 流程里加一步清理缓存的检查确保缓存目录的完整性。这个问题不常见但一旦遇到会很影响开发效率提前知道能省不少时间。