这两个月我一直在折腾一个用 Flutter 写的 OpenHarmony 家庭药箱管理 App中间还加了血压记录模块。起因很简单家里老人常备药有好几盒有的快过期了也没人知道血压记录本写得密密麻麻但要看出趋势变化却难得很。于是我想着与其等着哪天吃错药或者血压波动没被注意到不如直接自己做一个工具来管这件事。选 Flutter 是因为我本来就更熟 Dart 生态而 OpenHarmony 这边正好也需要一个跨端快速落地的方案两个一凑项目就这么开始了。这篇文章我不打算讲太多虚的直接把整个项目的需求拆分、技术选型、核心实现、踩坑过程都拆开给你看。内容涉及药品库存管理、过期提醒、用药定时、血压记录与趋势图表以及 Flutter 在 OpenHarmony 上最常见的那些坑——组件通信、异步机制、平台通道、渲染引擎兼容性等等。如果你正打算用 Flutter 做 OpenHarmony 应用或者手头刚好有类似的家庭健康类工具需求这篇文章里的工程方案和代码逻辑可以直接抄作业能帮你少走不少弯路。1. 项目背景与整体方案设计1.1 为什么选 Flutter OpenHarmony先说说技术选型的来龙去脉。OpenHarmony 是当前国内关注度很高的开源操作系统应用生态正在快速建设但相比 Android 和 iOS它的原生应用开发门槛还是偏高尤其是如果你的目标用户有多个设备、多个系统版本纯原生开发的人力成本会一直上涨。而 Flutter 的优势在于一套代码多端跑UI 层完全自绘渲染不依赖系统原生控件这个特性放到 OpenHarmony 上其实非常关键因为 OpenHarmony 的控件体系还在不断演进自绘引擎反而能帮我们规避一部分原生控件不一致的坑。当然选择 Flutter 也不只是因为 UI 层。我在这个项目里要处理的是家庭健康场景逻辑复杂度集中在业务层和数据层比如药品到期预警、血压趋势统计、用药提醒调度这些跟平台耦合度很低用 Dart 来写没有任何问题。再加上 Flutter 生态里已经有很多成熟的库下拉刷新、图表绘制、本地数据库、日期选择器这些东西都有现成的轮子比在 OpenHarmony 上从零写原生页面轻松太多。不过必须说清楚目前 Flutter 对 OpenHarmony 的支持并不是官方默认就集成好的需要借助 OpenHarmony 社区维护的 Flutter 分支来构建引擎和运行环境。社区方案已经能跑通大部分场景但像 native 插件、平台视图、相机调用这些还是会遇到兼容性问题。这个项目我是在功能选型上有意识地避开了过度依赖原生能力的部分把核心逻辑放在 Flutter 侧原生侧只保留通知和少量交互能力这也是后面项目整体进度没有卡死的重要原因之一。1.2 家庭药箱 血压记录的功能规划家庭药箱管理这个需求乍一看很简单但真正拆开之后就发现细节不少。我这里按照家里人实际使用的场景来规划功能最后收敛成四块核心能力。第一块是药品信息管理包括药品名称、分类、规格、剂量、剩余库存、存放位置、生产批号和有效期。药品分类我分成了常备药、处方药、外用药、儿童药和保健品几类方便后续做分类过滤和用药提醒的差异化处理。库存字段要区分整盒数和拆零余量不然就会出现“盒子里还剩两片但系统显示库存1盒”这种和实际脱节的情况。第二块是有效期和库存预警。药品过期是个刚需我默认提前 60 天开始提示提前 7 天加强提醒过期药会在列表顶部高亮拦截。同时库存低于设定阈值时也要提示补药不然提示过期却有药、提示补药却发现家里还有一抽屉就会很尴尬。第三块是用药提醒。家里人每天要吃的药种类不多但时间点很固定所以我没有做特别复杂的时间表引擎就是简单的“早/中/晚/睡前”四个时段配置配合每日重复的提醒计划。这一块后期牵涉到重启后提醒恢复的问题后面讲实操的时候会单独说。第四块是血压记录。记录包含收缩压、舒张压、心率、测量时间和备注信息额外支持按成员维度分开记录。数据展示方面我用折线图展示最近 30 天或者自定义时间段的收缩压和舒张压趋势并标出正常范围参考线。血压记录和用药提醒之间没有做联动因为目前医学上建议个性化的血压管理和用药调整要有医生参与作为一个家庭工具我把重点放到了记录和可视化上避免给出不专业的建议。1.3 技术选型与架构拆分技术栈方面Flutter 版本我用的社区 OpenHarmony 分支Dart 相关状态管理选择了 Provider没有一上来就上 Bloc 或者 Riverpod。家用工具类 App 的页面复杂度不算高Provider 的写法足够直白团队成员接手也容易不必要为了架构炫技增加理解成本。数据库用的是 sqflite 的 OpenHarmony 兼容实现虽然 OpenHarmony 官方有分布式数据管理服务但考虑到单机场景为主、多设备协同是加分项而不是必选项我暂时先用本地 SQLite等后续需要支持多设备同步再切分布式数据库也不迟。图标库选择了社区常见的 Material 风格图标绘图部分用了 fl_chart这个库的折线图性能表现不错自定义程度也够血压趋势图需要的参考线、点击高亮这些功能基本都覆盖了。页面跳转用系统内置的 Navigator 2.0 简版没有引入额外的路由框架因为页面总量八个左右路由管理自己用 Map 维护反而更可控。后端我直接放弃了。家庭场景不需要账号系统数据全部存在本地后续如果需要备份或者家庭成员间共享数据再考虑接云同步。这个决定让整个项目的网络权限为零也趁机躲开了大量安全和合规的坑而且对 OpenHarmony 应用的审核来说权限越少越有利。架构上我分成了三层UI 层负责页面展示和交互业务层放药品管理、血压记录、提醒调度这些核心逻辑数据层负责本地数据库读写。组件之间通过 Provider 消息通知来做状态同步底层数据变更统一走数据层接口避免出现多个页面各自维护一份数据副本的经典混乱场景。2. 核心功能预测与实际拆解2.1 药品管理从录入到过期提醒药品信息的录入表单是整个项目最普通的开发工作但是数据模型设计直接影响后面所有功能的复杂度。药品字段我最终定成下面这组。class Medicine { final int id; final String name; final String categoryKey; // otc / rx / external / child / supplement final String spec; // 规格比如 0.25g*24片 final String dose; // 用法用量描述 final int stockBox; // 整盒数量 final int stockPill; // 拆零余量 final DateTime? expiresAt; // 有效期截止日 final String location; // 存放位置比如客厅药柜第二层 final String? remark; }为什么要把拿药逻辑封装到业务层因为库存操作不只有“录入”这一种场景还有“吃药消耗”。每次记录用药后系统默认自动扣除库存扣除顺序是先扣拆零余量余量不够再扣一整盒。这个逻辑如果散落在各页面里后面一定会出现数据对不上的问题我在第一版就是这样结果三天后药品库存就变成负数了。过期提醒我用的是一个定时器加列表扫描的方案。每天打开 App 或者切换前台时扫描一次数据库把 60 天内到期、7 天内到期、已过期三个档位的药品数量统计出来放到首页顶部的提醒卡片里。同时用药提醒的每日计划里会额外插入一条“检查过期药”的通知任务双重保险确保不会漏看。值得提醒的是有效期的录入一定要设计成支持“盒子上只写了年份月份”的情况所以我在日期选择上有两个模式精确到日和仅精确到月。精确到日时直接用年月日仅精确到月时默认取当月最后一天作为过期日这样在计算剩余天数时会更保守对健康场景来说宁可提前提醒也不能压线。2.2 血压记录从表单到趋势图血压记录是这个项目里第二个核心模块也是用户体验最容易做砸的部分。测量血压本身流程就多用户很可能是睡眼惺忪坐在血压计旁边打开 App如果录入表单复杂到要输入五次才能完成那基本就弃用了。所以我把血压录入设计成了一个尽量傻瓜化的表单收缩压、舒张压、心率三个数字输入框默认带上一个适合大多数人的基础判断即根据基本常识判断记录是否在合理范围内超出正常值范围时用颜色给出轻度提示但不打断输入流程。测量时间默认取当前时刻但也支持手动修改方便用户补录之前漏记的数据。血压数据模型大概是这样的class BloodPressureRecord { final int id; final String memberId; final int systolic; // 收缩压 mmHg final int diastolic; // 舒张压 mmHg final int pulse; // 心率 bpm final DateTime measuredAt; final String? note; }趋势图部分我用了 fl_chart 的 LineChart。横轴是时间纵轴是血压值分别画两条折线代表收缩压和舒张压同时画了一条浅灰色的参考区域代表“正常血压”分区。这里有一个细节要提参考线的位置不是随政策走的而是在代码里用常量维护方便未来调整。血压数据量较少时折线图会显得很稀疏我做了个优化当时间跨度较大时自动切换为柱状平均值的显示方式按周聚合数据这样图表看起来更平滑。还有一个很容易被忽略的问题不同家庭成员的血压数据务必分开存储。哪怕目前你只管家里一个人模型上也应该预留 memberId 字段。我见过不少一开始没留成员维度的小工具后来加多用户支持时等于重构了一遍那个成本比一开始就加字段高出好几倍。2.3 组件通信与状态管理组件通信是 Flutter 开发中永远绕不开的话题也是这个项目里一开始让我踩了不少坑的地方。Flutter 的组件通信大体分三类父子组件之间用构造参数和回调、跨层级祖先组件用 InheritedWidget 或者 Provider、完全解耦的模块之间用事件总线或者 Stream。在这个家庭药箱 App 里我大部分通信是跨页面的所以直接选择了 Provider。为什么不用 InheritedWidget 硬写因为 Context 的嵌套一多读数据时容易一不留神拿到错误的父级实例。Provider 本质上是对 InheritedWidget 的封装解决了泛型数据读取的问题同时配合 ChangeNotifier 很容易实现页面局部刷新。具体到项目里我用三个顶层 Provider 来拆解业务MedicationProvider 负责药品的增删改查和库存变动BloodPressureProvider 负责血压记录的新增和查询ReminderProvider 负责用药提醒的启停和状态同步。还有一个值得单独讲的通信场景是首页和子页面之间的联动。首页要显示库存和血压摘要点击摘要卡片又会跳转到详情页而详情页里的修改操作要反向刷新首页数据。我的做法是在 Provider 里统一维护一个版本号字段增删改操作都走数据层的方法并在方法内部调用 notifyListeners。首页通过监听这个 Provider 的 version 变化来自动刷新摘要数据避免靠手动回传参数这种脆弱写法。至于那种更解耦的模块间通信比如吃药提醒触发后要同时更新库存和统计记录我用了 Flutter 的 StreamController 做了一个事件总线。提醒触发 - 库存扣除 - 通知刷新这一条链路在两个 Provider 之间来回拉扯有点丑用总线发一个“用药完成”事件让两个 Provider 各自响应反而清爽很多。3. 实操过程与关键代码复现3.1 OpenHarmony 环境搭建与工程初始化环境搭建是真的劝退了不少人。OpenHarmony 上跑 Flutter 目前没有一键式集成方案走的是一个“OpenHarmony 主工程 Flutter module”的混合工程模式。我当时的步骤如下每一步都踩出来了按这个顺序大概率一次能通。第一步准备 OpenHarmony SDK 和 DevEco Studio。下载 OpenHarmony SDK 后在 DevEco Studio 里配置好 SDK 路径并新建一个 empty ability 的工程作为宿主应用。这一步注意 OpenHarmony SDK 的版本要和你的设备系统版本匹配不匹配的话后面签名和安装都会出问题。第二步拉取 Flutter 的 OpenHarmony 分支。社区维护的仓库地址是 flutter_flutter 的 openharmony 版本我用的稳定分支。配置好环境变量后用这个分支的 flutter 命令创建 module。git clone https://gitee.com/openharmony-sig/flutter_flutter.git cd flutter_flutter git checkout 3.7.12-ohos # 也可以选其他版本注意和文档保持一致 export PATH$PWD/bin:$PATH flutter --version第三步创建 Flutter module。OpenHarmony 的 Flutter 集成方式和 Android 很像先 flutter create 生成一个 module 工程然后在 DevEco Studio 的宿主工程里添加依赖关系让宿主工程能够引用 Flutter module 生成的产物。flutter create --templatemodule --platformsohos medicine_box_flutter这里有个坑--platforms 参数要写 ohos如果不写默认生成的工程是不含 OpenHarmony 平台目录的后面集成时就会找不到 Flutter 引擎包。第四步在宿主工程的 build 配置里引入 Flutter module 的产物路径然后进行首次编译。编译过程中会下载 OpenHarmony 平台相关的依赖网络状况不佳的时候很容易卡在 Gradle 或者 hvigor 这一步建议第一次编译时找个网络稳定的环境一口气跑完。工程初始化这一个环节我前前后后折腾了两天左右大部分时间都耗在版本匹配上。如果你也遇到“新建项目后跑不起来”的问题大概率就是 SDK 版本、Flutter 分支版本、DevEco Studio 版本这三者没有对齐。我的建议是先确认 OpenHarmony 设备系统版本再反向去查该版本推荐使用的 Flutter 分支不要一上来就拉最新主干。3.2 数据库设计与数据层实现数据库我沿用 sqflite 的封装思路但在 OpenHarmony 上要注意插件版本。社区已经发布过兼容 OpenHarmony 的 sqflite 实现安装时指定对应版本即可否则会在运行时报 MissingPluginException。表结构设计上我实际建了三张表medicine、blood_pressure、reminder_plan。medicine 表对应药品模型关键是给 expiry_date 和 stock 字段建好索引因为过期提醒和库存查询都是高频操作。blood_pressure 表按 member_id 和时间字段建联合索引。reminder_plan 表记录每个成员的药品提醒计划包含时段、药品 id、是否启用等字段。class DatabaseHelper { static final DatabaseHelper _instance DatabaseHelper._(); DatabaseHelper._(); FutureDatabase get database async { return openDatabase( medicine_box.db, version: 1, onCreate: (db, version) async { await db.execute( CREATE TABLE medicine ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, category_key TEXT, spec TEXT, dose TEXT, stock_box INTEGER DEFAULT 0, stock_pill INTEGER DEFAULT 0, expiry_date TEXT, location TEXT, remark TEXT ) ); await db.execute( CREATE TABLE blood_pressure ( id INTEGER PRIMARY KEY AUTOINCREMENT, member_id TEXT NOT NULL, systolic INTEGER NOT NULL, diastolic INTEGER NOT NULL, pulse INTEGER, measured_at TEXT NOT NULL, note TEXT ) ); }, ); } }实现单例模式的数据库帮助类所有数据访问都走这一层避免多页面各自开着数据库连接最后文件锁冲突。实际开发中我确实发现过在 OpenHarmony 上 sqflite 对并发连接处理得不太稳串行复用单连接是最可靠的做法。库存扣除这个操作跨了药品和提醒两张表我用了一个事务来保证一致性顺序是先插入或用药记录再扣减库存最后更新提醒计划状态。如果中途异常回滚后提醒不会重复触发库存也不会被重复扣减。3.3 提醒通知与平台通道用药提醒是药箱 App 差异化的核心痛点。App 在前台的时候用 Flutter 内部的 Timer 就能实现倒计时提醒但切到后台尤其是进程被杀之后Timer 就失效了必须依赖 OpenHarmony 侧的计划任务能力把提醒“托管”给系统。这就涉及 Flutter 和 OpenHarmony 之间的平台通道。我在 Flutter 侧定义了一个 MethodChannel让 Dart 调用原生侧的能力注册定时提醒。具体做法是在原生 Ability 里用 OpenHarmony 的 reminderAgentManager 创建定时提醒传过去提醒内容、触发时间、重复规则这些参数。class ReminderBridge { static const MethodChannel _channel MethodChannel(medicine_box/reminder); static Futurebool scheduleReminder({ required int reminderId, required String title, required String content, required DateTime triggerTime, }) async { try { return await _channel.invokeMethod(scheduleReminder, { id: reminderId, title: title, content: content, triggerTime: triggerTime.millisecondsSinceEpoch, }); } on PlatformException catch (e) { debugPrint(schedule reminder failed: ${e.message}); return false; } } }平台通道是 Flutter 和 OpenHarmony 之间的桥但它在 UI 线程上执行所以像这种需要注册系统服务的调用量不大还行一旦涉及耗时的原生操作就一定要在原生侧起子线程不能在主线程里阻塞。这个我在 OpenHarmony 侧是用 AsyncCall 机制来处理的。另外Flutter 的 PlatformView 在 OpenHarmony 上也是可用的但兼容性和性能都还在完善中。我在项目里原本想用 PlatformView 嵌一个原生相机扫药品条码后来实测发现渲染性能不理想而且生命周期回调在部分系统版本上会出现错乱最终我放弃了原生相机方案改用 Flutter 侧做一个简易的手动条码输入入口。如果你是做更复杂的混合界面建议提前在目标设备上做 PlatformView 压测不要等集成完才发现卡顿严重。3.4 页面实现与血压图表代码页面部分我挑两个最有代表性的讲一个是首页的药箱盘点页另一个是血压趋势页。药箱首页的核心是一个药品列表但跟普通列表不同它要处理库存状态和过期状态的视觉区分。我用 Flutter 的 RefreshIndicator 做下拉刷新配合自定义的 ListView 实现按过期状态分组。每组开头显示一个摘要统计条比如“已过期 2 种”、“30 天内到期 3 种”、“库存充足 12 种”。过期判断写到数据层避免在前端到处写日期比较逻辑。ExpiryStatus getExpiryStatus(Medicine medicine) { if (medicine.expiresAt null) return ExpiryStatus.none; final days medicine.expiresAt!.difference(DateTime.now()).inDays; if (days 0) return ExpiryStatus.expired; if (days 7) return ExpiryStatus.soon; if (days 30) return ExpiryStatus.warning; return ExpiryStatus.normal; }血压趋势页的图表我用 fl_chart 的 LineChart 来实现。这里有一个放在实际代码里的关键点折线图数据量比较小的时候不要把每条记录直接变成一个点否则图会像锯齿一样扎眼睛。我选择在数据层做时间窗口聚合比如按天取平均值然后传给图表组件。以下是核心配置片段LineChartData buildChartData(ListBloodPressureRecord records) { final spots records .map((r) FlSpot( r.measuredAt.millisecondsSinceEpoch.toDouble(), r.systolic.toDouble(), )) .toList(); return LineChartData( minX: spots.first.x, maxX: spots.last.x, minY: 60, maxY: 180, lineBarsData: [ LineChartBarData( spots: spots, color: Color(0xFFE53935), barWidth: 2, isCurved: true, belowBarData: BarAreaData(show: true, color: Color(0x20E53935)), ), ], titlesData: FlTitlesData( leftTitles: AxisTitles( sideTitles: SideTitles(showTitles: true, reservedSize: 32), ), bottomTitles: AxisTitles( sideTitles: SideTitles(showTitles: true, reservedSize: 32), ), ), ); }看这段代码你会发现我没有直接把 List 塞进 FlSpot中间多了一层数据转换。这个转换层解决了一件事血压记录测量时可能因为运动或不规范操作产生明显异常值如果不加过滤直接画出来趋势就会被个别极端数据带偏。我在转换层里加了中位数滤波把偏离周围记录 50 mmHg 以上的点剔除或修正。这个过滤逻辑放在 UI 之前也方便加单元测试。3.5 渲染引擎与性能调优Flutter 在这个项目里用到的新渲染引擎也值得一提。Impeller 是 Flutter 为了替代 Skia 而推的渲染引擎主要解决 Skia 在跨平台渲染时的 shader 编译卡顿问题。在 OpenHarmony 上跑的那些 Flutter 版本目前大多还是 Skia 为主Impeller 的支持要看具体的社区分支状态。我实测下来在中等配置的 OpenHarmony 设备上列表页滚动和图表页面渲染还算是跟手的但如果你一屏铺满大量复杂组件比如同时显示动画、阴影和半透明遮罩帧率会明显掉下来。我的优化手段有三个列表项尽量使用 const 构造、图片开启缓存并统一压缩尺寸、图表在页面不可见时暂停重绘。最后一个尤其重要血压趋势页如果你在 PageView 里左右滑动fl_chart 是会继续重绘的在不可见页面上这是纯浪费我通过对 PageView 的页面生命周期监听来暂停图表重绘效果立竿见影。4. 常见问题与排查经验4.1 运行时未处理异常怎么定位运行阶段印象最深的报错是 Flutter 在 OpenHarmony 上的未处理异常日志长这样E/flutter (31173): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(error, ...)这个报错最让人难受的地方在于它只告诉你有一个未处理异常但崩溃 stack 往往不完整甚至不指向你的实际业务代码。要定位这类问题我的习惯是打开 Flutter 的 debug 模式同时开启系统日志过滤把 Dart 层和原生层的日志同时看。这里有一个非常实用的做法在 Dart 顶层用 Zone 捕获所有未处理异常然后统一记录并上报到自己的日志系统。void main() { runZonedGuarded(() { runApp(const MedicineBoxApp()); }, (error, stackTrace) { debugPrint(unhandled error: $error); debugPrint(stackTrace: $stackTrace); // 持久化到本地日志表方便App内查看 }); }项目里遇到的未处理异常一半以上是平台通道抛出的 PlatformException比如原生侧提醒权限没开、数据库插件在后台被回收之类。另一半来自数据层空值处理比如数据库查询字段为空时直接转 int 类型就会报错。建议在数据模型解析层统一做防御性判断不要让空值一路穿透到 UI 再炸。4.2 Future 异步与微任务队列的坑Flutter 开发中异步编程是最容易写错又最难排查的部分有人经常问“Future 的 then 回调是放在微任务队列里吗”这个问题我自己在项目里体会极深。结论是Future 的 then 回调会作为一个微任务被调度当你调用 Future 的方法后回调并不会立刻执行而是要等当前事件循环同步代码执行完再执行微任务队列。这个知识点影响实际项目的地方在于如果你在数据加载方法里先 await 了一个 Future然后又同步修改了 UI 依赖的状态变量UI 可能不会按你预想的顺序刷新。更隐蔽的是多个 Future 组合的时候Future.wait 的执行顺序容易搞混。我建议项目里统一用 async/await 而不是裸写 then 回调因为可读性强调试时栈信息也更清晰。另外不要在 build 方法里直接发起异步请求这会导致每帧 rebuild 都可能重新请求一遍数据正确做法是把请求放到 initState 或者 Provider 的初始化方法中。4.3 XTS 认证与 AAR 集成相关经验如果你的 App 是要上架 OpenHarmony 生态的应用市场就绕不开 XTS 认证。XTS 是 OpenHarmony 的兼容性测试套件用来验证应用和设备是否符合系统兼容性规范。我在项目后期跑过一次 XTS 测试遇到的问题多集中在权限声明和隐私合规层面。权限方面OpenHarmony 对敏感权限的管控非常严格凡是用不到的权限一律不要申请尤其是在本地健康数据这类应用里隐私声明和权限用途说明写不严谨就会被拒。关于 flutter aar 集成这个术语在 Android 工程里很常见OpenHarmony 的混合工程也有类似的产物模式。在宿主工程里引入 Flutter module 编译出来的 aar 包时要注意位次关系Flutter module 主工程和宿主工程的 minSdkVersion 之间如果存在冲突常常会表现为 native 库加载失败或者 MethodChannel 找不到实现类。排查这类问题最直接的突破口是把 native 日志打开看 Flutter 引擎初始化到哪一步崩的而不是盯着 Dart 层日志瞎猜。4.4 高频问题快速排查表现象可能的原因排查手段新建 Flutter 工程后在 OpenHarmony 上跑不起来SDK 版本、Flutter 分支、DevEco Studio 三者版本不匹配按设备系统版本反向查 Flutter 分支对应版本页面滚动时明显掉帧列表项未优化或图表持续重绘检查 const 构造、暂停不可见图表重绘MethodChannel 调用原生方法无响应插件未注册或原生侧方法名拼写不一致打开原生日志确认引擎初始化完毕后再调用通道药品库存变成负数库存扣减逻辑分散、事务未使用统一走数据层方法并加上事务与库存预检后台提醒不触发应用进程被杀死Timer 失效使用系统提醒调度能力替代 Flutter Timersqflite 报 MissingPluginException插件版本不支持 OpenHarmony更换兼容 OpenHarmony 的数据库插件实现这个表是自己项目跑出来的经验不一定覆盖所有情况但碰到类似症状时可以照着这个顺序排查能省下不少时间。最后说几句项目里的实在经验整个项目做下来我最大的感触是 Flutter 在 OpenHarmony 上的生态已经过了“能不能跑”的阶段正在往“跑得好不好”的方向走。引擎分支、插件兼容、渲染性能这些都在肉眼可见地改善但很多细节仍然需要用实际项目去趟坑才能摸清楚。比如 PlatformView 的兼容性、后台提醒的稳定性、XTS 认证对权限的严格要求这些都不是看文档能提前避开的只能靠真的把设备拿在手里试。另外家庭健康类工具这类 App数据安全意识必须从第一天就有。本地存储虽然不给网络权限看似安全但备份、导出、设备更换这些场景迟早会来。我建议至少在数据层预留一个加密能力接口哪怕现在不启用也不要等数据已经写了一大堆之后再做加密迁移那个成本就太高了。如果你也要做类似的项目我最后再分享三个小的建议第一数据模型上一定要预留成员维度哪怕现在只管一个人第二提醒功能优先用系统级的能力不要依赖 Flutter 的 Timer 方案第三多准备几台不同版本的 OpenHarmony 设备做回归纯靠模拟器和单一真机很多兼容性问题根本复现不出来。这些坑我不希望你非得重新踩一遍才知道。
