Flutter+OpenHarmony智慧养老应用系统设置模块开发实践

1. 项目背景与系统设置的模块定位

1.1 为什么是Flutter + OpenHarmony

先聊聊这个项目是怎么来的。智慧养老这个方向，说白了就是给老年用户做一套能用、愿意用的终端应用。但在实际落地时，第一个卡住团队的问题不是业务逻辑，而是“这套App到底跑在什么设备上”。养老场景里常见的是智能大屏、机顶盒、带屏音箱、健康一体机，这些设备的操作系统五花八门，如果每个平台都单独做原生开发，后续维护成本直接翻倍。

选择Flutter for OpenHarmony，最核心的原因是“一次编写，多端运行”。团队原本就有Flutter的开发经验，而OpenHarmony生态的设备这两年在家电、安防、适老改造领域增长得很快。与其等生态完全成熟再进场，不如先把Flutter在OpenHarmony上的坑趟一遍。这个项目的目标明确：在OpenHarmony设备上跑起一套包含健康数据、消息提醒、系统设置三大模块的养老App，其中系统设置模块是最能验证“跨端能力”的部分，因为它在交互、权限、存储、通知等多个维度都有覆盖。

1.2 系统设置模块在养老App里的定位

很多人觉得系统设置不就是几个开关加一个列表页吗？真正上手之后才发现，这个模块是整个App里最容易做“糙”的部分。老年用户的典型使用场景是：看不清楚字、容易误触、需要依赖语音或大字体、对权限和通知的感知特别弱。所以这个系统设置模块不是给极客用的，而是给家里长辈用的，它的定位应该是“把复杂的技术决策藏起来，只给用户最简单的选择”。

功能上划分成几个子模块：个人信息维护（监护人联系方式、紧急联系人）、健康数据管理（心率、血压的测量单位与提醒阈值）、通知与提醒设置（服药提醒、异常告警）、显示与无障碍设置（字体大小、语音播报开关、屏幕常亮）、关于设备（系统版本、存储空间清理）。这些功能在普通App里就是一堆输入框和开关，但在OpenHarmony + Flutter的体系下，每一项都要考虑原生能力的对接，尤其是路由、权限、存储和通知服务。

这个模块的另一个重要职责是“兜底”。老人的设备如果出现异常，比如蓝牙断连、网络不通、字体被误调成超大，系统设置页应该是用户第一个能找回安全感的地方。所以在设计上我会刻意把“恢复默认设置”“一键呼叫帮助”这类入口放在更显眼的位置，而不是藏在列表深处。

2. 开发环境搭建与工程配置

2.1 OpenHarmony SDK与Flutter SDK的版本匹配

先说环境。Flutter for OpenHarmony目前并不是Flutter官方主线直接支持的，而是基于OpenHarmony的flutter_flutter仓库fork版本。初次接触这个组合的人最容易在这步耽误时间，因为版本匹配是一个“牵一发动全身”的问题。

我的建议是直接使用OpenHarmony官方推荐的SDK组合。以当前比较稳定的版本为例，OpenHarmony SDK选择4.0 Release或更新的5.0版本，Flutter SDK使用OpenHarmony分支的3.7.x或3.10.x版本。这里有个关键点：不要用Flutter官方主线的SDK去尝试编译OpenHarmony工程，那会直接报错。因为OpenHarmony分支的Flutter引擎层做了平台通道的替换，把原来对接Android/iOS的embedder改成了对接OpenHarmony的ACE（Ability Cross-platform Environment）框架。

安装完成后，记得检查环境变量。我在macOS上配置时，需要把ohos-sdk的toolchain路径加到PATH中，同时在local.properties里指定ohosSdk目录。如果路径不对，构建时只会报一个模糊的错误，比如“Unable to locate Ohos SDK”，这时候先别急着重装，检查路径是不是写对了。

注意：Flutter for OpenHarmony的构建产物是HAP包，不是APK。所以你的Flutter工程里除了pubspec.yaml，还需要一个build-profile.json5文件来配置签名和模块信息。这部分很多人会漏掉。

2.2 创建Flutter工程并切换到OpenHarmony平台

工程创建这一步相对简单，可以用flutter create命令生成一个标准的Flutter工程，但生成完之后需要做两件事：一是添加ohos目录，二是修改模块配置。

实际上，OpenHarmony分支的flutter create命令已经支持ohos平台。执行时直接指定：

code复制flutter create --platforms=ohos my_app

这样会生成带ohos平台的工程结构。如果你用默认命令生成后再手动加ohos目录，会麻烦一些，因为需要自己写module.json5和build-profile.json5。

不过我这里有个建议：头一次跑通整个流程，最好先用官方仓库里自带的example工程验证环境，而不是直接拿业务工程去试。原因很简单，example工程里的依赖版本、Gradle配置、签名文件都是对齐好的，只要它能跑起来，说明环境没问题。我当初图省事，直接用业务代码去调环境，结果分不清是代码问题还是环境问题，排查耗时翻了三倍。

配置好之后，执行flutter build hap --debug构建调试包。第一次构建会下载大量Gradle依赖，这个过程的耗时取决于网络状况，建议预留半小时以上。遇到Gradle下载慢的情况，可以手动配置Gradle镜像仓库，但这里不展开讲代理配置，只提一句：在build-profile.json5里可以指定国内镜像源，能明显提升下载速度。

2.3 热重载与调试工具链

Flutter开发最爽的就是热重载，这个特性在OpenHarmony上也是支持的，但前提是使用OpenHarmony分支的Flutter工具链。启动调试的方式是：

code复制flutter run -d <device_id>

设备ID可以通过flutter devices查看。OpenHarmony设备连接后，会显示为ohos类型。热重载的快捷键（r键）和官方Flutter保持一致，但实测在OpenHarmony上热重载的稳定性不如Android，尤其涉及平台通道修改时，偶尔会失效，这时候老老实实执行R键冷重启，不要浪费时间反复触发热重载。

调试日志我推荐用OpenHarmony自带的hilog工具，它比adb logcat的过滤方式更适合鸿蒙系统。查看Flutter相关日志的过滤命令是：

code复制hilog | grep flutter

另外，DevEco Studio集成的Profiler工具能查看引擎层的帧渲染耗时，对排查卡顿问题非常有帮助。在养老设备这类低配硬件上，这个工具几乎是必备的，后面讲性能优化时还会再提。

3. 系统设置模块的页面结构与核心组件

3.1 整体导航与页面路由设计

系统设置模块虽然功能多，但在页面组织上要遵循“少层级、大触控”的原则。老年用户几乎没有“面包屑导航”