Flutter for OpenHarmony智慧养老App交通服务开发实践

1. 项目背景与需求拆解：为什么交通服务是智慧养老App里最硬的骨头

接触 Flutter for OpenHarmony 的智慧养老App项目时，我本来以为最大的难点在"跨端适配"或者"鸿蒙生态不成熟"上。真正动手以后才发现，交通服务模块才是整个App里最考验工程能力的一块。挂号、缴费、健康档案这些功能都是App内闭环，用户点几下就能完成，但交通服务完全不同——它涉及真实世界的位置、时间、网络波动、天气变化，还涉及老人面对突发状况时的应对能力。

先说一个我在需求调研阶段印象很深的场景。有位社区负责人告诉我，他们试过给老人装网约车App，结果发现老人连"确认上车点"这个步骤都容易误触，更别提在高峰期手动输入目的地。老人经常把"儿子家"说成"那个路口往里走的地方"，这种口语化地址根本没法直接变成地图坐标。所以交通模块的功能设计，不是把高德或百度地图抄一遍，而是要把出行链条拆碎，重新按老人的认知习惯组装。

我当时把需求拆成了五个优先层级，这是和产品、社区运营反复碰过的结果：

1. 一键出发：首页放常用地点大卡片，点一下直接进入路线规划，不需要手动输入起点终点。
2. 实时公交：能看附近站点、线路、下一班还有几分钟，比等导航路线优先级更高。
3. 大字版路线指引：明确告诉老人"坐几路、在哪站下、大概走多少米"，而不是甩一张复杂路线图。
4. 亲情守护：子女可以远程查看老人实时位置，设定电子围栏，老人走出范围自动通知。
5. 语音播报：关键节点用语音提醒，弥补老人看不清屏幕的问题。

为什么选 Flutter for OpenHarmony 这条路，而不是纯OpenHarmony原生开发？原因有三。第一，养老类项目往往不是只为一个系统做的，Android设备、鸿蒙设备、未来可能的iOS设备都要覆盖，Flutter一套代码能省掉很大一部分维护成本。第二，适老化UI需要高度定制，Flutter的自绘渲染机制可以保证同一套视觉逻辑在所有平台上完全一致，不依赖系统控件风格。第三，OpenHarmony生态还在成长期，Flutter社区的插件和工具链相对更成熟一些，遇到问题能参考的资料更多。

当然，这条路并不好走。OpenHarmony上的Flutter SDK不是官方主分支维护的，而是OpenHarmony SIG 团队在维护，版本更新节奏和Flutter官方不完全同步，很多Android上随手可用的插件在OpenHarmony上需要自己补平台通道。这些坑我在后面会详细展开。

1.1 老年用户出行的真实痛点清单

做适老化App最忌讳的一点，就是坐在办公室里凭空想象老人"应该需要什么"。我把调研中收集到的真实痛点整理成了一张清单，这张清单直接决定了我后面功能模块的优先级：

这张表做出来之后，整个交通服务模块的开发方向就清楚了：不是做一个完整的导航App，而是做一个"帮老人安全出门"的轻量工具。功能可以少，但每个功能必须可靠、可感知、可兜底。

1.2 功能边界与模块划分

基于上面的痛点清单，我把交通服务模块划分成了四个子模块：

• 公交服务：附近站点查询、线路到站时间、收藏线路。
• 路线规划：一键到家/一键去医院、公交/步行混合路线、步骤列表式大字展示。
• 安全守护：实时位置共享、电子围栏、异常提醒。
• 语音辅助：操作引导语音、路线播报、来电报读（这个后来因为权限问题砍掉了，原因后面说）。

每个子模块内部再细分状态机，比如公交查询要处理"正在刷新""无网络""无数据""加载成功"四种状态。这些状态不是随手写的，而是我在测试时发现老人经常会对着一个一直转圈的按钮干等，他们不会主动去下拉刷新，也不会返回重进。所以所有异步操作都必须有明确的超时机制和自动重试策略，这是适老化App和普通App一个很本质的区别。

1.3 为什么现在就要上OpenHarmony

有的人可能会问，OpenHarmony生态还不成熟，为什么要在这个时间点做投入？我的看法是，智慧养老是一个典型的B端带动C端的场景，社区、养老院、政府项目采购设备时，成本和安全可控性往往比生态丰富度更优先。OpenHarmony设备在价格和可控性上有明显优势，而且这类项目一旦落地就是持续好几年的运维关系，现在进场积累技术经验，恰恰能吃到窗口期红利。

Flutter for OpenHarmony 正好是这两者的结合点。Flutter负责跨端一致性和开发效率，OpenHarmony负责提供国产可控的硬件底座。我在选型时也对比过 React Native for OpenHarmony，但仔细看下来，Flutter的渲染引擎是自绘的，不依赖原生控件，在OpenHarmony这种控件体系和Android有差异的系统上，一致性的保障更彻底。后面的事实也证明这个判断基本正确——至少在UI层，我几乎没有为OpenHarmony单独写过样式。

2. 环境搭建与工程初始化：先踩平编译期的拦路虎

这一节我专门讲环境搭建，因为很多人在 OpenHarmony 上跑 Flutter 项目，第一步就被环境劝退了。我自己也在这上面折腾了两天，把报错一个个记录下来，这里直接给结论。

2.1 Flutter for OpenHarmony SDK 的获取与版本对应

OpenHarmony 的 Flutter SDK 不在 Flutter 官方仓库，而在 OpenHarmony SIG 维护的 flutter_flutter 仓库。安装时最容易犯的错，就是直接去 flutter 官网下标准版 Flutter SDK，然后照着鸿蒙的文档跑——这样在 flutter doctor 阶段就过不去，因为标准 SDK 根本不认识 ohos 平台。

我用的版本组合给你参考：

配置完环境变量后，记得检查一下 flutter doctor -v 能否识别 ohos 工具链。我一开始没装 DevEco Studio 的 command li