这段时间我一直在折腾一个比较偏门的组合:用 Flutter 开发 OpenHarmony 上的电子合同签署 App。听上去好像没啥特别的,但真正动手做 API 集成的时候才发现,这里面的坑远比想象中多。这篇文章把我在实战中踩过的坑、验证过的方案、以及最终跑通的实现路径整理出来,特别是 API 集成这一块,给后面想做同类跨端 App 的朋友一个参考。
开头先交代一下背景。电子合同签署这个业务,核心流程无非是:用户注册实名认证、发起签署、查看合同、确认签署、签署完成。但放到 OpenHarmony 这个新生态里,事情就没那么简单了。OpenHarmony 起步阶段,原生生态的第三方 SDK 数量和成熟度比不上 Android,而 Flutter 虽然能做到跨平台,但要调用鸿蒙系统的底层能力,就必须走 platform channel 桥接。这个项目的核心难点,就是在 Flutter 层把业务逻辑跟 UI 全部跑通,同时通过桥接层调起鸿蒙底层的能力,再跟后端的合同服务 API 做数据交换。
如果你正准备在 OpenHarmony 上做 Flutter 开发,特别是涉及用户登录、实名认证、合同文件上传下载这类重度依赖 API 和系统能力的场景,这篇文章值得收藏。
1. 内容整体设计与思路拆解
1.1 为什么在 OpenHarmony 上选 Flutter 而不是 ArkTS
这个项目最早做技术选型的时候,团队内部是有过激烈讨论的。OpenHarmony 官方主推的是 ArkTS + ArkUI 原生开发,理论上性能和系统能力调用最直接。但问题在于,团队里大部分人之前都是做 Flutter 的,如果全部转向 ArkTS,学习成本是一方面,最要命的是时间成本——原本两周能交付的东西,可能要拖到一个半月。
用 Flutter 的另一个决定性因素,是业务形态。电子合同签名这个 App,未来大概率要覆盖 Android、iOS、Windows、OpenHarmony 多个平台,不可能每个平台都搞一套原生实现。用 Flutter 做跨端,UI 层和业务逻辑层可以一套代码到处跑,只需要针对 OpenHarmony 做平台桥接适配。
从实际验证结果看,Flutter 在 OpenHarmony 上的表现是够用的。我用的是 Flutter 3.7.12 版本搭配 OpenHarmony 4.1 Release,开发框架选的是 OpenHarmony Flutter SDK 社区维护版,日常操作和页面跳转的流畅度跟原生差距不大。当然,如果你做的App对性能要求极其苛刻,比如大量 3D 渲染,那 Flutter 方案可能不是最优解,但对于合同签署这种偏表单和文档操作的业务,Flutter 完全能扛住。
1.2 API 集成方案的选型逻辑
API 集成这块,我一开始想过用官方推荐的 http 包,简单直接。但合同签署这个业务它不是简单的增删改查,涉及到的 API 调用场景非常复杂,比如:
- 实名认证需要上传身份证正反面照片,文件流上传;
- 合同发起需要提交模板 ID 和签署方信息,同时关联多个参与方;
- 签署状态需要轮询或者长连接实时刷新;
- 下载合同文件可能面对几百兆的大文件;
- 所有请求都要带 token,且 token 过期需要自动刷新。
这些需求叠加在一起,http 包的抽象层级太低,做拦截器、全局错误处理、token 刷新这些功能都得自己造轮子。我最终选了 dio,它内置了拦截器、请求取消、文件上传下载进度、连接超时控制,做这种重 API 依赖的业务能省掉一大半的底层工作。
数据格式方面,后端接口统一走 RESTful JSON。关于这一点我多说一句:如果你能控制后端接口设计,强烈建议所有接口的 response 都包装成统一格式,比如 { code, message, data },这样前端做全局拦截和错误提示会非常顺手。我这个项目的后端虽然也是自研的,但一开始没做统一包装,导致我在前端处理了三种不同的返回结构,浪费了不少时间去兼容。
1.3 整体架构分层与模块划分
这是我最想强调的部分。用 Flutter 开发 OpenHarmony 应用,架构分层是否清晰,直接决定你在 API 集成阶段是轻松还是崩溃。
我的项目架构长这样:
- UI 层:Flutter Widget 构建,负责合同列表、签署页面、实名认证页面的展示;
- 业务逻辑层:用 Provider 做状态管理,处理登录态、签署流程状态、轮询逻辑;
- API 服务层:dio 实例封装,统一的请求入口,处理 token 注入和错误码映射;
- 数据模型层:JSON 序列化和反序列化,
fromJson/toJson手动写,或者用json_serializable生成; - 平台桥接层:MethodChannel 调鸿蒙原生能力,比如获取设备唯一标识、调用系统相机拍照、使用安全存储。
每个模块职责单一,层与层之间通过接口通信。这样做的好处是,API 集成的时候你只需要关注 API 服务层和数据模型层,UI 和业务逻辑基本不用动。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 合同签署 API 的数据模型设计
电子合同签署,核心对象就是"合同"和"签署行为"。我在设计数据模型的时候,参照了行业内比较成熟的电子合同平台的数据结构,再针对自己的业务做了一些裁剪。
合同(Contract)模型的字段设计:
contractId:合同唯一标识,后端生成,UUID 格式;contractName:合同名称,用户可读;templateId:模板ID,对应后端的合同模板;signStatus:签署状态(见下文状态机);- `init
