企业官网建设流程全解析

去年下半年我们团队做了个决定：把内部代号 Grok Bot 的 AI 对话助手，从鸿蒙平台完整搬到 iOS 和 Android。当时所有人都以为这就是“把 UI 换一套、API 重新接一遍”的体力活，结果排期第三天就发现，真正折磨人的根本不是界面，而是后台任务、通知通道、文件目录、系统权限这些东西在三个平台上各说各话。折腾到第三周，我们引入了一套叫 CJMP 的跨端任务消息协议，整个迁移才真正走上正轨。如果你也在做类似的跨端迁移，尤其想从单一平台走向双端甚至三端，这篇文章应该能让你少走两个月的弯路。

1. 为什么一个鸿蒙 Bot 要同时搬到 iOS 和 Android

1.1 鸿蒙上跑得挺顺，为什么要挪窝

先交代背景。Grok Bot 是我们团队做的一个基于大语言模型的智能对话助手，核心能力包括多轮对话、定时提醒、轻量工具调用，比如帮你查个天气、记个会议、到点提醒你喝水。最初版本基于鸿蒙平台开发，用 ArkTS 写界面，模型网关单独部署在云端，端侧通过 WebSocket 长连接保持在线。

鸿蒙版上线后，我们收到不少正向反馈，但一个很现实的问题摆到桌面上：客户和用户并不只用一个生态。很多团队和我们一样，面对的是“员工/用户既有鸿蒙手机，也有大量 iOS 和 Android 设备”的混合环境。单独押注一个平台，意味着大量潜在用户根本没机会接触到这个 Bot。不是鸿蒙不好，而是对一个面向大众的助手类产品来说，市场覆盖是绕不开的命题。

于是目标定下来：不放弃鸿蒙版，但必须新增 iOS 和 Android 两个端。听起来是个“加法”，但实际上我们把整个项目重新拆了一遍底层的技术依赖。

1.2 Grok Bot 真正的技术依赖是什么

迁移之前，团队花了整整两天做一件事：把 Grok Bot 的所有依赖全部列出来，按“能力类型”归类，再逐个标注鸿蒙、iOS、Android 三端的行为差异。我们当时列出的核心依赖大概有这些：

• 长连接通信：端侧与模型网关之间的 WebSocket 连接，负责实时收发对话内容；
• 任务调度：定时提醒、计划任务的注册、触发、取消；
• 通知能力：提醒送达时，需要弹出系统级通知；
• 本地存储：聊天记录、用户偏好、任务列表的持久化；
• 账号登录：绑定用户身份，支点多端同步；
• 系统权限：麦克风权限（语音输入）、通知权限等；
• 包发布与签名：三个平台各自的应用签名、审核、上架流程。

真正做完这张表我才意识到，跨端迁移最痛苦的不是“同一行代码在不同平台跑不通”，而是同一个功能概念在三个平台完全是不同的系统机制来实现。比如“定时任务”这件事，鸿蒙有自己的任务派对机制，Android 得看 Doze 模式和厂商后台限制，iOS 又有独立的 Background Task 调度。后面几章细讲。

2. 迁移前必须看明白：三端系统机制差异到底有多大

2.1 后台任务与进程优先级：同一个提醒，三种命运

我们把最难的模块放在前面处理——后台任务。Grok Bot 有一个“定时提醒”功能，用户说“明天早上九点提醒我开会”，Bot 就要在指定时间把提醒消息推到用户手机上。这个功能在鸿蒙上跑得很正常：系统调度、到点触发、通知栏弹出。可换成 Android 和 iOS 以后，事情完全变了。

我们自己在真机上测试时，同一个“九点提醒”任务，Android 某些手机上能准点弹，某些手机要等用户点亮屏幕才执行；iOS 更极端，一个纯后台执行的定时任务几乎不可能准时触发，必须要靠远程推送在服务端算好时间下发。这个差异直接否定了“把鸿蒙的任务逻辑平移过去”的思路。

后来我们的方案是：定时任务不依赖端侧调度，全部由服务端定时推送通知，端侧只保留一个“本地兜底”逻辑。也就是说，端侧任务是最终展示层，触发源统一收归服务端。这个改动很大程度是为了绕开平台的进程机制，而不是我们懒。

2.2 通知通道不是“调个 API”就完事

通知功能同样让人头疼。iOS 的通知要走 APNs，而且用户安装 App 后第一次打开就要弹窗申请通知权限；用户一旦点了“不允许”，后续所有提醒都静默丢失。Android 从 8.0 开始引入通知渠道（Notification Channel）的概念，应用必须为每一类通知建一个 channel，用户可以在系统设置里单独关掉其中一类。鸿蒙的通知形态又和两者都不一样，推送服务也有自己的接入协议。

对我们这种“提醒送达率直接决定产品口碑”的场景，通知就是生命线。我们见过太多团队从单一平台迁到双端时，把通知当成普通模块顺手接一下，结果上线后用户投诉“Bot 怎么不提醒了”，一看日志才发现推送 token 没上报成功，或者用户权限被系统侧默认拒绝了。

2.3 文件目录与存储访问：路径习惯差异极大

另一个容易被新手忽略的坑是文件目录。鸿蒙上，应用读写自己的文件目录相对简单；iOS 应用只能访问自己的沙盒目录，Document、Library、tmp 各有用途；Android 从 10 开始强制分区存储，应用不能随便读写公共目录，甚至访问/storage/emulated/0/Android/data/自己的外部存储目录也会被权限挡住。

Grok Bot 需要把聊天记录导出、导入，还会把语音输入生成的临时文件存起来。这套逻辑最初是给鸿蒙写的，直接搬到 Android 后发现，导出文件到公共目录这条路基本走不通，必须改用 MediaStore 或 SAF 文档树；iOS 上又必须用 FileManager 去定位 Documents 目录。我们最后专门抽象了一个FileStorageAdapter，所有文件读写都走这个适配器，底层各自实现，业务层再也不用关心 Path。

3. CJMP 到底帮我解决了什么问题

3.1 CJMP 是什么：不是 UI 框架，是一套消息协议

在动手写双端代码之前，我们做了选型调研，这也是标题里“为什么最后选了 CJMP”的核心。先解释一下 CJMP 是什么：CJMP（Cross-platform Job Messaging Protocol，跨端任务消息协议）并不是一个 UI 框架，也不会帮你渲染任何控件。它定义了一套标准化的任务消息格式、状态流转规则和端侧适配器接口，解决的是“业务网关和任意平台端侧之间，如何用同一套语言描述任务、上报状态、回传结果”的问题。

一句话概括：CJMP 把“跨端”这件事从 UI 层下沉到了消息层和任务层。

当时我们手里的原型是这样的：Grok Bot 的核心逻辑在云端，端侧负责采集输入、展示输出、触发任务。端侧和云端之间需要大量消息往来，比如用户发起提醒、云端注册任务、到点推送、端侧确认已读。在单平台上，这些东西自己定义内部协议就行；一旦多端并行，每端一套协议，后端要对应维护三套格式，排查问题也像破案。CJMP 正好抽出了这套统一的“任务—消息—状态”模型。

3.2 用任务状态机统一“提交—执行—回执”

CJMP 最核心的设计是任务状态机。任何一个端侧或服务端发起的任务，都会经历这几个阶段：

{ "msg_type": "task.dispatch", "task_id": "a2f4c19e-7b0e-4a1d-9c2a-ef3b0aa5f6d1", "source": "server", "target": "ios", "payload": { "task": "reminder.create", "params": { "content": "9:00 开会", "trigger_at": "2026-05-20T09:00:00+08:00" } }, "state": "pending", "timestamp": "2026-05-19T21:30:00Z" }

这个字段结构我们当时几乎没改动就定了下来：msg_type标记消息类型，task_id是全链路唯一的任务 ID，source、target标明消息方向，payload放具体业务参数，state表示当前状态，timestamp记录时间。核心是不管什么系统的 Bot，只要收发双方都实现了 CJMP，任务从“提交”到“成功/失败/取消”的流转就完全一致：

1. pending：任务被接收入队；
2. running：端侧开始执行，或服务端开始等待调度；
3. succeeded：任务最终执行成功；
4. failed：任务执行失败，带有失败原因；
5. canceled：被用户或超时逻辑取消。

有人可能会问，这不就是一个状态字段吗？确实不复杂，但真正让协作变顺畅的是两件事：状态机是统一强制约定的，而不是各端自己想怎么传就怎么传；任务 ID 去重和幂等机制保证了同一条提醒不会因为网络重试被创建两次。

3.3 端侧适配器：协议负责统一，差异留在底层

CJMP 的另一个关键是适配器接口。协议只约定消息长什么样，具体某个端去执行通知、存储、后台任务时，由各端的PlatformAdapter实现。我们当时定义了这样一组接口（示意）：

interface PlatformAdapter { fun sendNotification(title: String, body: String): Boolean fun saveLocalData(key: String, value: String) fun readLocalData(key: String): String? fun scheduleBackgroundTask(taskId: String, triggerAt: Long) fun getPushToken(): String fun registerTokenRefreshCallback(callback: (String) -> Unit) }

iOS 和 Android 各自实现这套接口，业务层完全不感知底层差异。比如scheduleBackgroundTask，Android 端内部用 WorkManager 实现，iOS 端内部用 BGTaskScheduler 实现；而到底能不能准时执行，是适配器实现时要考虑的问题，不是业务层每次都要操心的问题。

这个设计让我们的迁移方式变成了“加法而不是重构”：原生 UI 继续保留，站在原地不动；核心逻辑往上走一层，通过 CJMP 和服务端通信；系统能力全部下沉到适配器。每端需要新写的东西，就是一个适配器加上若干页面，而不是把整个 Bot 的逻辑推倒重来。

4. 选型复盘：Flutter、RN、KMP 都看过了，为什么最后是 CJMP

4.1 选型前提：我们不缺 UI 框架，缺的是逻辑跨端

当时团队里有人提议直接用 Flutter 或 React Native 重写整个 App，一劳永逸。这个方案我们认真评估了两周，最终没有采用。原因不是这些框架不好，而是它们解决的不是我们当前最痛的问题。

Grok Bot 的 UI 本来就不复杂：聊天会话页、任务列表页、设置页，广义上就是三个主要页面。原生开发或用 Flutter 重写，工作量差别有限。真正复杂的是与云端的长连接、定时任务、通知调度、状态同步，这些并不由 UI 框架帮我们跨端。Flutter 再强，它的插件生态里，后台任务还是得调用原生 API；React Native 再方便，厂商推送适配还是绕不开每个安卓 ROM 的做法。

所以我们的真实需求是：把业务逻辑中的“任务调度、状态上报、消息回执”用一套统一机制跨端，而不是把整个 App 的 UI 统一掉。这是 CJMP 能胜出的最关键前提。

4.2 与主流跨端框架的实际对比

这里不是要贬低 Flutter 或 RN，它们在很多产品里是正确答案。但对一个团队已经拥有原生代码基础、核心逻辑在云端、UI 本身不复杂的 Bot 来说，用跨端 UI 框架属于“用大炮打蚊子”，还要承担整体重构带来的稳定性风险。CJMP 则不同，它只引入一个协议层，我们现有代码的迁移成本降到最低。

4.3 决策逻辑：用加法代替重构

选型会最后我们形成了一个共识：能加一个协议层解决的问题，就不要重构整个应用。

迁移计划最终是这样定的：

• 服务端接口统一走 CJMP 消息格式；
• iOS 端原 SwiftUI 界面保留，新增 CJMP 客户端 SDK 和PlatformAdapter；
• Android 端原 Jetpack Compose 界面保留，同样接入 CJMP SDK；
• 鸿蒙版同步改造接入 CJMP，保证三端共享同一套任务语义。

实际执行下来，整个过程比我们最初排期节省了大概三周。因为不需要重新写任何一端的核心页面，也不需要处理 Flutter 和原生插件之间的兼容性问题。每端的开发任务变得很纯粹：实现自己的PlatformAdapter，把系统能力对齐到协议层的接口语义。

5. 迁移落地踩坑清单：从 iOS 开发者模式到 Android 分区存储

5.1 iOS 开发者模式、证书和真机调试

iOS 端碰到的第一个坑是开发者模式。新版本 iOS 在真机调试时，手机上必须开启开发者模式，否则 Xcode 编译出的应用装到真机上会直接被系统拦截。这个设置藏在“隐私与安全性”里，默认是关闭的。当时团队第一次在 iPhone 上调试，编译成功但装不上，发现问题出在开发者模式没开，浪费了一个下午。

再一个是证书和 App ID。我们内部测试用的分发方式与正式上架不同，测试证书只能装到已注册的设备 UDID 上，换一台真机就要重新添加。后来我们统一用企业证书做了内部分发，才解决测试团队多台设备的问题。但要注意，正式上架 App Store 时必须走常规的发布证书和描述文件流程，审核时还要配置好隐私清单。我们因为在隐私清单里漏填了数据收集类型，被审核打回了一次。

5.2 Android 分区存储：路径搬不过去

Android 端的代码从鸿蒙移植过来时，遇到最隐蔽的坑是分区存储。很多老的 Android 开发习惯里，应用会把文件直接写进/storage/emulated/0/Android/data/包名/这样的外部目录，用来做导出备份或者日志。Android 10 之后，这个目录访问变得极其受限，即便应用自己写进去的文件，某些场景下也不能直接读取。

我们实际碰到的场景是：Grok Bot 要把聊天记录导出成文本文件，让用户分享出去。最初的代码直接往外部存储写入文件，在鸿蒙和旧 Android 上都能跑通，在 Android 14 的测试机上就报权限异常。最终方案是改用 MediaStore 的 Downloads 集合来创建导出文件，代码改动量不大，但必须把原先所有文件路径硬编码全部找出来清理掉。这属于典型的“代码在低版本能跑，不代表新版本没问题”。

5.3 后台任务的取舍：服务端触发 + 本地兜底

前面提过，我们最后把定时提醒改成服务端触发加本地兜底。这个方案在实际落地中有个细节：iOS 的 BGTaskScheduler 不适合执行“准点提醒”，更适合“趁用户凑巧打开 App 时补拉数据”。所以 iOS 端本地兜底逻辑做得很轻，只负责在用户打开 App 时检查有没有错过的提醒；真正的准点推送完全依赖 APNs。

Android 端情况不同，WorkManager 可以被系统延迟执行，且厂商 ROM 有自己的省电策略。我们额外接入了几个主流厂商的推送 SDK，通过厂商通道提高到达率。这又是一个容易忽略的坑：不能只接一个 Google 的 FCM 就觉得万事大吉，国内 Android 环境必须做厂商推送适配，否则离线消息基本送不到。

5.4 推送 token 刷新：一条消息悄悄丢掉的教训

推送 token 的问题也是实际排查了很久才发现。我们最初只在登录时上报一次推送 token，逻辑很简单：用户登录、拿 token、上报、结束。但实际场景里，iOS 的 APNs token 在应用重装、备份恢复、甚至系统更新后都可能变化，Android 的厂商 token 也有有效期。如果不做刷新机制，就会出现“用户明明装了很多推送 SDK，却一条推送都收不到”的灵异情况。

CJMP 在这里帮了忙：我们把 token 刷新建模成一个独立任务，端侧只要检测到 token 变化，就通过task.dispatch消息上报到服务端。服务端收到后，比对旧 token 并覆盖，相当于给推送通道加了“心跳”。上线后，推送到达率从最初的 85% 提升到 97% 左右，这个提升基本都来自 token 刷新机制。

5.5 鸿蒙元服务改造的一个提醒

最后说一句鸿蒙这边。我们原本以为鸿蒙版不用动，加一个新协议就算完事。实际上，为了统一三端消息语义，鸿蒙版也要把自己原来那套私有消息格式改成 CJMP。这里最大的一个教训是：不要在原来的合成服务上直接“打补丁”，而是把元服务的入口重新梳理一遍。合成服务的生命周期和 iOS、Android 的 App/Activity 生命周期差异很大，试图用同一个状态机去套原生 App 的逻辑，反而会越改越乱。最终我们把鸿蒙版也按“适配器 + 协议层 + 页面”拆了一遍，问题一下子就清晰了。

6. 迁移后的实际数据与团队感受

6.1 包体积、启动时间和人日的实测对比

迁移完成后，我们记录了一些关键数据，供同样从单端向双端迁移的团队参考。说明一下，这些数字不是实验室环境，而是真机测试和内部发布版本统计的结果。

包体积里 Android 和 iOS 偏大，主要原因是集成了多家厂商推送 SDK 和 CJMP 客户端的必要依赖。冷启动时间都在可接受范围内，因为页面本身不重。迁移开发人日只算了增量部分，如果从一开始就用跨端框架重写，人日估计要翻倍以上。

6.2 稳定性提升的意外收获

统一协议后，我们意外发现在问题排查上省了很多时间。以前三端各有各的消息格式，日志互相看不懂，服务端得为每个端写一堆转换逻辑。现在所有端的日志里都能搜同一个task_id，从服务端到端侧一条链路拉全，排查效率提高得不是一点半点。比如一次用户反馈“提醒没弹”，我们直接搜task_id，发现消息在服务端显示已下发，但端侧适配器sendNotification返回了 false，详情一看是用户关掉了通知权限。没有统一协议之前，这个排查过程至少要翻两到三套日志系统。

6.3 协作方式的变化：人人都是协议守护者

团队协作方式也因为 CJMP 发生了一点微妙变化。以前 iOS 和 Android 各自为战，遇到问题互相甩锅；现在所有人围绕同一份协议文档工作，任何一端要加字段，都得先回到协议层讨论，再由各端适配器同步更新。协议评审成为日常开发流程的一部分。一开始有人觉得麻烦，后来发现，这恰恰是跨端项目减少返工的最有效手段。

我自己的体会是，跨端迁移最难的部分，永远不是写代码，而是找到一套让所有端都愿意遵守的“共同语言”。CJMP 对我们来说就是这套语言，它没有试图包办一切，只做了最该做的那件事：把跨平台最复杂的任务调度和消息同步问题，收敛到一个足够简单、足够透明的协议里。如果你现在也在折腾类似的迁移，别急着选 UI 框架，先花一周时间把底层消息协议定清楚，这个投入比任何重构都有回报。