企业官网建设流程全解析

把 Flutter 应用跑上 OpenHarmony，再叠加一个"会话级步行轨迹追踪"的场景，这组合听起来有点小众，但我做完之后反而觉得——这恰好是 Flutter 跨端能力最值得验证的一类落地形态。轨迹追踪不像普通的表单页面，它涉及持续定位、状态管理、地图渲染、后台恢复，几乎把移动端开发的硬骨头都碰了一遍。这篇文章不聊空泛的"鸿蒙适配展望"，就记录我基于 Flutter 实现会话级步行轨迹可视化追踪的全过程：从环境选型、工程改造、会话生命周期设计，到地图绘制方案取舍、渲染异常排查，最后附上实测数据和踩坑清单。如果你正在考虑 Flutter 与 OpenHarmony 的结合，或者想做一个带地图轨迹记录的应用，这篇文章应该能帮你少走不少弯路。

1. 为什么纠结于在 OpenHarmony 上做 Flutter 轨迹应用

1.1 从"要不要做"到"怎么做"的决策逻辑

先说背景。我手头有个运动健康类的项目，原本只在 Android 和 iOS 上跑，用的就是 Flutter 那套跨端框架。后来产品提了一个诉求：OpenHarmony 设备要不要支持？当时公司内部其实有分歧——有人说直接用 DevEco Studio + ArkTS 重写一遍，有人说先评估 Flutter 的 OpenHarmony 适配情况再说。

我的立场很明确：除非业务逻辑简单到只有几个页面，否则在 OpenHarmony 上完全重写一套 ArkTS 应用，人力成本和后续维护成本都不可接受。尤其我们这个项目里有一个核心模块是"会话级步行轨迹可视化追踪"——用户点开始，系统持续记录 GPS 轨迹，以一段会话为单位展示行走路径、里程、配速。这种会话型功能天然是"跨端统一逻辑"的受益者：定位、滤波、会话状态机、轨迹数据模型，这些代码放到 Android 和 OpenHarmony 上理应完全一致，只有最上面的渲染层和底层定位通道需要做平台适配。

所以最终方案定为：Flutter 作为 UI 和业务逻辑层，OpenHarmony 通过 Flutter 的社区适配分支来承载。这一步的决策逻辑是——先用 Flutter 把应用跑起来，再逐步替换底层平台通道。

1.2 Flutter for OpenHarmony 到底成熟到什么程度

很多人一听到 Flutter on OpenHarmony，第一反应是"这能跑吗？"。老实说，目前（我写这篇文章时的体验）它已经不再是"能不能跑"的问题，而是"跑起来后要修哪些边角料"的问题。

官方这边，Flutter 主线其实并没有正式把 OpenHarmony 列为 target platform，真正可用的是社区维护的 flutter_flutter 仓库 OpenHarmony 分支，以及配套的 flutter_engine 和 flutter_packages 仓库。这套方案会生成一个标准的 OpenHarmony 工程（ohos 目录），然后通过自己实现的 Flutter 引擎壳把 Dart 代码跑在 OpenHarmony 的 Native 层上。

渲染层面，OpenHarmony 分支支持 Skia 和 Impeller 两条渲染路径。Impeller 是 Flutter 新一代渲染引擎，在 iOS 上已经默认启用，而 OpenHarmony 分支也逐步把它作为默认选项。我在实际项目里启用 Impeller 后遇到过一次画面渲染异常——轨迹页面在快速缩放时出现矩形花屏，后面会专门讲这个坑的完整排查链路。

能力层面，插件生态是最大的短板。像 google_maps_flutter、amap_flutter 这些地图插件基本没做 OpenHarmony 适配。CustomPainter 这类纯粹的绘制能力反而没问题，因为它是 Flutter 引擎自带的，不依赖平台。所以我在轨迹可视化上最终选择了"自绘 Canvas + 叠加瓦片图层"的路线，这也算是被生态逼出来的方案，后面细说。

2. 环境搭建与工程改造：跑起来是最难的一步

2.1 工具链组合：DevEco Studio + flutter_flutter OpenHarmony 分支

如果你之前只在 Android/iOS 上开发过 Flutter，第一次拿到 OpenHarmony 分支可能会有点懵，因为你要同时维护两套工具链：

• Flutter SDK：使用 flutter_flutter 仓库的 openharmony 分支，不是官方 release 版。
• OpenHarmony SDK：通过 DevEco Studio 安装，类似 Android SDK 的角色。
• DevEco Studio：OpenHarmony 应用的 IDE，用来编译、签名、烧录和调试 ohos 端工程。

我本地的环境组合是：flutter_flutter 的 3.22.x OpenHarmony 分支 + DevEco Studio 5.0 + OpenHarmony SDK 5.0.0。这个组合是目前能稳定跑完整项目的搭配，太新的分支容易踩到引擎还没合入的坑，太老的又缺少一些 API 能力。

需要特别提醒一点：不要用官方 Flutter 安装包来跑 OpenHarmony 工程，因为标准 Flutter SDK 根本不认识 ohos 目录，flutter create也生成不了 OpenHarmony 工程结构。你需要的 Flutter SDK 是那个 fork 出来的 OpenHarmony 分支版本。

2.2 用 FVM 管理多版本 Flutter：被逼出来的习惯

为什么提 FVM？因为一旦同时维护 Android、OpenHarmony 两个平台，你就一定会有多版本 Flutter 并存的需求——Android 那边可能还在跑 3.19 稳定版，OpenHarmony 这边却要切到 3.22 分支。如果不用 FVM，版本切换就是一场灾难。

FVM（Flutter Version Management）它就是个 Flutter 版本管理器，用法和 nvm 很像。核心命令就三条：

fvm install 3.22.0-openharmony fvm use 3.22.0-openharmony fvm flutter --version

把 .fvm/flutter_sdk 路径加进 IDE 的 SDK 配置里以后，项目级版本锁定就自动生效了，团队协作时也不会出现"我这边能跑你那边不能跑"的扯皮。尤其这种 OpenHarmony 分支版本，通过 FVM 管理比手动下载 https://gitee.com/openharmony-sig/flutter_flutter 的 zip 包再解压要清爽太多。

还有一个经验：FVM 装多版本 Flutter 之后，全局命令flutter可能和你预期的版本不一致。项目根目录下用fvm flutter才是正确姿势，尤其是执行flutter pub get和在 IDE 里调试的时候。

2.3 创建并改造 flutter ohos 工程：核心步骤与踩坑点

拿到 SDK 后，第一步是创建工程。OpenHarmony 分支的 Flutter 扩展了 create 指令，支持直接生成 ohos 平台目录：

fvm flutter create --platforms=android,ohos my_track_app

如果项目已经存在，也可以手动补上 ohos 平台：

fvm flutter create --platforms=ohos .

这会生成一个ohos/目录，里面是标准的 OpenHarmony 工程结构。关键文件包括：

• ohos/entry/src/main/ets/entryability/EntryAbility.ets：应用入口，类似 Android 的 MainActivity。
• ohos/entry/src/main/resources/base/profile/main_pages.json：页面路由配置。
• ohos/entry/src/main/module.json5：模块配置，包括权限声明、Ability 配置。

当时最容易踩的坑是把权限声明加错地方。定位、网络权限要在module.json5的requestPermissions里声明，而不是在 Flutter 的 AndroidManifest.xml 里写。我当时惯性思维只改了 Android 的配置，结果在 OpenHarmony 真机上LocationKit拿不到定位数据，卡了半天才发现是权限问题。

{ "module": { "requestPermissions": [ { "name": "ohos.permission.LOCATION", "reason": "$string:location_reason", "usedScene": { "ability": ["EntryAbility"], "when": "inuse" } }, { "name": "ohos.permission.INTERNET", "reason": "$string:internet_reason", "usedScene": { "ability": ["EntryAbility"], "when": "always" } } ] } }

编译时会偶发 "unable to find suitable visual studio toolc" 这类报错——虽然这热词看着像 Windows 上 Android 构建的问题，但我在 OpenHarmony 构建环境里也遇到过类似的工具链找不到问题，大部分是 DevEco Studio 的 Native 工具链没有正确配置导致的，去 SDK Manager 里重新安装 Native 工具链，或者在 ohos 目录下执行hvigorw clean再重试即可。

3. 会话级轨迹管理：把一次行走拆成一个个"会话"

3.1 会话生命周期：开始、暂停、恢复、结束

"会话级"是这个项目的灵魂。它不能是"地图上画一条永久线"，而是要以用户一次完整的运动过程为单位来管理数据。可以类比成播放器里的"播放会话"——有开始、暂停、恢复、停止，每个会话有独立的统计维度。

我把轨迹会话的状态机设计成四个状态：

• IDLE：空闲，没有进行中的会话。
• RECORDING：正在记录轨迹。
• PAUSED：已暂停，定位停止，但会话未结束。
• FINISHED：已结束，轨迹落库。

状态迁移规则：

1. IDLE -> RECORDING：用户点击开始。
2. RECORDING -> PAUSED：用户点击暂停。
3. PAUSED -> RECORDING：用户点击继续。
4. RECORDING/PAUSED -> FINISHED：用户点击结束。

状态机的好处是杜绝了非法操作，比如"暂停中点击结束"和"记录中点击结束"在 UI 上的确认弹窗、数据保存逻辑其实是不一样的，不建模就拿分支判断硬写，后面加功能时一定会乱。

代码上用enum+StateNotifier（Riverpod） 表达：

enum TrackingStatus { idle, recording, paused, finished } class TrackingController extends StateNotifier<TrackingStatus> { TrackingController(this._locationService) : super(TrackingStatus.idle); void start() { if (state != TrackingStatus.idle) return; _session = TrackSession.create(); _locationService.start(); state = TrackingStatus.recording; } void pause() { if (state != TrackingStatus.recording) return; _locationService.stop(); state = TrackingStatus.paused; } void resume() { if (state != TrackingStatus.paused) return; _locationService.start(); state = TrackingStatus.recording; } TrackSession finish() { if (state == TrackingStatus.idle) return null; _locationService.stop(); state = TrackingStatus.finished; return _session; } }

3.2 定位数据采集与去噪策略：千万别拿原始数据直接画线

GPS 数据有多"脏"，跑过步的人都知道——在开阔地带还好，一旦靠近高楼、树荫或桥下，定位点就会像喝醉了酒一样到处飘。如果直接把这些原始点连成线，轨迹上会出现大量锯齿和诡异的"穿楼"路径。

我处理定位数据的链路分为三层：

1. 层一：时间与精度过滤。定位点必须同时满足：

   • 水平精度accuracy<= 30 米（默认阈值，用户可调）。
   • 与上一个被采纳点的时间间隔 >= 2 秒。

2. 层二：速度与位移合理性过滤。单人步行速度上限一般是 3 m/s 左右，如果两个定位点之间的推算速度超过 10 m/s，大概率是定位漂移。把这类点直接丢弃，不进入轨迹。

3. 层三：离群点剔除。这个是针对静置漂移的——用户在路口等红灯时，GPS 会在周边 20 米范围内"震"，如果不做处理，轨迹上就会出现一团乱麻。

我的去噪代码核心就一个小函数：

class GpsFilter { static bool shouldAccept(TrackPoint point, TrackPoint? last) { if (last == null) return true; final distance = GeoUtils.distanceInMeters(point.latLng, last.latLng); final interval = point.timestamp.difference(last.timestamp).inSeconds; if (interval <= 0) return false; final speed = distance / interval; if (speed > 10) return false; // 超过 36km/h，视为异常点 if (distance < 3 && point.accuracy > 20) return false; // 静置漂移过滤 return true; } }

这套朴素规则对步行场景效果很好，没有上卡尔曼滤波这类重量级手段。在实测 30 分钟的步行会话里，过滤前大约采集到 850 个定位点，过滤后剩下约 640 个有效点，轨迹形状明显更干净。

3.3 会话数据模型：内存对象与本地存储双轨

会话在内存中是实时变化的，结束时需要持久化。我的数据结构定义为：

class TrackSession { final String id; final DateTime startTime; DateTime? endTime; final List<TrackPoint> points; TrackStatus status; double get totalDistance => _calculateDistance(); Duration get duration => (endTime ?? DateTime.now()).difference(startTime); double get avgPace => totalDistance / duration.inMinutes; } class TrackPoint { final double latitude; final double longitude; final double accuracy; final DateTime timestamp; final double? altitude; }

本地存储选用 Hive——纯 Dart 实现、无需原生依赖，这在 OpenHarmony 上非常友好，因为很多原生存储插件都没适配。写入时机是每次会话结束时全量写入，中间状态只保存在内存和 Riverpod 状态里。如果担心应用被杀，可以在每次pause()和每 30 秒自动落盘一次，但这个项目里用户步行场景时长较短，全量写就够了。

4. 轨迹可视化：地图组件选择与多段线绘制

4.1 OpenHarmony 的地图组件现状：为什么不能用现成插件

这是整个项目里最让人头疼的部分。在 Android 上，你可以用google_maps_flutter或者amap_flutter轻松画出 Polyline；在 iOS 上，有MapKit的 Flutter 封装。但到了 OpenHarmony：

• 谷歌地图：在 OpenHarmony 上没有官方支持，你也没有com.google.android.gms那套底座。
• 高德/百度地图：未开放适配 OpenHarmony 的地图 SDK，Flutter 插件更是没有。
• 华为地图：有Map Kit（基于华为 HMS），但对 OpenHarmony 非华为设备适配程度有限，而且 Flutter 插件需要额外封装。

所以"用现成地图 SDK 画轨迹"这条路基本是堵死的。我最终采用的方案是双图层法——底层渲染瓦片地图（静态图块），上层用 Flutter 内置的CustomPainter画轨迹线。

如果你觉得不需要地图底图，纯粹在透明背景上画轨迹也行，但体验上缺少参照物，用户很难感知路径走向。有底图的提升非常明显——用户能直观看到自己经过了哪条街道，步行轨迹才"活"了。

4.2 自绘 Canvas：Polyline 绘制与坐标投影

先讲底层的自绘方案。Flutter 的坐标系是左上角为原点、右和下为正方向，而 GPS 坐标是经纬度。这里必须做一次投影变换：把经纬度映射到当前可视区域的像素坐标。

我维护了一个可视区域类MapViewport，核心函数就是经纬度转屏幕坐标：

class MapViewport { final double latitude; // 中心点纬度 final double longitude; // 中心点经度 final double zoomLevel; // 缩放级别 final Size size; // 可视区域大小 Offset project(LatLng latLng) { final metersPerPixel = _metersPerPixel(); final dx = (latLng.longitude - longitude) * _metersPerDegreeLng() / metersPerPixel; final dy = -(latLng.latitude - latitude) * _metersPerDegreeLat() / metersPerPixel; // 纬度增大时 y 减小 return Offset(size.width / 2 + dx, size.height / 2 + dy); } }

绘制轨迹线就很简单了，在CustomPainter.paint()里遍历会话点集，把相邻点连成线段：

class TrackPainter extends CustomPainter { final List<LatLng> trackPoints; final MapViewport viewport; @override void paint(Canvas canvas, Size size) { if (trackPoints.length < 2) return; final paint = Paint() ..color = Color(0xFF00A0E9) ..strokeWidth = 6 ..style = PaintingStyle.stroke ..strokeCap = StrokeCap.round ..strokeJoin = StrokeJoin.round; final path = Path(); for (var i = 0; i < trackPoints.length; i++) { final offset = viewport.project(trackPoints[i]); i == 0 ? path.moveTo(offset.dx, offset.dy) : path.lineTo(offset.dx, offset.dy); } canvas.drawPath(path, paint); // 起点和终点标记 final startOffset = viewport.project(trackPoints.first); final endOffset = viewport.project(trackPoints.last); canvas.drawCircle(startOffset, 8, Paint()..color = Color(0xFF00C853)); canvas.drawCircle(endOffset, 8, Paint()..color = Color(0xFFD50000)); } @override bool shouldRepaint(covariant TrackPainter oldDelegate) { return oldDelegate.trackPoints != trackPoints || oldDelegate.viewport != viewport; } }

需要提醒的是，viewport.project里的经纬度到米换算不能直接按地球半径简单算，因为纬度不同经度代表的实际距离会变化。我用的是一阶近似：

• 纬度 1 度约等于 111,320 米。
• 经度 1 度 = 111,320 × cos(latitude) 米。

步行轨迹的尺度通常在几公里内，一阶近似不会造成视觉误差，不用上墨卡托投影。

4.3 瓦片地图叠加：不依赖地图 SDK 的底图方案

没有地图 SDK，但是我们能加载瓦片。原理很简单：地图厂商（比如 OpenStreetMap）把世界地图按金字塔层级切成一张张 256×256 的图片，前端根据经纬度和缩放级别计算当前可视区域需要加载哪些瓦片，拼起来就是一张底图。

Flutter 里可以通过Widget列表 +CustomPaint的层级关系实现：底下一个Stack放瓦片Image，上面放CustomPaint。

瓦片坐标计算函数：

class TileCalculator { static List<TileIndex> getVisibleTiles(MapViewport viewport) { final tiles = <TileIndex>[]; final n = pow(2, viewport.zoomLevel).toInt(); final xMin = tileX(-180, viewport.zoomLevel); // ... 根据屏幕可视范围反推经纬度边界，再算出瓦片 x/y 范围 return tiles; } }

加载瓦片后放进Stack：

Stack( children: [ // 瓦片底图 for (final tile in tiles) Positioned( left: tile.screenOffset.dx, top: tile.screenOffset.dy, child: Image.network(tile.url), ), // 轨迹图层 Positioned.fill( child: CustomPaint(painter: TrackPainter(...)), ), ], )

我测试用 OpenStreetMap 的瓦片服务，免费无需 key，访问速度在国内一般，但 OpenHarmony 开发阶段完全够用。如果要上生产环境，可以切换到底图是国内可访问的地图源，或者自己部署瓦片服务。

这里有一个性能坑：瓦片不能一次性全加载，否则内存和网络会有压力。我做了简单地按可视区域裁剪 + 缓存已加载图片，滑动地图时只加载新增瓦片，复用缓存图。实际 30 分钟轨迹约 640 个点，绘制帧率稳定在 55~60 FPS。

5. 性能调优与渲染异常排查

5.1 画面渲染异常的完整排查链路：Impeller 关掉还是打开

上面提到，启用 Impeller 后遇到过轨迹页面快速缩放时出现矩形花屏。这个问题在 Flutter 的 OpenHarmony 适配里挺有代表性，我把整个排查过程写下来，方便你复现思路。

现象：在轨迹详情页快速双指缩放时，屏幕会随机出现矩形色块，松手后恢复，但视觉上非常难受。复现率大约 30%，只有在轨迹线密集、Canvas 上有大量 drawPath 时才会触发。

排查步骤：

1. 我先怀疑是瓦片图层的问题。把瓦片加载临时注释掉，问题依旧，排除底图因素。
2. 再怀疑是CustomPainter.shouldRepaint写得太激进，导致每帧都在重绘。仔细检查后发现shouldRepaint只有在 viewport 变化时才返回 true，排除了这个方向。
3. 去 flutter_flutter OpenHarmony 仓库的 issue 区搜索，发现有人报告过类似"Impeller on OpenHarmony 矩形撕裂"的问题。定位到根因是 Impeller 在 OpenHarmony 上的某个渲染后端对drawPath的裁剪计算有 bug，尤其是带圆角 strokeCap 的粗线条路径在局部更新时容易触发。
4. 临时方案：用--no-enable-impeller回退到 Skia 渲染引擎。验证后问题消失。
5. 长期方案：等 Impeller 在 OpenHarmony 分支上修复，同时我在绘制层做了一个优化——把轨迹分成静态底图层（已经画好的历史轨迹）和动态高亮层（当前正在移动的点），缩放时只重绘动态层，减少 drawPath 的触发频率。

最终线上版本暂时跑在 Skia 上，性能表现也很稳定，轨迹绘制没有卡顿，只是启动热度和着色器编译上比 Impeller 略差一点点。我建议：如果 OpenHarmony 版本在你测试场景下没渲染问题，就开 Impeller 以获得更流畅的新引擎体验；如果有渲染异常，果断关掉，不要死磕。两者的 API 兼容性在 Flutter 框架层没有问题，你的 Dart 代码不需要做任何改动。

5.2 多线程与定位数据频率：UI 卡顿的根源

Flutter 是单线程 UI 模型，如果定位数据回调在 UI isolate 里做大量计算，卡顿是必然的。实测中，如果直接把 GPS 点送到 UI 线程进行去噪、距离累加、重绘，120 个点之后手势缩放就开始掉帧。

我的优化手段：

1. 底层频率降频：OpenHarmony 定位接口支持设置上报频率。步行场景下 1~2 秒一个点足够用，不需要高频刷新。OpenHarmony 的geoLocationManager.startLocation可以设置interval为 2000ms。
2. Main isolate 只做轻量操作：定位到点后，UI 线程只负责：
   • 追加到内存点的列表。
   • 标记轨迹数据脏（需要重绘）。
   • 更新距离进度文本。
3. 重计算丢到 compute isolate：距离求和、路径化简、统计计算这些放到compute()异步执行，结果回来后用ValueNotifier通知 UI 更新。

典型代码：

void onLocationUpdated(TrackPoint point) { _pendingPoints.add(point); final simplified = await compute(simplifyTrack, _pendingPoints); _trackNotifier.value = simplified; }

路径化简我用的是 Douglas-Peucker 算法的简化版，阈值设定为 3 米。这个算法能把 640 个点压缩到 300~400 个点，对绘制性能和 Canvas 负担的改善非常明显。如果你不知道这个算法，一句话解释：对一条折线找最远的点，如果偏离距离小于阈值就舍弃中间所有点，大于阈值就递归拆分，反复执行直到整体形状基本不变。

5.3 点数量大时的 Canvas 绘制的两个优化技巧

轨迹点少时无所谓，点多了之后 Canvas 绘制第一个要避免的是每帧都构建新 Path。我实现了一个两级缓存：

• 一级缓存：轨迹 Path 缓存。只要轨迹点集合没有变化，就复用之前构建好的Path对象，而不是在 paint() 里重建。
• 二级缓存：屏幕像素缓存。瓦片完全不动、轨迹也没新增时，直接把整张图层截图缓存到PictureRecorder，手势移动时只是平移这个 picture，不让 Canvas 重画几百个点。

第二个技巧是对轨迹线的简化显示——缩放级别小时，像素空间里的线路轨迹密集到无法区分，此时每 5 个点取 1 个点画线即可；缩放级别大时，再切换到全量点。这样能让缩放手势、地图平移过程中的绘制压力大幅下降。可以在MapViewport.zoomLevel变化时根据点的像素距离动态剔除。

6. 实测结果与避坑清单

6.1 真机测试数据：30 分钟会话的表现

工程跑在 OpenHarmony 5.0 的真机（开发板）上，我用一次完整的户外步行做了压测：

步频、配速、轨迹形状都符合预期。最有价值的是轨迹过滤前后的对比——过滤前地图上能看到明显的"毛刺"和"短跳"，过滤后整体平滑了很多，也没有把正常的直角转弯或 U 型折返误删。

6.2 踩坑清单：从环境问题到业务逻辑

这些坑是几天时间里一轮轮踩出来的，整理成清单，你对照着排查会省很多时间：

环境类

• unable to find suitable visual studio toolc之类找不到工具链的报错，先查 DevEco Studio 的 Native 工具链是否装全，别急着重装项目。
• Flutter SDK 一定要用 OpenHarmony 分支，且最好通过 FVM 固定版本，否则多人协作时版本不一，会出现"我这边能跑你那边跑不了"的问题。
• OpenHarmony 构建默认走的是 hvigor，不是 Gradle，别拿 Gradle 的思路硬套。ohos目录下有独立的构建配置。

权限与平台通道类

• OpenHarmony 的定位权限、网络权限在module.json5的requestPermissions声明，不是 AndroidManifest.xml。我当时漏掉ohos.permission.LOCATION，真机上拿不到任何定位回调。
• 高德地图、谷歌地图等插件不适用于 OpenHarmony，别花时间尝试适配，直接用瓦片地图 + 自绘方案更可控。

绘制与渲染类

• 启用 Impeller 后如遇到画面渲染异常，先关掉 Impeller 验证，再找触发条件上报 issue。
• Canvas 绘制的shouldRepaint必须严格比较传入对象，否则每次 setState 都会把整条轨迹重画一遍，卡成 ppt 是必然的。
• 轨迹点一定要做过滤和化简，原始数据直接画线虽然功能上能"跑通"，但产品上没法看。让用户看到真实的运动轨迹而不是定位噪声，这决定了这个功能能不能上线。

6.3 如果再往下走：会话级能力还能扩展什么

会话级步行轨迹可视化追踪做完之后，我发现这个架构其实可以很自然地往外扩展。

我目前已经在规划的一个能力是"会话内分段统计"——把 30 分钟的步行拆成每公里一段，分别计算每段的配速，在轨迹上用不同颜色标识快慢段。这个实现完全不需要动底层，只需要在绘制层把轨迹点按累计里程切分几段，每段用不同颜色的 Paint 画出来就行。

另一个方向是会话回放。因为会话模型里每个点都带时间戳，天然支持按时间轴播放轨迹——用AnimationController驱动一个进度值，不断更新"当前已绘制的点集"即可。这个功能对运动类应用来说是极具竞争力的差异化能力，值得投入。

还要考虑的是多设备会话合并。用户的 OpenHarmony 手表和手机可能是两个采集端，会话模型需要支持"多个采集端数据源合并到一个 TrackSession"或"多 TrackSession 对比"。这意味着会话数据模型要增加数据源字段，轨迹点要带来源标识，绘制层也要能遮挡显示多条轨迹线。这些都是"会话级"架构带来的自然延伸，在一开始设计数据模型时留出扩展字段就能平滑对接。

最后分享一个个人体会。很多团队面对"Flutter 跑 OpenHarmony"这件事，第一反应都是观望，但我的实际体验是，选对技术路径之后，它并没有想象中那么不可控。环境上的坑大多一次性踩完，业务逻辑完全复用，真正要花心思的是渲染适配和平台能力补齐这两块。如果你也打算在 OpenHarmony 上做类似的事，我的建议是：先跑通最小闭环，再逐步掉头优化细节，千万别一上来就追求完美架构——你需要的不是一版完美代码，而是一条能让用户真正走起来的轨迹。