上个月我们刚把 GroK Bot 的鸿蒙版停掉正式转向 iOS 和 Android 双端。说起来有点狼狈团队最开始只有三个人为了抢一个内测名额用最快的速度在原生鸿蒙上写了一个 AI 对话 Demo后来这个 Demo 因为口碑还不错用户量慢慢涨了上来。然后渠道方的需求就来了iOS 和 Android 同时上线时间卡得很死。当时全团队心里都清楚一件事——鸿蒙那套代码一行都没法直接复用而跨端方案选型成了决定生死的第一道关卡。我们评估了 React Native、Flutter、双端原生拆分最后把宝押在了一个内部代号叫 CJMP 的跨端方案上。这篇文章就是这次迁移的完整复盘包括我们为什么放弃其他方案、CJMP 的架构核心、迁移实操细节以及一堆不踩不知道的坑。1. 项目痛点鸿蒙单一平台的困局1.1 原始架构是怎么搭起来的先说下 GroK Bot 最初的技术形态。当时为了抢内测UI 层直接用 ArkTS 写界面逻辑、状态管理、网络请求全部混在一起底层用 C 写了一个引擎库承载核心能力再通过鸿蒙的 NAPI 暴露给 ArkTS 调用。引擎里封装了 WebSocket 长连接、消息协议编解码、TTS 播放、会话状态机这些相对“重”的东西UI 层主要负责渲染气泡、管理输入框和调用引擎接口。这个架构在单一平台上跑得很顺因为 NAPI 的调用链路短ArkTS 直接同步调用 C 接口传参和回调都不用考虑跨语言太多事情。但问题也埋在这里当时为了追求速度几乎没有做平台隔离业务状态、会话缓存、网络回调都直接写在 ArkTS 里引擎接口也不是按“平台无关”的标准设计的。一旦要脱离鸿蒙环境这些代码全都变成沉没成本。等到双端需求下来我们把代码库翻了一遍能带走的只剩两块一块是 C 引擎层另一块是产品层面的交互逻辑和 Prompt 链路设计。UI 层的 ArkTS 代码约等于一次性筷子用完就得扔。1.2 需求突然变化后我们列出的硬指标需求变更不是简单的“多支持两个平台”而是要在限定时间内完成重构所以我们首先把硬指标列出来避免选型的时候被花哨的框架宣传带偏双端必须同时覆盖 iOS 和 Android且核心功能保持一致AI 对话链路、Prompt 模板、会话上下文管理必须原样保留不能因为换框架产生行为偏差首批支持至少 5 个主流机型包括配置偏低的千元机安装包体积尽量控制在 60MB 以内带内置 TTS 资源冷启动时间目标在 3 秒以内对话流式输出首字延迟不超过 1.5 秒后续版本要支持不发原生包的热更新能力其中争议最大的是热更新。有人觉得跨端方案本身已经能省掉很多发版成本没必要再加热更新。但 GroK Bot 的 Prompt 模板和会话策略迭代非常频繁每次都要走应用商店审核的话产品节奏会慢到没法接受。所以热更新被定成硬指标这也基本排除了某些不支持动态化的方案。1.3 为什么没有选择“拆成三套原生”先算一笔人力账团队一共 8 个人如果拆三套原生意味着 UI 层要有三波人同时维护同一个对话框、同一个设置页、同一个引导流程要写三遍。Bug 会在三个仓库里以不同形态出现版本节奏也很难对齐。对于当时那个状态的产品来说三套原生等于把本就不充裕的研发资源砍成三份每份都不够用。而且三套原生最大的坑不只在开发阶段后续每个功能迭代都要同步改三个代码库任何一个库漏提了改动用户看到的就是功能不一致。我们之前在一个小功能上试过双端同步结果还是花了两倍时间对齐样式差异三端只会更惨。当然原生并不是完全没有不可替代性GroK Bot 里的 TTS 播放、音频焦点管理、后台保活这些能力最终还是需要原生代码介入但这可以放在跨端框架的原生层解决不意味着整个 UI 和业务逻辑都要拆成原生。2. 跨平台方案横评谁才是真的“能打”2.1 React Native 生态圈的诱惑与陷阱说实话一开始最想选的是 React Native毕竟生态大、社区热、学习资料多团队里也有人写过 JS 和 TS上手成本看着最低。但 GroK Bot 有一个极其关键的场景对话内容是流式输出的词是一个一个蹦出来的每个 chunk 到达都要触发 UI 更新。这种高频、小数据量的刷新在 React Native 里必须穿过 JS 和原生之间的桥而桥的异步模型决定了它天然不适合这种场景。实测下来React Native 在长对话列表上滚动刷新时帧率会明显掉到 30fps 附近词块到达时列表重新渲染还会出现肉眼可见的闪烁。另外我们要接 TTS 播放和音频路由React Native 的第三方库覆盖不够深最终还是要自己写原生模块等于省下来的成本又还回去一部分。还有一个被很多人忽视的问题React Native 的版本升级痛苦指数很高尤其是原生依赖多的时候升级一个版本可能牵扯十几个第三方库的兼容性调整。GroK Bot 当时已经有比较复杂的原生依赖我不想在迁移过程中再背上一个“升级地狱”的包袱。2.2 Flutter 渲染一致性的代价Flutter 的诱惑在于渲染一致性自绘引擎不管在 iOS 还是 Android 上都能画出完全一样的界面这对设计同学来说很友好。但它的问题对 GroK Bot 来说也很致命。我们的核心资产是 C 引擎Flutter 的方案意味着要设计一套 Dart 与 C 之间的 FFI 层Struct 映射、内存生命周期、回调线程切换、错误传播每一项都要重新造轮子。我见过不少 Flutter C 的项目初期跑得欢越往后越难维护因为 Dart 的垃圾回收和 C 的手工内存管理完全是两种思维边界稍微一复杂就很容易出现 release 了还在用、或者该释放的不释放的问题。另外Flutter 在 iOS 上做后台音频、音频焦点这类系统级能力时还是要走 MethodChannel 回到原生桥接问题一个没少。对于 GroK Bot 这种依赖底层系统能力的产品Flutter 的优势并没有想象中大。2.3 各家方案对比速览把几个候选方案放在一张表里主观评分仅供参考对比项React NativeFlutter双端原生CJMPUI 开发效率高高低中流式高频刷新性能中高高高C 核心复用度低中低高热更新能力强受限无强包体积控制中偏大小中团队技术栈匹配JS/TSDart分语言C/JS系统级能力接入成本中高中高低低React Native 输在流式性能Flutter 输在 C 接入成本双端原生输在人力不够。CJMP 能赢本质上是因为它的架构形态和 GroK Bot 的技术资产恰好对上了。2.4 CJMP 第一次进入视野时的第一印象先说清楚CJMP 不是市面上那种开箱即用的通用框架它是我们内部给这套跨端方案起的代号全称是 C JavaScript Multi-Platform。核心思路是三层分离C 写真正干活的引擎JavaScript 写 UI 和页面逻辑双端各自用最薄的桥接层把两者接通。我第一次看到这种结构时第一反应是这不就是我们鸿蒙版那个架构的“平台无关化”版本吗鸿蒙版本来就是 C 引擎加 ArkTS UICJMP 只是把 ArkTS 换成了 JavaScript把 NAPI 换成了 ObjC / JNI 桥接层。这意味着我们可以把整套 C 引擎几乎原封不动搬过去业务逻辑用 JS 重写一遍迁移范围比从零开始小太多了。当然第一印象归第一印象真正决定选它的是后面那次为期两周的 PoC 验证。我们拿 GroK Bot 最核心的“流式对话”场景做了双端原型C 引擎接 WebSocketJS 层渲染流式气泡结果从开发到跑通只用了 5 天首字延迟和帧率都达标。从那一刻起团队内部基本达成了一致。3. CJMP 架构核心为什么它适合 GroK Bot 这种 AI 应用3.1 一句话理解 CJMP 的架构形态用一个汽车比喻来拆解 CJMP 的分层逻辑C 核心层是发动机负责真正产生动力的事情——网络通信、协议解析、音频播放、状态计算JavaScript 层是驾驶舱负责驾驶员看到的仪表盘和方向盘也就是界面交互、页面跳转、数据展示双端的桥接层是传动轴发动机和驾驶舱之间靠它传递信号不同车型的传动轴结构不同但发动机本身不用换。这个比喻能直接解释我们为什么选它GroK Bot 最重、最难做、最不希望被平台差异影响的逻辑都在发动机里放到 C 层之后iOS 和 Android 共用同一套代码不需要为了平台差异维护两套算法。UI 逻辑虽然也有差异但驾驶舱的改动成本低用 JavaScript 在不同平台上做条件渲染就够了。3.2 C 核心层的价值算法与协议栈复用GroK Bot 的核心资产集中在以下几块WebSocket 长连接管理断线重连、心跳保活、消息序列号消息协议编解码二进制帧解析、压缩与校验流式解析器把模型返回的增量内容切分、累积、触发回调TTS 音频播放器音频解码、播放调度、焦点处理会话状态机多轮对话的上下文状态迁移、超时处理这些模块全部用 C 实现并下沉到 core 层之后iOS 和 Android 只需保留一份源码。鸿蒙版里这些逻辑原本就是 C 写的所以我们等于把最有价值的部分完整继承了下来。后续再扩展端侧模型推理也直接在 C 层接 ONNX Runtime不会涉及业务层改动。这里有个关键原则core 层必须零平台依赖不能出现任何 #ifdefAPPLE或 #ifdefANDROID之类的东西。所有平台差异都通过抽象接口注入比如文件路径、系统时间、网络接口core 里只定义纯虚基类由各平台实现。这个原则我们刚开始没守住后面踩了坑下面实操章节会专门讲。3.3 JS 业务层的价值动态发版与热更新GroK Bot 的业务层有几个特点页面数量不多但迭代频率极高。会话列表、Prompt 模板管理、设置项、引导流程几乎每两周就要改一轮。用 JavaScript 写这些逻辑的最大好处是可以在不发布原生包的情况下走热更新用户下次打开 App 时自动拉取最新 bundle不需要经过应用商店审核。安全性上我们会把核心鉴权逻辑放在 C 层JS 层只处理界面状态和展示数据这样即使热更新的包被恶意篡改攻击面也有限。有人说“热更新不安全”但 GroK Bot 的实践表明只要把关键路径收敛在 C 层JS 层热更新暴露的风险完全可以接受。还有一个容易被忽略的点JS 层做 UI 布局时双端差异比想象中小得多多出来的部分用条件渲染去适配就够了。比如 iOS 的 TabBar 需要避让底部 Home IndicatorAndroid 的沉浸式状态栏处理方式不同这些差异在 JS 层判断一次平台类型选择不同的样式参数就行不用走到原生层。3.4 双端桥接细节iOS 的 ObjC 与 Android 的 JNI桥接层是整个 CJMP 方案里技术密度最高的部分。iOS 侧相对好办Objective-C 允许直接混编 C 源码桥接成本非常低。我们只需要做一个 ObjC 的封装类把 C 引擎的接口暴露给 JS 层调用同时把引擎回掉转成 JS 事件。Android 侧则必须走 JNIJNI 的类型转换、方法签名、异常处理都要小心处理模板代码量明显大得多。先看统一抽象接口我们在 core 层定义一个事件回调解耦器class IBotEventHandler { public: virtual ~IBotEventHandler() default; virtual void onStreamChunk(const std::string text) 0; virtual void onStateChanged(BotState state) 0; virtual void onError(int code, const std::string message) 0; }; class BotEngine { public: explicit BotEngine(std::shared_ptrIBotEventHandler handler); void startSession(const std::string sessionId); void sendMessage(const std::string message); void stopSession(); };JS 层不直接看到这个 C 接口而是通过桥接层转发。Android 的 JNI 部分长这样extern C JNIEXPORT void JNICALL Java_com_example_grok_BotBridge_sendMessage(JNIEnv* env, jobject thiz, jstring message) { const char* msg env-GetStringUTFChars(message, nullptr); // 拿到 std::string 后交给全局唯一的 BotEngine 实例 g_engine-sendMessage(msg ? msg : ); env-ReleaseStringUTFChars(message, msg); }iOS 的 ObjC 部分更直接新建一个 BotBridge.mm类的内部直接持有 C 的 BotEngine 指针方法实现里直接调用 C 函数。整套桥接代码量不大难的是回调需要从 C 工作线程切回 JS 主线程否则 UI 刷新会异常这一块后面单独说。3.5 线程模型与回调设计C 引擎的回调默认发生在自己的工作线程而 JS 层的 UI 操作必须跑到主线程。我们的事件路由设计简洁但严格所有从 core 发出去的事件只允许进入一个线程安全的事件队列JS 主线程每帧从队列里取事件并派发任何业务代码都不允许直接操作跨线程对象。同时JS 层调用 C 层的方法也尽量走异步。同步调用只用在 session 状态查询这类轻量只读操作上像发送消息、启动会话、切换音色这些耗时操作全部走异步回调避免主线程阻塞。4. 迁移实操从鸿蒙到双端的完整落地记录4.1 工程结构调整三层仓库怎么拆迁移第一步是把工程结构从“鸿蒙一锅烩”改成三层仓库。目录结构最终长这样repo/ ├── core/ # C 引擎纯平台无关 │ ├── include/ # 对外暴露的头文件 │ ├── src/ # 引擎源码 │ └── CMakeLists.txt # 独立构建单元 ├── platform/ │ ├── ios/ # iOS 工程与 ObjC 桥接 │ └── android/ # Android 工程与 JNI 桥接 ├── js/ │ ├── src/ # JS 业务层源码 │ ├── pages/ # 页面级组件 │ └── bridge/ # 与原生桥接的接口封装 └── scripts/ ├── build_android.sh └── build_ios.sh这个结构最核心的约束是依赖方向core 不能引用 platform 或 js 的任何东西js 只能通过桥接层接口调用 coreplatform 负责把两者拼起来。只要依赖方向不乱任何一层都能单独修改而不影响其他层。4.2 核心模块改造网络层、音视频流、AI 推理网络层是相对容易的一部分。鸿蒙版用的是 HarmonyOS 的 socket API 和 WebSocket 模块迁移到双端时统一重写成了标准 POSIX socket libwebsockets只依赖 C 标准库和少量第三方开源库。这样 iOS 和 Android 网络栈完全一致断线重连逻辑、心跳间隔、消息序列号这些行为不会出现平台差异。音视频流是第二块硬骨头。TTS 音频播放器在鸿蒙上依赖的是系统 AVPlayer迁移时我们做了一层抽象core 里定义 PlaybackProvider 接口iOS 用 AVFoundation 实现Android 用 ExoPlayer 实现。粗看像多写了一层代码实际上把上层业务逻辑和具体播放器解耦了后续如果要切换播放器内核比如换成自研播放器不会波及业务代码。AI 推理部分GroK Bot 上线初期主要走云端 API端侧只做轻量分类和关键词匹配用 C 直接实现不涉及深度学习框架。后续加了端侧意图识别后直接在 core 层接入 ONNX Runtime双端共用模型和推理逻辑这一块省下的时间甚至比 UI 迁移还多。4.3 关键配置与构建参数含示例build 配置里有几个参数直接影响包体积和性能这里记录一下我们最终采用的配置。Android 侧用 CMake 做交叉编译abiFilters 只保留 arm64-v8a放弃 32 位可以显著减小 APK 体积cmake_minimum_required(VERSION 3.22.1) project(grok_core LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 开启符号级裁剪配合 NDK 的 gc-sections 使用 add_compile_options(-ffunction-sections -fdata-sections -fvisibilityhidden) add_link_options(-Wl,--gc-sections) add_library(grok_core SHARED src/engine.cpp src/network.cpp src/audio.cpp ) # ONNX Runtime 等第三方库静态链接 target_link_libraries(grok_core onnxruntime libwebsockets openssl )iOS 侧在 Xcode 里需要把 Strip Style 设置为 All Symbols同时把 Dead Code Stripping 打开否则 C 模板展开带来的符号膨胀会让 Mach-O 体积多出不少。还有一个容易踩的点如果 core 里的某些导出函数只在 JNI 侧引用而编译器觉得没人调用会被优化掉需要在 Android 的 CMake 里保留特定符号列表。构建脚本统一用 CI 跑Android 是 Gradle 调 CMakeiOS 是 xcodebuild。我们约定所有产物都必须从 CI 出来不允许本地打包分发避免“在我机器上能编译”这种经典问题。4.4 性能对比数据与机型适配记录迁移完成后我们对几个核心指标做了压测数据是我们在测试机上的平均值仅供参考指标迁移前鸿蒙版迁移后 iOS迁移后 Android冷启动时间1.8s2.2s2.8s流式首字延迟1.0s1.1s1.2s对话列表滚动帧率60fps60fps55~60fps安装包体积32MB48MB39MBAndroid 的 2.8 秒里有一大部分花在系统组件初始化和 JNI 首次加载上后续版本通过启动时预加载 C 引擎和延迟初始化非必要模块压到了 2.4 秒左右。流式首字延迟和鸿蒙版基本持平核心原因是 C 引擎完全不经过跨语言重分发WebSocket 数据一到就直接进入 JS 层渲染链路上没有多余损耗。适配机型方面我们没有追求覆盖所有设备而是按渠道方要求和用户反馈圈定了 5 个重点机型包括某品牌旗舰机、某品牌中端机、某品牌千元机、某品牌折叠屏、某品牌影音向机型覆盖不同屏幕比例和性能档位。千元机上最容易暴露问题的是图像渲染和 TTS 播放同时跑时的卡顿后来通过对位图缓存和音频解码优先级做了调整才基本稳住。5. 踩坑实录迁移中我们修复的最难问题5.1 音频流在 Android 后台被杀的问题我们上线后收到的第一个严重反馈是Android 手机上用户锁屏后 GroK Bot 的 TTS 播到一半就停了有时候还会出现 App 直接被系统“杀掉”的情况。排查下来有两个叠加的原因一是没有申请前台服务权限后台播放音频时进程优先级不够二是音频焦点没有正确申请系统认为 App 在后台不应该继续占用声音通道。解决方法是双管齐下启动 TTS 时申请音频焦点并在播放开始后拉起前台服务通知栏显示常驻通知同时把播放状态写入系统媒体通知区域。这套方案能解决绝大多数 Android 后台音频问题但前提是权限声明要完整否则部分国内深度定制系统还是会限制后台行为。5.2 鸿蒙特有的 API 语义残留这个坑是我们自己埋下的。鸿蒙版早期用 TaskPool 做过一些并发处理迁移时把这种“任务调度”思维带进了 C 层结果在 Android 上出现了一个奇怪的死锁两个线程各自持有一个锁同时等待对方释放卡死概率约 30%只在特定网络波动时出现。排查了很久才定位到问题不是锁写错了而是线程数量过多导致优先级反转。鸿蒙的 TaskPool 体系会自动调节线程优先级C 里用裸 pthread 无法复现这套机制。解决方案是把 core 层所有并发逻辑收口到一个线程池管理器禁止业务代码自己创建线程并通过统一调度器控制任务优先级死锁现象彻底消失。5.3 包体积和启动时间的双指标拉锯包体积和启动时间一开始是互相打架的关系。如果把所有 TTS 资源、动态库、JS bundle 都打进包里安装包会膨胀到 80MB如果为了体积把资源放到云端冷启动就要先去下载启动时间反而变慢。最终采取折中方案核心语音包和引擎库打包进安装包备用语音包和更新包放云端延迟下载。CMake 开启 LTO 后core.so 体积从 14MB 降到了 9MBiOS 侧的 Mach-O 也通过符号裁剪瘦身了约 20%。代价是 LTO 链接时间变长CI 构建一次要多等两分钟但这个时间成本完全可以接受。5.4 同步桥接导致的臭名昭著的“秒退”还有一个非常经典的 JNI 崩溃我们差点没排查出来JS 层调用原生方法时如果不小心走了同步桥接在 Android 主线程上执行了耗时的 C 逻辑会导致 ANR但如果 C 逻辑内部触发了异常JNI 层没有正确捕获App 会直接“秒退”连崩溃日志都没有。解决方式是规定所有真正干活的接口必须走异步回掉同步桥接只允许做简单的 getter。同时封装一个全局异常捕获器在 JNI 的每个入口函数里都套上 try-catch保证任何 C 异常都不会穿透到 Java 层导致进程崩溃。这个经验虽然朴素但救了我们很多次。6. 常见问题速查如果你也要迁 CJMP6.1 为什么我编译不过CMake 版本与 NDK 版本匹配CJMP 的 Android 构建对 NDK 版本比较敏感。我们最初用 NDK 23编译时 C 标准库的一部分特性直接报错换到 NDK 25 之后一切正常。如果遇到“undefined reference to std::__1::...之类的错误先检查 NDK 版本而不是急着改代码。6.2 为什么 JS 层调用原生方法卡顿线程模型问题如果你发现 JS 层调用原生方法时界面卡顿首先怀疑是不是走了同步调用。C 引擎里任何带网络请求、音频解码、模型推理的接口都不允许同步执行必须在 JS 层封装成 Promise 或事件回调。我们内部的代码规范是bridge 层只暴露异步方法所有返回值都通过回调传递UI 线程只会被轻量 setter 同步调用。6.3 为什么包体积大开启符号级裁剪如果你发现 Android 包体积异常大大概率是没有正确开启符号裁剪。CMake 里加上-ffunction-sections -fdata-sections -Wl,--gc-sections再配合-fvisibilityhidden通常能省掉 20% 到 30% 的 so 体积。iOS 侧确保 Strip Style 为 All Symbols同时检查 Pods 里是否残留了模拟器架构的二进制那会白白增加不少体积。6.4 CJMP 适合什么项目不适合什么项目适合 CJMP 的项目有几个共同点核心能力集中在网络、音视频、算法等重逻辑上团队拥有可复用的 C 资产UI 复杂度不高且对热更新有强需求。典型场景包括 AI 对话产品、音频工具、IoT 控制端、数据采集类工具。不适合的项目也有明显特征以炫酷界面和复杂动效为核心卖点的应用比如泛娱乐直播里的礼物特效、资讯类 App 的复杂排版这些场景用 CJMP 去硬碰 UI 表现力会很痛苦不如选择成熟的自绘渲染框架。另一个不适合的情况是团队完全没有 C 背景虽然可以用但桥接层的每一个问题都会变成高风险排查项学习曲线会很陡。6.5 启动速度优化还有哪些切入点除了预加载 C 引擎JNI 首次调用的痛点在 Android 上非常明显。我们用一个技巧把首字延迟降低了约 200ms在 App 启动早期先在一个空闲线程里调用一次 BotEngine 的空初始化和销毁把 JNI 注册和类加载提前完成等用户真正进入对话时第一次跨语言调用就不会再触发完整的 JNI 初始化。另外JS 引擎的启动时间也是大头。我们没有使用完整版 JS 引擎而是启用了字节码缓存和延迟编译策略把首屏页面需要的部分提前编译其他页面模块按需加载冷启动时间又缩短了一截。迁移告一段落后回头看最难的从来不是怎么写 C 或者怎么调 JNI而是团队能不能守住 core 层零平台依赖这条红线同时愿意为统一的底层主线长期投入。CJMP 不是那种开箱即用的通用框架它更像是一套骨架你把自己的核心逻辑放进去它才能在两个平台上给你一致的体验。我们后续计划把本地端侧检索和离线技能包继续往下压深度这套分层结构应该还能撑很久。如果你也在做类似的 AI 产品迁移希望这篇复盘能帮你少走几步弯路。