Flutter on OpenHarmony：家庭药箱管理App开发实战与踩坑记录

我家里药箱的乱象应该是很多家庭的缩影：感冒药、降压药、创可贴、维生素全堆在一起，每次找药都要翻半天，月底偶尔还能翻出一两盒过期的。市面上确实有不少用药管理App，但大多要注册账号、绑定手机号、云端同步，对一台摆在家里、只服务一家人的OpenHarmony设备来说根本没必要。所以我干脆用Flutter写了一个家庭药箱管理App，目标平台就是OpenHarmony，所有数据都留在本地，打开即用，不用联网。

这个项目做下来最大的感触是：Flutter跨平台那套思路，在OpenHarmony上真的走得通。如果你有Flutter基础，又正好需要在OpenHarmony设备上快速落地一个业务清晰、体验扎实的工具类应用，这条路线非常值得试。下面把环境配置、核心功能拆解、设置页实现和真机调试过程完整记录下来，尤其是设置功能里那几个容易翻车的细节，希望能帮想试水的人少走弯路。

1. Flutter与OpenHarmony的缘分：为什么用这套组合做药箱App

1.1 OpenHarmony应用开发的另一条路

大部分人在OpenHarmony上做应用开发，第一个接触到的是一整套DevEco Studio加ArkTS加ArkUI的组合。这套东西确实成熟，声明式UI写起来也顺手，官方文档和示例都挺全。但我自己已经有两年多的Flutter经验，手头一堆现成的Dart代码和pub依赖，接到这个家庭药箱管理App需求时，第一个念头就是：能不能直接用Flutter跑在OpenHarmony上，把跨平台能力复用过来。

结论是可以。Flutter官方仓库里一直保留着对OpenHarmony的适配分支，社区迭代速度比想象中快，pub.dev上大量纯Dart包可以直接使用，UI层面仍然是Widget那一套，迁移成本远低于换一套语言和框架。选择这条路的逻辑其实不复杂：在ArkTS和Flutter之间做选择，本质上不是哪个技术更好，而是哪个更贴近你现有的团队积累和应用场景。ArkTS原生性能更直接，系统能力调用更省事，但如果你已经有Flutter版本的业务代码，或者团队主力技能就是Flutter，那用Flutter跑OpenHarmony，能省下至少一半的开发维护成本。

1.2 为什么恰恰是“家庭药箱”这个场景

选这个场景不是随手拍脑袋。一个药箱管理App要处理的核心问题无非几件事：药快过期了要知道、药吃完了要及时补、按医嘱按时吃。它天然就是本地优先的工具型应用，不涉及复杂服务端，不需要登录注册，数据量也小。这样我在验证Flutter on OpenHarmony的过程中，能把精力集中在界面交互、数据持久化、调度提醒这些真正体现跨平台能力的点上，而不是被业务复杂性拖住。

同时，药箱App的功能骨架刚好覆盖了移动应用最常见的几种形态：列表页、详情页、表单页、设置页，以及定时任务。尤其是设置页，几乎汇集了所有“全局状态管理”的典型问题：主题切换、开关状态、参数修改、跨页联动。把这些做明白了，一个App的架子基本就立住了。所以这篇文章会把设置功能的实现单独拿出来详细拆，它算是整个项目里最值得反复推敲的部分。

1.3 项目整体架构与目录结构

项目采用标准Flutter分层结构，UI层全部用Dart写，数据层通过插件访问本地SQLite，通知通过本地通知插件实现，设置项存储在shared_preferences。目录结构上，models放实体类，providers放状态管理，pages放页面，services放业务服务，utils放工具函数。ohos目录是OpenHarmony平台壳，包含module.json5、资源和原生构建配置。

技术选型如下表：

2. 环境搭建：把Flutter的OpenHarmony工具链装好跑通

2.1 需要准备的物料清单

实际搭建时，需要的工具比普通Flutter环境多几样：OpenHa