企业官网建设流程全解析

直接把项目标题丢进我邮箱的人不少，但像这次这样的话，说“要一个 Flutter 写 OpenHarmony 的身体健康记录 App，重点看运动详情怎么做”，一没给设计稿，二没给后端接口，唯一的要求是“跑得起来、拿得出手”。我拿到这个需求的第一反应是，这事没那么简单，但也没那么难——Flutter 的跨端能力和 OpenHarmony 的生态底座，恰好把这事的难度压到了一个人能扛住的范围内。

先说结论：如果你要在 OpenHarmony 设备上做健康类应用，Flutter 是目前很值得选的路子，尤其是运动详情这种“数据展示+图表交互+本地存储”都很重的页面，Flutter 的渲染性能、组件生态和状态管理方案都能直接平移过来。这篇文章我就围绕运动详情的完整实现，把从数据建模、状态管理、UI 布局到图表绘制、性能优化的整个链路拆开讲，所有代码都是我在模拟项目X里实际跑过的版本，不是 PPT。

适合谁看？两类人最对口：一是已经在 Flutter 里做过业务应用、想低成本切入 OpenHarmony 开发的；二是正在评估 OpenHarmony 应用技术选型、想知道 Flutter 在这里到底能不能扛真实业务的。当然，如果你是刚接触 Flutter 的新手，这篇文章的数据流和组件拆解也对你有用，至少能少踩几个我没帮你踩掉的坑。

1. Flutter for OpenHarmony 的工程底色与运动详情模块的整体拆解

1.1 这个技术组合的前提：Flutter 的跨端能力在 OpenHarmony 上怎么落地

提到 Flutter for OpenHarmony，绝大多数人第一反应是“这不就是跑个 Flutter 引擎吗”。姿态完全正确，但细节决定体验。OpenHarmony 虽然不是 Android，但 Flutter 引擎在它上面的适配走的是类似 Embedder 的思路：OpenHarmony 提供 Surface 和事件注入，Flutter 引擎在这之上跑 UI 线程、栅格化线程和 IO 线程，渲染路径走的是 Skia，和你在 Android 上看到的 Flutter 渲染管线基本同源。

我实际用下来的体验是，Flutter 写的页面在 OpenHarmony 设备上的帧率稳定性和触摸响应，都达到了可用的水平。尤其像运动详情这种充斥着图表和滚动列表的页面，Flutter 的自绘特性反而成了优势——它不需要频繁地和原生控件做桥接，图表、卡片、手势动画全在 Flutter 内部搞定，性能瓶颈更容易控制在自己手里。

不过工程落地的细节要比 Hello World 多得多。我当时用的是社区维护的 flutter_flutter 适配分支，在 OpenHarmony 的 DevEco Studio 里把 Flutter 工程作为 HarmonyOS 模块嵌进去，Process 还是用 OpenHarmony 的 UIAbility 拉起。这里有个容易混的点：你的应用外壳（Ability、权限声明、生命周期）是 OpenHarmony 的，业务 UI 是 Flutter 的，两者之间的生命周期事件（Foreground、Background、Pause）需要手动桥接给 Flutter 侧。

注意：如果你选的 Flutter SDK 版本和 OpenHarmony SDK 版本不匹配，最常见的问题是编译通过但运行白屏。我当时锁的是 Flutter 3.x 的适配分支 + OpenHarmony 4.x 的 API，调试起来很顺。升级任何一个大版本之前，先看适配说明，别盲升。

1.2 运动详情模块在健康 App 里的定位：为什么它是全App最值得下功夫的一页

先摆个背景。我模拟项目X里的身体健康记录 App，功能分几大块：首页健康概览、运动记录列表、运动详情、身体指标趋势、个人设置。运动详情这个页面看名字不起眼，实际上它是用户感知“我这个 App 到底好不好用”的最核心触点——用户辛苦跑完步、骑完车，打开 App 就想看这次运动到底怎么样，数据准不准、图表顺不顺、有没有仪式感，全在这一页。

所以运动详情的需求拆出来，不只是“显示几个数字”那么简单，至少要覆盖四块能力：

• 基础运动信息展示：运动类型、开始时间、持续时间、里程、卡路里。
• 数据指标卡片：平均配速/速度、平均心率、最大心率、步频等核心生理和运动指标。
• 图表可视化：心率曲线、配速变化曲线，有条件还要上运动轨迹地图。
• 分段数据列表：按公里或按时间分段的详细表现，方便跑者做复盘。

这四块能力在 Android 或 iOS 上用 Flutter 做当然没问题，但在 OpenHarmony 上要重新验证一遍生态兼容性。比如图表库能不能编译过、地图 SDK 有没有 OpenHarmony 版本、传感器数据通过什么通道拿，都是实战中必须先探路的地方。我后面几个章节会逐一把这些问题展开讲。

1.3 页面结构规划与数据来源决策

运动详情的 UI 结构我分了四个层级，从上到下分别是：

• 顶部预览区：运动类型图标 + 运动状态 + 时间长度 + 大数字卡路里；
• 指标卡片区：用横向排列的多张卡片展示配速、心率、步频等；
• 图表区：心率曲线 + 配速柱状图（或折线）；
• 分段列表区：每公里/每圈的数据明细。

数据来源有两种方案。第一是纯本地记录，运动结束后把所有数据写入本地数据库（我用的是 Hive），详情页直接读本地数据；第二是服务端下发，App 需要先拉取运动记录详情再展示。

我最终选择了“本地优先”方案，原因很现实：运动记录是用户的高频读写数据，走服务端会引入网络延时和加载态，而这页面的价值恰恰在“打开的一瞬间就要看到结果”。服务端同步放到后台去做，页面始终以本地缓存为第一数据源，体验最稳。

2. 运动记录的数据建模与状态管理设计

2.1 运动记录数据模型：不只是字段，而是字段之间的关系

先上一个我实际在用的数据模型关系。运动记录是一个聚合根，它下面挂了运动指标、心率序列、分段数据这三类子信息。用 Dart 的原生 class 来描述，核心结构长这样：

enum WorkoutType { running, cycling, walking, swimming } class WorkoutRecord { final String id; final WorkoutType type; final DateTime startTime; final DateTime endTime; final double distanceMeters; final double durationSeconds; final double calories; final double avgHeartRate; final double maxHeartRate; final double minHeartRate; final double avgPace; // 配速，单位秒/公里 final double avgSpeed; // 速度，单位米/秒 final List<HeartRateSample> heartRateSeries; final List<SplitItem> splits; } class HeartRateSample { final DateTime timestamp; final int bpm; } class SplitItem { final int index; final double distanceMeters; final double durationSeconds; final double avgHeartRate; final double avgPace; }

这里有三个字段是新手最容易定义错的。

第一个是配速（Pace）。在跑步场景里配速是“跑一公里用时多少”，单位是分/公里或秒/公里，不能直接存成小数分钟数，否则格式化的时候全是精度问题。我在模型里统一存“秒/公里”，展示层再格式化成 5'30"/km 这样的字符串。算完一个 5 分 30 秒配速，存的是 330 而不是 5.5。

第二个是速度（Speed）。配速和速度是倒数关系，但配速用的是时间/距离，速度用的是距离/时间。很多接口给的是 km/h，比如 10.8km/h，而本地计算步频和配速时用的是 m/s，建议统一在模型层先转换成 m/s，所有计算全走标准单位，只有展示层做单位切换。

第三个是心率序列的采样点。它不能是一个平均值数组，必须带时间戳。为什么？因为心率曲线画出来后，X 轴的均匀分布不是按“第几个采样点”来的，而是按真实时间间隔来的，否则出现掉点或补点阶段，曲线就变形了。

另外还有运动类型的枚举设计。我用的是枚举而不是字符串，最大好处是 switch 写逻辑（换图标、换文案、计算不同运动的卡路里系数）时，编译器会提醒你把所有分支写完，不会漏。

经验之谈：数据模型在写界面之前，先花 30 分钟把它推演完整。我第一版没考虑心率序列的时间戳，画图表时才发现按点索引画出来的曲线会把时间轴压缩得毫无意义，后面补数据迁移，烦得很。

2.2 状态管理选型：Provider 还是 Riverpod，以及页面内的状态切分

Flutter 的状态管理方案这么多年了，选择反而多了容易纠结。在模拟项目X里，我用的是 Provider + ChangeNotifier，没用 Riverpod，也没上 Bloc。原因很朴素：Provider 在 OpenHarmony 社区适配版里的兼容性经过验证最多，资料和踩坑记录最全；运动详情页的状态复杂度用 ChangeNotifier 完全压得住；团队没有人写 Bloc，不为了“架构感”引入学习成本。

运动详情的状态切分我做了三层：

• 应用级状态：登录态、用户信息、全局主题，用 Provider 挂在应用顶层；
• 页面级状态：当前正在展示的运动记录、加载状态、错误状态，用 ChangeNotifier 放在详情页的 Provide 范围里；
• 组件级状态：图表的悬浮选中值、卡片的展开折叠，用 StatefulWidget 的局部 State 管理，不提升到全局。

页面级的状态类大概长这样：

class WorkoutDetailController extends ChangeNotifier { WorkoutRecord? _record; bool _loading = false; String? _error; WorkoutRecord? get record => _record; bool get loading => _loading; String? get error => _error; Future<void> loadWorkout(String workoutId) async { _loading = true; _error = null; notifyListeners(); try { _record = await workoutRepository.fetchById(workoutId); } catch (e) { _error = e.toString(); } finally { _loading = false; notifyListeners(); } } }

这里的 fetchById 表面上是“查询接口”，实质上是先查 Hive 缓存，没有缓存再触发网络请求。Controller 里不直接操作数据库也不直接发网络请求，全部走 Repository 层，这样将来换成服务端下发或者接入新的数据源时，只动 Repository 一个文件就够了。

我特别想提醒的是页面里的 setState 洁癖问题。图表区上面有手势选中、下面有滚动列表，如果整个页面都用同一个 StatefulWidget + setState，每次心跳数据刷新一次就要 rebuild 整棵树，曲线直接开始卡。把变化影响面大的区域（图表、指标卡片）单独拆成 Consumer 组件，让它们各听各的，才能保住性能。

2.3 数据持久化：Hive 在 OpenHarmony 上的实际工作状态

健康类 App 有个天然的属性：大量数据是本地产生的，而且隐私敏感。我把运动记录用 Hive 存在本地，用 record id 作为 key，存的是序列化后的 Map。Hive 在 OpenHarmony 上的适配比想象中顺利，因为在底层它本来就是纯 Dart 实现，文件 IO 走的是 Dart IO，和平台相关性很弱。

不过我在用 Hive 时遇到了一个版本坑：某些版本在 OpenHarmony 上打开 Box 时文件锁机制和 Android 有些差异，偶发卡顿。解决办法是把 openBox 的操作放到初始化阶段，加一个全局的 Box 引用，不要频繁开关。实际用下来，几百条运动记录的读写都在毫秒级，完全够用。

3. 运动详情页面的核心 UI 实现与图表绘制

3.1 顶部概览区的布局：信息层级决定第一印象

页面打开的一瞬间，用户先看到的一定是顶部概览区。我的做法是一个大背景卡片 + 运动类型图标 + 运动总时长居中 + 卡路里大数字靠右。背景卡片用了渐变色，从运动类型的主题色渐变到透明。

这段布局我用的是 Stack 叠层：下层放渐变背景 Container，上层放 Row 编排信息。具体代码如下：

Container( height: 220, decoration: BoxDecoration( gradient: LinearGradient( begin: Alignment.topLeft, end: Alignment.bottomRight, colors: [typeColor.withOpacity(0.9), typeColor.withOpacity(0.2)], ), borderRadius: BorderRadius.circular(24), ), child: SafeArea( child: Padding( padding: const EdgeInsets.all(20), child: Row( children: [ Container( width: 56, height: 56, decoration: BoxDecoration( color: Colors.white.withOpacity(0.2), shape: BoxShape.circle, ), child: Icon(workoutTypeIcon[record.type], color: Colors.white, size: 28), ), const SizedBox(width: 16), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, mainAxisAlignment: MainAxisAlignment.center, children: [ Text( formatDuration(record.durationSeconds), style: const TextStyle( fontSize: 36, fontWeight: FontWeight.bold, color: Colors.white, ), ), Text(workoutTypeName[record.type], style: ...), ], ), ), Column( mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.end, children: [ Text('${record.calories.toStringAsFixed(0)}', style: ...), const Text('千卡', style: ...), ], ), ], ), ), ), )

这段代码在 OpenHarmony 上跑的体验和 Android 几乎没差异，字体渲染、圆角裁剪、渐变填充都是标准 Flutter 能力，没有碰原生控件的边。需要留心的是 SafeArea 在 OpenHarmony 上对状态栏的避让逻辑，部分设备的挖孔区形状和 Android 差异较大，建议测试两台以上的真机。

3.2 指标卡片区：多卡片布局与自适配方案

指标卡片区域我用了一个横向滚动的 ListView，每张卡片固定宽度 140，高度 100，里面三行：指标名、数值、单位或副信息。这样做的好处是“少就是多”——四个指标全塞进一屏会挤，横向滑动反而让每张卡片的可读性更高。

卡片数据结构用了一个内部类：

class MetricCardData { final String label; final String value; final String unit; final Color accentColor; final IconData icon; }

四个指标我按优先级排列：平均配速、平均心率、最大心率、累计爬升（骑行就换成平均速度）。这里有个产品层面的小细节：不同运动类型，指标优先级不同。跑步首看配速，骑行首看速度，游泳首看划频和心率区间。我做了个按运动类型返回指标列表的工厂方法，每张卡片的展示优先级完全跟着运动类型走。

3.3 心率曲线与配速曲线：不用第三方库，纯 CustomPainter 方案

图表是运动详情页里我最想聊的部分，因为这里的选择题很典型：用现成的 fl_chart 库，还是自己画？

我在模拟项目X里实验了两个方案。fl_chart 确实是 Flutter 生态里最好用的图表库，折线图开箱即用，动效也成熟。但它在 OpenHarmony 上有一个隐患：它依赖的手势识别和动画 ticker 在 OpenHarmony 的 Flutter 适配版上，偶发掉帧。再加上运动详情的心率曲线交互相对简单，就一个“滑动选点 + 显示该点时间和心率”，用自绘反而更可控。

自绘方案用的是 CustomPainter + GestureDetector。总体思路：

• 把心率序列映射到 Canvas 的坐标空间；
• 按真实时间戳算 X 坐标；
• Paint 绘制背景网格、折线路径、渐变填充区域；
• 在 GestureDetector 的 onPanDown/onPanUpdate 里把触摸点的 X 坐标反向映射到心率序列的索引位置，绘制垂直参考线和选中点气泡。

核心绘制代码如下：

class HeartRateChartPainter extends CustomPainter { final List<HeartRateSample> samples; final int? selectedIndex; HeartRateChartPainter({required this.samples, this.selectedIndex}); @override void paint(Canvas canvas, Size size) { if (samples.isEmpty) return; final minX = samples.first.timestamp.millisecondsSinceEpoch.toDouble(); final maxX = samples.last.timestamp.millisecondsSinceEpoch.toDouble(); final minY = 60.0; // 心率下限 final maxY = 200.0; // 心率上限 double mapX(DateTime t) { final ratio = (t.millisecondsSinceEpoch - minX) / (maxX - minX); return ratio * size.width; } double mapY(double bpm) { final ratio = (bpm - minY) / (maxY - minY); return size.height - ratio * size.height; } // 网格线 for (int i = 0; i <= 4; i++) { final y = size.height * i / 4; canvas.drawLine( Offset(0, y), Offset(size.width, y), Paint() ..color = Colors.grey.withOpacity(0.2) ..strokeWidth = 1, ); } // 折线路径 final path = Path(); for (int i = 0; i < samples.length; i++) { final x = mapX(samples[i].timestamp); final y = mapY(samples[i].bpm); if (i == 0) { path.moveTo(x, y); } else { path.lineTo(x, y); } } canvas.drawPath( path, Paint() ..color = HeartRateColor ..style = PaintingStyle.stroke ..strokeWidth = 2.5 ..strokeJoin = StrokeJoin.round, ); // 选中标记 if (selectedIndex != null && selectedIndex! < samples.length) { final selected = samples[selectedIndex!]; final x = mapX(selected.timestamp); final y = mapY(selected.bpm); canvas.drawLine( Offset(x, 0), Offset(x, size.height), Paint() ..color = Colors.white.withOpacity(0.4) ..strokeWidth = 1, ); canvas.drawCircle(Offset(x, y), 5, Paint()..color = Colors.white); } } @override bool shouldRepaint(covariant HeartRateChartPainter oldDelegate) { return oldDelegate.samples != samples || oldDelegate.selectedIndex != selectedIndex; } }

这段代码我建议你重点抄两个地方：心率 Y 轴固定范围（60~200），因为心率有生理意义，不能像普通折线图那样自动适配数据范围，否则一会儿从 80 起一会儿从 40 起，曲线看起来很抖；X 轴按真实时间戳映射，而不是按采样点序号，这样才能保证掉一个点以后曲线形状仍然正确。

配速曲线我用的是柱状图，同一张画布、不同画法。每公里一个柱子，柱高对应配速的秒数，颜色按心率区间上色：偏高心率区间用暖色，正常区间用冷色，一眼就能看出哪公里跑崩了。这就是运动复盘的价值所在，配速曲线不是摆设。

3.4 分段数据列表：懒加载与渐变动效兼顾

页面最底部的分段列表，我用的 ListView.builder。每条分段数据展示“第 X 公里”、“用时 MM:SS”、“配速”、“心率”四列，中间用一条浅灰色分割线分隔。这个列表数据量不大，最多四五十条，直接用 builder 构建没有任何性能压力。

为了让页面看起来有层次感，我给列表区的每条分段数据加了淡入动画：首次进入页面时，分段按 50ms 的间隔从透明+位移到完全可见。实现用 AnimatedOpacity 或者 TweenAnimationBuilder 都可以，代码量很小：

TweenAnimationBuilder<double>( tween: Tween(begin: 0, end: 1), duration: Duration(milliseconds: 300 + index * 50), builder: (context, value, child) { return Opacity( opacity: value, child: Transform.translate( offset: Offset(0, 12 * (1 - value)), child: child, ), ); }, child: SplitItemWidget(split: split), )

这个小细节用户一般不会说出来，但体验上的“顺滑感”会默默加分。实现成本低，没有理由不做。

4. 数据刷新、页面生命周期与 OpenHarmony 适配的关键细节

4.1 从运动进行中到详情页：实时数据到静态数据的衔接

正常情况下运动详情页展示的是已经运动结束的历史记录。但模拟项目X的产品需求里有一个特殊情况：用户可能在运动刚结束、数据还在落盘收尾时就点进详情页。此时数据库里主记录可能已写入，但心率序列或分段数据还没完全写入，读出来就是“缺胳膊少腿”的详情。

这个问题我在第一版真机测试时踩过，现象就是用户结束运动后立刻进详情，心率曲线只有开始半小时的数据，后面小半程直接消失。排查过程花了一些时间，最后定位不是查询写错，而是写入竞态：结束运动的写入事务和详情页的读取事务在同一个 isolate 里同时执行，Hive 的 Box 在同一时刻被多条链路访问，读到了中间态。

解决方案分两层。第一层，写入侧在运动结束时先写主记录、再写心率序列、最后写分段数据，全部在一个事务里；第二层，读取侧对运动数据的完整性做校验，如果心率序列为空或时长不满运动时长的 80%，就触发一次延迟重读，把读取放到写入事务结束之后。代码里的表示是这样的：

Future<WorkoutRecord?> fetchById(String id) async { final raw = _box.get(id); if (raw == null) return null; final record = WorkoutRecord.fromMap(raw); if (_isIncomplete(record)) { await Future.delayed(const Duration(milliseconds: 300)); final retry = _box.get(id); if (retry != null) return WorkoutRecord.fromMap(retry); } return record; } bool _isIncomplete(WorkoutRecord record) { final expectedDuration = record.durationSeconds; if (record.heartRateSeries.isEmpty) return true; final lastSampleSec = record.heartRateSeries.last.timestamp .difference(record.startTime).inSeconds; return lastSampleSec < expectedDuration * 0.8; }

经验总结：健康类 App 里“边写边读”的场景比想象中常见（后台记录运动时切到前台看数据、运动结束自动跳转详情等），核心坑位就一个——不要信“写入完成后读一定安全”，要给读取侧加校验逻辑。

4.2 生命周期桥接：OpenHarmony 的 UIAbility 事件如何通知 Flutter 侧

OpenHarmony 的应用生命周期和 Flutter 引擎不是完全自动同步的。主流适配方案里，Flutter 侧监听生命周期靠 WidgetsBindingObserver 的 didChangeAppLifecycleState，但这个事件的触发源头是 Flutter Engine 自己感知到的平台状态变化，在 OpenHarmony 的 UIAbility 实现里，这部分的桥接链条时有时无。

我的做法很土但很稳：在 EntryAbility 的 onBackground、onForeground、onDestroy 里显式调用 Flutter 侧的生命周期接口。具体是在 Flutter 侧暴露一个 MethodChannel，原生侧在生命周期回调里把事件推过去，Flutter 侧收到后再分发到业务层。

// Flutter侧 final _lifecycleChannel = MethodChannel('app/lifecycle'); _lifecycleChannel.setMethodCallHandler((call) async { switch (call.method) { case 'onBackground': _handleAppBackground(); break; case 'onForeground': _handleAppForeground(); break; case 'onDestroy': _handleAppDestroy(); break; } });

有人可能会问：开着 MethodChannel 会不会增加维护成本？会，但这个成本换回来的是确定性和可控性。运动详情页有一个场景极度依赖这个桥接：用户切到后台，再切回来，图表区的数据不能闪烁或重新加载，而是继续保持离开时的滚动位置和选中状态。没有生命周期通道，你只能靠 Flutter 内部自己猜状态，很容易猜错。

4.3 传感器数据与运动详情的物理单位换算

运动详情里涉及的指标和传感器强相关。心率来自 PPG 传感器或外接设备，步频来自加速度传感器，里程来自 GPS 轨迹或步频估算。这些数据从原生层拿回来后，有一个统一的物理单位换算链路要走。

我模拟项目X里的数据链路是这样的：原生侧统一上报国际单位，心率是 bpm，加速度是 m/s²，GPS 坐标是经纬度，速度是 m/s；Flutter 侧拿到后全部按统一标准存储。展示层遇到需要切换单位的场景再做格式化，比如速度一栏默认显示 km/h，用户切到英里制时换算为 mph。

这个链路看起来就是“统一单位”四个字，实际操作容易在兜底逻辑上翻车。比如 GPS 信号弱时跑了一段路，里程显然小于实际值，但步频和心率是传感器算的，这时如果配速 = 距离/时间，配速会显示得非常离谱。我在底层做了个校验：当距离 < 200 米时，配速位直接展示“--”，因为这个距离下配速没有意义，强行显示反而误导用户。

5. 常见问题与高效避坑速查表

运动详情的实现过程中，我把踩过的坑按“现象—原因—解法”整理成了一张速查表。这表和网络上的报错解决方法不太一样，更多是业务逻辑和交互层面的坑，属于不真正跑一个健康 App 不会碰到的那种。

其中我特别想展开的是心率尖刺问题，这个坑的隐蔽性很强。跑步过程中手表稍微晃一下、戴松一点，传感器就会采到几个明显超出正常范围的值（比如突然 190 bpm，一秒后又回到 145）。如果你直接把原始采样点画上去，曲线的尖峰就会给用户一种“传感器不靠谱”的印象，而实际上绝大多数用户分不清是数据问题还是展示问题。

我的处理是画图之前先做一轮平滑：每 5 个相邻采样点取均值作为当前点的值。这样做会轻微平滑掉真实的心率快速变化（比如冲刺瞬间心率飙高），但在运动详情这种复盘场景里，可读性优先于极端值的精确性。如果你做了这个平滑，建议把原始数据和平滑数据的差异率控制在 5% 以内，不要为了好看把真实的冲刺心率小高峰也抹掉。

6. 性能优化实测：如何把详情页稳定压在 60 FPS

6.1 页面卡顿的真凶：不是图表本身，而是图层叠加

运动详情页最容易卡的位置不是图表绘制，而是整页滑动时图表和指标卡片的重叠区域。真机 profile 后发现，掉帧场景集中在“列表滚动到图表区域”这个过程中，CPU 并不高，反而是 GPU 的 overdraw 很严重。

原因分析是这样的：页面的滚动容器是一个大 ScrollView，图表区是固定高度嵌套在里面的，而图表区的 CustomPainter 每帧都在 repaint（因为 ScrollView 滑动时图表位置变化，Flutter 需要重新合成图层），加上指标卡片的阴影、半透明背景，同一区域叠加了四五层绘制，GPU 直接饱和。

解决思路是把图表区的绘制开销尽量压低。我做了三件事：

• 给图表区的 Container 设置clipBehavior: Clip.antiAlias，避免圆角外区域参与绘制；
• 把 Card 的阴影改成BoxShadow，颜色用不透明度低的深色，替代 blur 大的全透明阴影；
• 图表 Painter 里加一个 60 秒缓存：当采样点数量超过 500 时，先把 Path 生成结果缓存到内存，滚动时直接复用，不再重复算 Path。

第三件事收益最大。运动时长一小时，心率采样 3000 个点，每帧重建这个 Path 本身就是纯计算负担。缓存 Path 后，Chart 区的滚动开销直接降了一个数量级。

6.2 列表项的 build 频率：别让滚动刷新毁掉图表的流畅度

详情页底部的分段列表，如果用简单的 ListView.builder，每次滑动时列表项重新构建是正常的。但问题是列表项构建会连带触发它依赖的 Provider 读取，如果 Provider 粒度太粗（比如整个 Controller 挂在页面顶层），一次 Provider 通知会让所有子组件全部 rebuild，包括不依赖于该状态的图表组件。

我的结构是三层 Provider + Consumer：

• 顶层用 ChangeNotifierProvider 提供 WorkoutDetailController；
• 图表区用 Consumer 只监听心率系列和选中索引；
• 列表区用 Consumer 只监听分段数组。

这样当用户滑动分段列表时，只有列表区重新构建，图表区完全不受影响。实测下来平均帧率从晃动的 40 多帧稳到了 60 帧。

6.3 图像缓存与字体优化的附加收益

在 OpenHarmony 上，Flutter 的字体渲染整体没问题，但中文字体首次加载会有一小段白屏时间。运动详情页顶部的运动类型标题用了加粗中文字体，我在项目里把字体文件做了一次预加载，放在启动页和详情页之间，提前用FontLoader注册。这步操作不大，但可以避免用户每次冷启动进详情页时“先白后字”的尴尬。

运动类型图标我用的是自定义 IconData，本质上是一段字形数据。为了减小包体和渲染压力，我把常用图标做成了图片缓存，首次加载后常驻内存，不再走图标字体查询。

7. 项目总结与个人实战体会

这套运动详情实现方案，在模拟项目X上从第一个 Demo 到完整落地用了大约三周，其中排掉的环境和适配坑占了接近一半时间。但整体走下来，我对 Flutter for OpenHarmony 的判断是正面的：它的渲染主体能力没有打折，状态管理和自绘方案可以完全复用，真正需要你花心思的是工程接入层的生命周期桥接和数据完整性保护。

有几件小事是常规文档不会写、但我强烈建议你提前做的：

• 第一，真机调试别只看一块屏。OpenHarmony 的平板、手机、带鱼屏设备的窗口尺寸差异比 Android 阵营更大，运动详情的卡片区我用的是固定宽度横向滑动方案，就是为了避开不同屏宽下的自适应问题。如果你的目标设备是手机和平板都要支持，建议卡片区改成自适应宽度按比例计算。

• 第二，数据模型尽量多存原始单位。不要为了展示方便直接存 km/h，存 m/s，展示层随时可以换算。一旦存了格式化后的字符串，后面要接国际版或者改单位制，全部要重写。

• 第三，图表区的滑动选点功能在一开始就要设计数据索引和像素坐标的映射关系，不要后面补。补的话大概率会写出“选中点和曲线位置对不上”的将就方案，返工成本比一开始就做高得多。

最后再分享一个小技巧：OpenHarmony 上 Flutter 的调试热重载有时候不生效，别慌，大部分情况是 DevEco Studio 的构建缓存问题，关掉命令行里的构建守护进程，重新 build 一次就好。这个小问题我一开始还以为是代码写错了，排查好久才发现是工具的锅。

运动详情这个页面做完了，整个 App 的“硬骨头”也基本啃完了，后面再做什么历史趋势、身体指标分析，在技术上都只是这个页面的变体。你如果也在用 Flutter for OpenHarmony 做健康类项目，把这套数据建模、自绘图表、状态切分的路子吃透，后面的路会很顺。