我最近把一个健康档案管理系统的“快速入口”搬到了 OpenHarmony 设备上,整套 UI 和业务逻辑全部用 Flutter 写完,再通过社区维护的 OpenHarmony 分支跑通真机。整体项目不算复杂,但里面涉及环境搭建、跨端能力桥接、设备适配和一堆“文档里根本不会写”的坑,值得单独整理一篇实战记录。如果你也在评估 Flutter 能不能做 OpenHarmony 应用,或者已经准备上手但卡在环境或运行环节,这篇文章应该能帮你少走不少弯路。
先说结论:Flutter 做 OpenHarmony 应用目前可行,但远没有到“开箱即用”的程度。它能带来一套 Dart 代码同时覆盖 Android、iOS、OpenHarmony 甚至桌面端的收益,代价是你需要接受非官方分支带来的版本延迟、部分插件不可用、以及调试工具链不完整的现实。对于健康档案这类对 UI 一致性要求高、需要快速迭代但又没有极其复杂系统能力的应用,这个组合反而非常合适。下面我会从项目定位讲起,逐步展开环境配置、核心页面实现、原生能力调用和一系列踩坑经验。
1. 项目在做什么:健康档案快速入口与跨端口标
1.1 这个项目最想解决的三个问题
先明确“快速入口”不是完整健康档案系统。实际业务里,完整系统包含个人信息、历次就诊记录、检验报告列表、用药计划、医生排班等一大堆模块,用户的手机不可能被所有低频操作占据。很多人打开一个健康类 App,核心诉求就是:看最近一次报告、记着按时吃药、知道自己下次复查时间。所以我这个快速入口只做三件事:把跟当前用户最相关的健康摘要聚合到首页,把高频使用功能做成一键卡片,再预留一个可跳转完整档案系统的路由。
第二要解决的问题是终端碎片化。健康档案类应用经常需要跑在医生手持终端、护士站平板、患者自己的 Android 手机上,甚至有项目会把触屏一体机纳入范围。如果每个设备都写一套原生界面,人力成本直接翻好几倍。引入 Flutter 之后,Dart 代码在这些终端上渲染的像素级效果几乎一致,唯一要适配的就是屏幕尺寸和交互方式。
第三是可维护性。OpenHarmony 自身的 ArkUI 声明式语法学习成本并不低,而且它目前还不能让一套代码反向跑到 Android/iOS 上。相比之下 Flutter 的生态、组件库和社区问答都非常成熟,大部分业务团队招到一个 Flutter 工程师就能同时维护多个端,这个优势在当前资源普遍紧张的项目环境里非常有吸引力。
1.2 为什么是 Flutter × OpenHarmony,而不是 ArkUI 或 Android 原生
我见过一些团队的方案是“Android 一套,OpenHarmony 再招人用 ArkUI 重写一套”。这样做 UI 能做得非常原生,性能也很好,但代价是双倍测试成本、双倍埋点成本和长期维护中两个端的交互不一致。健康档案应用恰恰对一致性有要求:同一份电子病历展示在 Android 和 OpenHarmony 设备上,如果出现字号、间距、字段顺序不一样,医护工作者很容易误读。
另一个备选是 ArkUI 跨端方案。ArkUI 的声明式写法和 Flutter 有不少相似之处,但它的生态目前主要服务 OpenHarmony 产品,想把它跑到 Android/iOS 上基本还是要套一层 WebView 壳。如果业务的上线范围主要是“OpenHarmony + Android”组合,Flutter 在当前阶段是相对均衡的选择:它拥有成熟的跨端社区,又有 OpenHarmony SIG 在持续适配引擎和插件。
不过要诚实说一句:Flutter 官方至今没有把 OpenHarmony 列入正式支持列表,这意味着你不能直接 flutter create 一个官方模板就万事大吉。我这里用的是 OpenHarmony 社区维护的 flutter_flutter 和 flutter_packages 仓库,属于“跟随分支但滞后于官方版本”的模式。做项目前一定要和团队打好招呼:线上如果出现 Flutter 版本升级带来的问题,处理优先级永远低于官方支持的 Android/iOS 构建。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备:让 Flutter 能跑到 OpenHarmony 上
2.1 安装 Flutter SDK 时最容易耽误时间的几个点
先装 Flutter SDK,这个步骤和普通 Flutter 开发完全一样。下载压缩包后解压,把 bin 目录加进 PATH。如果是 macOS 或者 Linux,建议顺手做一次国内镜像配置,否则后续拉起 pub 依赖时经常等很久甚至失败。配置方法是在 shell 环境里加入两行:
bash复制export PUB_HOSTED_URL=https://pub.flutter-io.cn
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn
网上很多教程会让你把这行写进 ~/.bashrc,但不少人改完直接在当前终端跑 flutter --version,发现没有任何变化。不是配置没写对,而是当前终端没有重新加载配置文件。执行 source ~/.bashrc,或者干脆新开一个终端窗口,再跑 flutter doctor 就正常了。这个细节看起来很小,实际能把很多刚入门的人卡住十几分钟。
安装完后用 flutter doctor 检查环境。注意如果你只做 OpenHarmony 开发,Flutter 官方 doctor 可能不会显示 OpenHarmony 工具链状态,别慌。接下来要准备 OpenHarmony 的 SDK 和 IDE,主要路径是通过 DevEco Studio 下载,也可以直接用命令行 SDK 包。我建议把 DevEco Studio 安装好,因为后面查看日志、签名、打包都要用到它的配套工具。
2.2 搭建一个能同时编译 Android 和 OpenHarmony 的 Flutter 工程
OpenHarmony 对 Flutter 的支持并不是直接集成在官方 Flutter 仓库的 stable 分支里,而是由 OpenHarmony SIG 维护了一套独立的 flutter_florch、flutter_packages 和 flutter_samples。实际操作前,你需要先确定要用的 OpenHarmony SDK 版本,然后切到 flutter_flutter 仓库中对应的分支。
有一个常见的误区是下载了官方 Flutter SDK,然后直接拿 OpenHarmony 的 flutter_packages 去执行 flutter pub get。如果版本基准相差太远,编译时会报一堆莫名其妙的符号缺失或 C++ 编译错误。尽量把 Flutter、OpenHarmony SDK、Flutter Packages 三者的基准版本对齐,通常的做法是:去 Gitee 上找 openharmony-sig 组织下的 flutter_flutter 仓库,查看 README 中推荐的
