瑜妩1. 项目背景与设计思考
我一直觉得“家庭药箱”这个场景特别适合做成跨端应用。家里药箱里的药，品类多、效期乱、偶尔还会出现“药还没吃完就过期”的情况，记录需求是真实存在的。正好那段时间我在用 Flutter 做跨端项目，手头又有一块 OpenHarmony 开发板，就想着把 Flutter 应用搬到 OpenHarmony 上跑一遍，于是就有了这个 flutter_for_openharmony 家庭药箱管理 App。
这个项目的完整形态可以概括为：用 Flutter 编写业务代码和 UI，通过社区适配层打包成 OpenHarmony 应用，最后在开发板上运行，核心功能覆盖药品入库、效期预警、用药提醒，以及一个完整的设置功能模块。如果你正在做类似方向——不管是想了解 Flutter 在 OpenHarmony 上能跑成什么样，还是准备开发一款家庭健康管理类应用，这篇内容都值得看完。
1.1 家庭药箱到底需要哪些能力
先不急着写代码，把需求理清楚。家庭药箱管理如果只做“药品名称+过期日期”的表格，用 Excel 就够了，做成 App 的价值在于实时性和提醒能力。我在需求分析阶段整理出的功能点如下：
- 药品信息管理：名称、规格、剂型、用途、用法用量、总数量、剩余数量、生产日期、有效期、备注。
- 效期状态识别：区分正常、临期、已过期三种状态，并在列表页直观展示。
- 定时提醒：按药品设置用药提醒，或者按家庭成员设置每日固定提醒。
- 数据导出：把药箱数据导出成 JSON 文件，方便备份或者迁移。
- 设置模块：通知总开关、默认提醒时间、主题模式切换、缓存清理、关于页面。
这里我想多说一句：家庭药箱应用最核心的体验不是“录入”，而是“提醒”。很多用户录完一次药品之后，可能一个月都不会再打开 App，真正触达用户的点在于临期提醒和用药提醒。所以设计的时候一定要把通知能力放到优先级最高的位置，而不是把精力都花在列表动画上。
1.2 为什么选择 Flutter 对接 OpenHarmony
选技术方案的时候我对比过两条路：一条是用 ArkTS + ArkUI 原生开发 OpenHarmony 应用，另一条是走 Flutter 适配层。我当时没有直接选 ArkTS，原因很现实：
- 团队里 Flutter 的代码资产最多，现成的状态管理、路由、UI 组件体系可以直接复用。
- Flutter 是自绘引擎，UI 在 Android、iOS、OpenHarmony 上的一致性很好，界面不会因为底层系统差异走样。
- Dart 生态对本地存储、JSON 处理、文件读写场景足够成熟，开发效率比从零写 ArkTS 要高。
Flutter 对接 OpenHarmony 的适配链路，目前主要是 OpenHarmony 社区维护的 flutter_flutter 分支，里面包含了 OpenHarmony 平台侧的 Runner 工程。这套适配不是把 Flutter 当作 WebView 去套壳，而是真正把 Flutter 引擎跑在 OpenHarmony 系统上，Dart 层代码通过 Platform Channel 调用 OpenHarmony 的能力。
当然，选 Flutter 也有代价。OpenHarmony 适配层的插件生态没有 Android 那么全，部分插件无法直接使用，需要自己写平台通道，或者换成纯 Dart 实现的第三方库。这个我心里有预期，所以项目规划时给适配预留了时间。
1.3 技术选型的取舍
如果你也在犹豫要不要用 Flutter 做 OpenHarmony 应用，我建议按这个逻辑判断：
- 如果应用强依赖系统级能力，比如蓝牙、NFC、USB、传感器这类硬件接口，就需要先查一下 OpenHarmony 侧 Platform Channel 有没有现成实现。社区没覆盖的话，自研成本不低。
- 如果应用只是常规界面 + 数据存储 + 网络请求，Flutter 的适配风险很小，可以放心用。
- 如果团队已经有 Flutter 开发经验，那更不建议轻易推到 ArkTS 重写。一套代码可多端运行的价值，在家庭药箱这类工具型应用里能明显体现出来。
我这个项目的系统能力依赖主要是本地通知、文件读写、偏好设置存储，这三块在 OpenHarmony 上都有可用的适配方案，所以整体选型是成立的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境搭建与工程结构
2.1 OpenHarmony 环境与 Flutter 适配层
先讲环境配置。OpenHarmony 的 Flutter 适配目前以社区维护为主，常见的做法是直接拉 flutter_flutter 的 OpenHarmony 分支，而不是用 pub.dev 上默认的 Flutter SDK。默认 SDK 不包含 OpenHarmony 平台目标，创建工程时不会生成 ohos 目录。
我使用的版本组合可以参考：
| 组件 | 版本说明 |
|---|---|
| Flutter SDK | 社区 OpenHarmony 适配分支（基于 3.x 版本线） |
| OpenHarmony SDK | 4.0 Release，API 9 及以上 |
| DevEco Studio | 用于编译 ohos 工程并导出 HAP 包 |
| hdc 工具 | 连接开发板、查看日志、安装应用 |
编译链路大致是：Dart 代码经过 Flutter 引擎，映射到 OpenHarmony 平台层，最终由 DevEco Studio 编译成 HAP 包安装到设备上。需要特别注意的是，OpenHarmony 的 Flutter 工程最终是通过 DevEco Studio 打开 ohos 目录来构建的，不是直接跑 flutter run 就能在开发板上看到效果。
2.2 工程初始化
我的初始化步骤记录如下，方便直接照着操作：
bash复制# 拉取 OpenHarmony 适配版 Flutter SDK
git clone -b dev_oh_flutter https://gitee.com/openharmony-sig/flutter_flutter.git
# 配置 PATH
export PATH=$PWD/flutter_flutter/bin:$PATH
# 检查环境
flutter doctor
flutter doctor 会输出 Flutter 基础状态，但 OpenHarmony 平台不会被自动识别，需要手动确认工程里有 ohos