企业官网建设流程全解析

前一阵子我接到一个活儿：给某个健康管理项目做 OpenHarmony 端的应用。这个 App 的核心功能是把用户每天的身体数据——体重、心率、睡眠时长、血压、步数——记录下来，然后在首页给用户一个一眼就能看懂的统计结果。我选了 Flutter for OpenHarmony 来做整个跨端实现，其中一个重头戏就是“统计概览”页。这部分整体不算复杂，但真正落地时牵扯到数据聚合、图表绘制、状态管理、页面性能一堆问题，踩的坑比预想的多。这篇就把统计概览从设计到实现的完整过程复盘一遍，给正准备用 Flutter 做 OpenHarmony 应用的开发者一份可以直接照着干的参考。

1. 整体设计思路与方案选型

1.1 为什么用 Flutter 做 OpenHarmony 应用

先回答一个很多人会问的问题：既然 OpenHarmony 有原生的 ArkUI 开发方式，为什么还要用 Flutter？

最直接的原因是跨端复用。项目本身已经有人在 Android 和 iOS 上用 Flutter 写了业务层，如果 OpenHarmony 端再用 ArkUI 从零写一套，那么同样的数据模型、同样的聚合算法、同样的页面布局，都要重写一遍。两个团队维护两套代码，逻辑稍微有点不同步，很容易出现“安卓上算出来的平均心率是 72，OpenHarmony 上算出来 75”这种尴尬情况。用 Flutter for OpenHarmony，业务层和 UI 层绝大部分代码可以共用，只有极少数涉及平台能力的部分需要单独适配。

另一个原因是 Flutter 自绘引擎的渲染机制。健康数据统计页面上大量使用卡片、圆角、渐变、阴影、图表，这些用 Flutter 的 Widget 体系描述起来非常顺手。OpenHarmony 的 ArkUI 当然也能实现，但对我这种从 Flutter 切过去的开发者来说，基于已有组件的迁移成本显然更低。官方没有直接提供 Flutter 支持，但社区维护的适配分支一直比较活跃，我用的是 Flutter 3.x 的一个适配版本，配合 OpenHarmony 的 SDK 使用，整体稳定性完全可以接受。

当然，选择 Flutter 也要付出一些代价，后面会详细说。最典型的就是插件生态：很多在 Android/iOS 上直接能用的第三方包，到了 OpenHarmony 上要么没有适配，要么需要手动改。所以方案选型的核心思路是：凡是纯 Dart 实现的、不依赖原生能力的东西，优先用；凡是依赖原生平台能力的东西，能少用就少用，尽量自己封装。

1.2 统计概览页的产品需求拆解

开工之前，我先把这个页面向产品要了几个关键问题的答案。统计概览不是简单地把数据堆上去，它要能快速回答用户的三个问题：

第一，今天我的身体状态怎么样？这对应“今日概览卡片”——显示今天的步数、心率、睡眠时长、血压，并且和昨天比是升了还是降了。

第二，这段趋势是好是坏？这对应“趋势图表”——按周显示体重变化折线，按月显示平均心率波动，按天显示睡眠时长柱状图。

第三，哪些指标需要提醒？这对应“达标率”——比如目标每日 8000 步，这周达标了几天，用进度环展示一个百分比。

基于这三个问题，页面结构就非常清晰了：顶部是一个今日总览卡片区，中间是各指标的详细统计卡片，底部是周/月趋势图表区域。每张卡片都有自己的数据来源和聚合逻辑，但整体页面的数据状态又需要统一管理，不能各自为政。

设计上的核心原则是“数据驱动”。用户在这个 App 其他页面新增、修改、删除一条健康记录之后，回到统计概览页，所有卡片和图表必须自动刷新，不需要手动下拉或者重启页面。这就要求状态管理方案一定要把“数据变化”和“UI更新”之间的链路打通。

1.3 图表技术选型：自绘比引用库更稳

统计页面离不开图表，而图表选型是我在 OpenHarmony 上遇到最大的一个坎。常用的 Flutter 图表库，比如 fl_chart、syncfusion_flutter_charts，在 Android 上是没问题，但在 OpenHarmony 上就不好说了。这些库底层一般会依赖手势识别、Canvas 绘制，以及一些平台通道，适配分支并不保证这些依赖都能跑通。我在试跑过程中发现，有些图表库的交互手势可以在模拟器上响应，但到了真机上就出现触摸事件不生效、饼图中心旋转失灵之类的问题。

最后我决定：核心图表全部用 CustomPaint 自绘，不用第三方图表库。这句话很多人听起来会觉得工作量很大，其实对于健康数据统计这类固定形态的图表来说，自绘反而更可控。我要画的类型很固定：折线图（体重趋势）、柱状图（每日步数/睡眠）、环形进度图（达标率）。这些图形用 Canvas 的 Path、Line、Arc 就能画出来，不需要图表库这层抽象。

自绘的好处有三个：

• 不依赖插件适配，跨平台行为一致。纯 Dart 代码，OpenHarmony 上就是 Flutter 引擎自己渲染，不存在平台通道丢失的问题。
• 性能好控制。健康指标哪怕存了三年的数据，聚合后也就是几十个点，画起来毫无压力。
• UI 完全可控。图例、网格线、拐点标注、颜色渐变，想怎么安排就怎么安排，不会被库的默认样式限制住。

当然，自绘的代价是要自己处理触摸交互。比如用户想看某个日期的体重，点一下折线图的拐点要能弹出对应的数值。这个后面在实现环节细说。

所以整个技术选型清单如下：

2. 环境构建与工程改造

2.1 搭建 Flutter for OpenHarmony 开发环境

这个部分网上资料比较少，很多教程还在按老套路走，我先把我验证过的流程说清楚。

第一步，拿到 Flutter for OpenHarmony 的适配版本。这跟普通 Flutter SDK 不一样，不能直接从官方下载普通包然后强行用于 OpenHarmony，否则会缺少 OpenHarmony 平台的打包工具链。需要从社区仓库单独拉取适配分支，而且建议直接拉代码编译，不要只下载 release 包，因为后续可能要自己修补特定痛点。

环境这块我整理一下我用到的组件：

• OpenHarmony SDK：包含 API 接口和工具链，通过设备开发工具统一管理。
• Flutter for OpenHarmony 适配分支：把原来的 flutter 命令行工具替换成适配分支里的版本。
• 项目构建工具：用于构建 OpenHarmony 的 hap 包，它需要读取 OpenHarmony SDK 的路径配置。
• 模拟器或真机：模拟器方便调试 UI，但真机测试是必需的，下面会有专门一节讲差异。

环境配置正确以后，你的 Flutter 版本和目录结构其实和普通 Flutter 项目很接近，只是在构建环节会多出一个 OpenHarmony 的 hap 包输出。一个小建议：环境变量里把 OpenHarmony SDK 路径和 Flutter 适配分支的路径都固定下来，写进备忘。否则换一台电脑或者换一个终端窗口，经常会遇到“IDE 退出后找不到 SDK”的报错。

第二步，创建项目。先用适配分支的 flutter 命令创建标准工程，执行完成后会在项目里生成标准的 pubspec.yaml 和 lib 目录。然后在这个工程基础上加入 OpenHarmony 平台目录，一般会自动生成一个类似ohos的目录，里面放着 OpenHarmony 工程的结构。如果你打不开这个目录，大概率是环境变量没配对。

第三步，配置依赖。在pubspec.yaml里只需要添加纯 Dart 的第三方库。我用到的有provider（状态管理）、intl（日期格式化，这个也是纯 Dart）。像shared_preferences这类涉及原生存储的包，虽然社区可能有适配，但我为了省事改成了自己写一个极简的文件存储工具，后面会说明。

2.2 目录结构与分层设计

工程搭好之后，我按功能模块做了分包，避免所有页面和逻辑堆在 main.dart 里。一个典型的结构大概是这样的：

lib/ ├── main.dart # 入口，配置 ProviderScope 等 ├── core/ │ ├── models/ │ │ ├── health_record.dart # 健康记录单条数据模型 │ │ └── health_metric.dart # 统计指标模型 │ ├── storage/ │ │ └── local_store.dart # 本地 JSON 存储工具 │ └── theme/ │ └── app_theme.dart # 主题、字号、间距 ├── features/ │ ├── overview/ │ │ ├── overview_page.dart # 统计概览页面 │ │ ├── model/ │ │ │ └── stats_state.dart # 统计数据状态 │ │ ├── provider/ │ │ │ └── stats_provider.dart # 页面状态管理 │ │ ├── service/ │ │ │ └── stats_aggregator.dart # 数据聚合逻辑 │ │ └── widgets/ │ │ ├── today_summary_card.dart # 今日概览卡片 │ │ ├── trend_chart.dart # 趋势折线图/柱状图 │ │ ├── progress_ring.dart # 达标率进度环 │ │ └── metric_chip.dart # 单指指标标签 │ └── record/ │ └── record_page.dart # 健康记录维护页面 └── shared/ └── utils/ └── date_utils.dart # 日期工具

这个分层强调一点：stats_provider.dart不直接操作 JSON 文件，而是通过stats_aggregator.dart聚合数据，聚合器再通过local_store.dart读取原始记录。各层职责明确，后续加数据库也好替换。

2.3 主题与字体适配的注意点

健康类 App 的界面风格通常偏清爽，我用的是白色底、圆角卡片、主色调蓝绿渐变。在 Flutter 里做这套主题设计的时候，有两点专门为 OpenHarmony 做了适配。

第一是字体。OpenHarmony 设备上的默认字体和安卓设备不完全一样，部分中文字符在强调、数字等 FontWeight 下渲染效果有差异。我直接把 App 的主题字体设置为系统默认，不开自定义字体文件，省去字体打包和版权问题。同时对数字的展示用了fontFeatures或者干脆用TextStyle(fontFeatures: [FontFeature.tabularFigures()])，强制等宽数字，避免统计数字在刷新时宽度跳动。

第二是安全区。OpenHarmony 的一些设备屏幕有挖孔或者圆角，顶部状态栏高度和底部导航区域跟常见安卓机不一样。统计概览页是全屏滚动的，必须用SafeArea包住，不然首页卡片容易顶进状态栏。这个看起来是小细节，在真机上非常影响第一印象。

3. 统计数据的聚合与状态管理

3.1 健康记录的数据模型设计

统计概览页要展示的指标很多，但底层数据结构其实很统一。我把每条健康记录设计成这样一个模型：

class HealthRecord { final String id; final DateTime date; // 记录归属日期 final HealthMetricType type; // 指标类型 final double value; // 数值 final double? secondaryValue; // 部分指标需要第二个值 final int? timestamp; // 毫秒时间戳 }

HealthMetricType是一个枚举，包含weight、heartRate、sleepDuration、bloodPressure、stepCount这几种。之所以用“枚举 + 通用字段”而不是“体重记录”和“心率记录”分开建表，是因为统计概览页需要把这些指标统一放在一个列表里滚动展示，统一模型会让聚合逻辑通用化很多。

血压稍微特殊一点，它有收缩压和舒张压两个值。我的处理是把收缩压放在value，舒张压放在secondaryValue，然后通过type == HealthMetricType.bloodPressure判断。这样模型不需要多建字段，聚合时也能拿到完整数据。

3.2 按日/周/月维度聚合的算法细节

统计的核心逻辑在StatsAggregator里。这个聚合器接收原始记录列表，返回一个结构化的统计结果，供 UI 层展示。

我的实现思路是把聚合拆成三步：过滤 -> 分组 -> 汇总。

以“近 7 天步数柱状图”为例：

第一步，过滤。从所有记录中筛选出type == HealthMetricType.stepCount并且日期在最近 7 天内的记录。这里要注意，记录中的date保存的是“自然日”维度，一条记录对应一天。如果业务上有每天更新多条的，就需要先把同一天的数据求和，再进入分组。

第二步，分组。按date把记录分到对应的日期桶里。这个操作通常用groupBy实现，但要注意键值必须是日期字符串而不是DateTime对象本身，因为DateTime的比较包含时间部分，可能导致同一天的数据被分到两个桶里。我自己封装了一个dateKey方法，统一把日期格式化成yyyy-MM-dd。

第三步，汇总。每个日期桶里如果有多条步数，就求和，如果只有一条就直接取。对于心率、体重这类趋势指标，建议取当天最后一次记录或者平均值，具体看产品要求。平均值会平滑掉波动，更像“趋势”；而取最后一个值更真实反映“当前状态”。我在项目里对体重用了“最后一次记录值”，对心率用了“全天平均”，这样页面上两条曲线的语义不同，用户不会混。

环比数据的计算也有讲究。比如“今日步数比昨日增加 25%”，分母如果为 0 会直接弹出无穷大或者界面显示异常。我的处理方式是统一判断分母小于等于 0 时返回null，UI 层发现null就显示“昨日无记录”，而不是硬算一个百分比。

3.3 Provider 状态管理的实现方式

状态管理我用的是 Provider，理由很简单：这个页面没有特别复杂的异步流程，也不需要多页面共享大量数据，ChangeNotifier完全够用。在 OpenHarmony 上少依赖外部生态反而是优势，因为 bug 排查范围更小。

核心类是StatsProvider，它继承ChangeNotifier，内部持有当前统计数据状态。页面在initState时注册一个监听，当用户从记录页修改数据返回后，调用provider.refresh()，它会重新读取存储、重新聚合、然后notifyListeners()让页面刷新。

具体代码逻辑大致是：

class StatsProvider extends ChangeNotifier { StatsState _state = StatsState.loading(); Future<void> refresh() async { final records = await localStore.fetchAll(); final stats = statsAggregator.aggregate(records); _state = StatsState.success(stats); notifyListeners(); } }

StatsState我用了一个轻量的 sealed 类概念，用枚举status+ 数据字段表示 loading/success/error。这样页面根据status渲染骨架屏、内容区或者错误重试按钮，逻辑非常直接。

关键是要注意 Provider 的刷新作用域。统计概览页如果是 tab 页，不要用Consumer包整个页面，而是在每个卡片组件外层单独包一层Consumer，这样某个指标聚合结果变化时，只重绘对应的卡片，其他卡片不会无用重建。这个优化在数据量小的时候看不出来，但记录量涨到几千条以后，性能差距很明显。

4. 统计卡片的实现细节

4.1 今日概览卡片：大数字与环比标记

今日概览是整个页面的门面，视觉上需要一眼抓住重点。我把步数、心率、睡眠、血压放在同一行卡片里，每张卡片上半部分是一个大数字，下半部分是一个趋势标记——和昨天相比是升了、降了、还是持平。

在 Flutter 里每张卡片就是一个独立的 Widget，内部接入Consumer<StatsProvider>。为了避免四张卡片同时刷新，我让每张卡片读取的指标互相独立：步数卡只select今天的步数统计，心率卡只select今天的心率统计。

这里踩过的一个坑是刷新闪烁。最开始我在卡片滑动动画里使用了AnimatedSwitcher包裹数值，导致每次从记录页返回时数字都先消失再出现，视觉上很突兀。后来改成：只在数值变化超过阈值时才触发动画，比如体重变化超过 0.1 才播放过渡效果，否则直接替换文本。这样日常“打开 App 看首页”的场景不会闪烁，只有真实变数据时才给反馈。

环比标记的颜色也做了语义区分：上升、下降使用红色和绿色，为了健康类 App 的谨慎，我特意使用“比昨天多”的箭头加数值，而不是简单套用股市涨跌的红色概念。这一点设计上要提前确认，否则容易被产品挑战。

4.2 趋势折线图与柱状图：用 CustomPaint 自绘

下面进入技术含量最高的部分：用CustomPaint绘制趋势图。我以“近 7 天体重折线图”为例拆解实现过程。

第一步，定义CustomPainter的子类。它接收已经聚合好的数据点列表，比如List<WeightPoint>，每个点包含日期和体重值。paint方法里第一件事就是计算绘图区域的宽高。这里切记要用size.width而不是直接使用逻辑像素常量，因为在不同屏幕上，可用宽度不同，自绘必须基于实际尺寸计算。

第二步，计算 Y 轴范围。体重数据可能长期在 60kg 到 65kg 之间浮动，如果 Y 轴从 0 开始，折线会变成一条贴顶的直线，毫无趋势感。我取数据里的最小值和最大值，再上下各留 2 的 padding，让折线在图表区域中占满纵向空间。同时把 Y 轴标签的格式化做好，比如显示61.5kg而不是61.49kg。

第三步，绘制网格线和坐标标签。网格线用浅灰色，每根线旁边标注一个刻度值，让用户能大致读出纵轴的数量级。横轴日期标签则每两天显示一个，避免 7 个标签挤在一起。绘制文字使用TextPainter，它是纯 Dart 实现，在 OpenHarmony 上没有问题，但注意文字的方向和居中都要手动计算。

第四步，绘制折线。把每个数据点转换为Offset，然后用Path连起来。如果是直线连接，图形很生硬，所以我用Path.cubicTo做平滑曲线连接。这里提供一个小技巧：平滑系数取 0.2 效果最自然，系数太大曲线会过冲，出现“体重回去了”的假象，系数太小就退化成直线。

第五步，绘制拐点标记。每个数据点上加一个小圆圈，再给最后一个点加一块明显的强调色，让用户一眼看到“最新体重”。如果用户触摸到了某个拐点附近，我需要显示一个垂直线和浮层。触摸命中的计算方法是：把触摸点Offset的横坐标和每个数据点的横坐标比较，找差值最小的那个。这种精度在没有图表库的情况下已经足够。

柱状图类似，只是把 Path 换成Rect。绘制时要注意柱子的宽度 = 可用宽度 / 柱数 * 0.6，左右留出空档，看起来更像产品风格而不是 Excel 截图。

4.3 环形进度图：达标率的直观展示

达标率这部分我做了“今日目标完成度”的环形进度图。例如目标 8000 步，当前已完成 6000 步，完成率 75%。UI 效果是一个圆环，完成部分用主色渐变填充，未完成部分用浅灰色背景，中间显示百分比。

原理上环形就是两个圆弧：背景环和前景环。用Canvas.drawArc绘制，注意 Flutter 的角度起点是 3 点钟方向，且角度是顺时针增加。我需要把从 0 到 100% 映射为从-pi/2开始、顺时针2 * pi * progress的圆弧。这个细节经常有人搞错，画出来进度环起点不在顶部。

中间文字用TextPainter绘制在圆心的位置。这里有一个经验：文字大小不要固定写死，应随圆环尺寸变化。最简单的方式是取圆环半径的 0.4 作为文字字体大小，这样在大屏上不显得小气、在紧凑卡片上不会溢出。

如果环形还要展示“本周达标天数”，我会改成用多个小圆点表示周一到周日，达标的点亮色，未达标的灰色，而不是整个环。这种视觉模式对“日历式的达标”特别直观，属于健康类 App 里的常见样式。

5. 真机适配、性能优化与排查实录

5.1 减少无谓重建的策略

统计概览页的数据量虽然不算大，但如果用户记录了半年每天 3 次体重，那也有几百条数据，再加上心率、睡眠、血压，总共可能到几千条。每次刷新都重新计算全部聚合逻辑，在低功耗设备上会有明显卡顿。

我的优化策略是“分级刷新”。页面首次进入时，refresh()全量读取一次，生成统计数据存入状态；后续如果只是新增一条记录，采用增量更新的方式：找到该记录对应的日期桶，重算该桶的值，然后重新跑一遍汇总。这个逻辑需要把聚合器设计成可复用的函数，参数化日期范围。

另外，图表的CustomPainter都实现了shouldRepaint方法。这个方法返回false时，Flutter 不会重绘画布，这在列表滚动时非常关键。一定要比较数据列表是否真的有变化，不要只比较引用地址，因为有时聚合结果对象被替换了但内部数值没变，这时也应该返回false。

5.2 OpenHarmony 真机与模拟器的差异点

这部分尤其重要，项目里踩出来的教训都在这。

首先是渲染性能差异。模拟器上图表滚动非常流畅，但到了中低端 OpenHarmony 真机上，如果圆角卡片使用了多层阴影，滚动时会出现明显掉帧。原因是 Flutter 的阴影在部分 GPU 驱动上会触发额外的离屏渲染。我把卡片的阴影方案从默认的BoxShadow改成自定义的浅色描边 + 少量模糊，视觉差距很小，性能提升明显。

第二是触摸事件的坐标系问题。在自绘图表中处理点击时，GestureDetector回调里的localPosition在模拟器上是正确的，但在部分真机上会偶尔偏移。我的处理是始终使用RawGestureDetector的onTapDown事件里的localPosition，不依赖全局坐标转换。实测下来这个方案稳定很多。

第三是中文字体渲染差异。同样的fontWeight: FontWeight.w500，模拟器上显示很清晰，真机上某些字符会发虚。我改成了FontWeight.w600，并针对统计数字单独用fontFeatures开启等宽属性，保证表格类的数字对得齐。

5.3 常见问题与排查技巧速查表

我整理了开发过程中真正遇到的高频问题，按主题分类：

5.4 数据存储与记录页的联动设计

统计概览页不是孤立存在的，它依赖记录页写入的数据。我采用的极简存储方案是：LocalStore维护一个 JSON 文件，每次写入都序列化整个记录列表，再追加到文件。这种方式在记录量不大时非常可靠，而且便于调试，打开文件就能直接看数据格式。

但要注意并发问题。如果用户在记录页连续写入两条数据，两次写入同时操作文件，可能产生写冲突。我的做法是把所有写入操作放进一个内存队列，串行执行。每次写入后，通过回调通知StatsProvider执行刷新。这个联动逻辑写清楚之后，统计页永远能拿到最新数据，不需要手动刷新。

联动还有一个细节：当记录页删除一条数据时，统计概览页里的“今日步数”这类 sum 指标会自动减少，这是正确的行为，但 UI 上如果有“小目标”动画，可能会显得数据在往下掉。产品上我倾向于不在这类场景播放动画，只做普通数值替换。

6. 对整体实现的复盘与几个实操体会

统计概览这个模块，从前期设计到真机调通，我最大的体会是：在 OpenHarmony 上做 Flutter 开发，控制第三方依赖比优化绘制代码更重要。很多看似高级的问题，比如图表库不兼容、触摸事件失灵、状态管理困难和插件有关，纯 Dart 的聚合逻辑和自绘 UI 基本一路顺利。所以建议所有准备入坑这个技术栈的人，先把“能不用原生插件就不用”当作铁律，凡是能自己用 Dart 解决的问题，不要偷懒引库。

几个可以直接带走的小技巧再重复一遍：第一，聚合逻辑一定要从 UI 里抽出来单独测试，统计口径变了只会改一个函数；第二，自绘画图时起点角度和坐标轴范围这两处最容易出错，先画最简数据（比如 3 个点）验证再扩展；第三，真机上的字体渲染和触摸坐标可能有问题，项目里一定要备一台 OpenHarmony 真机，不能只靠模拟器调完就提交。

如果后续你要继续做这个健康记录 App，统计概览页还可以扩展很多方向：把每周健康报告生成成一张可分享的图片、为异常波动增加提醒文案、把多维度的数据综合成一个“健康评分”等等。这些功能的底层数据能力在这套模块里已经准备好了，接下来要做的只是在聚合器上增加新的计算方法、在 UI 上增加新的卡片组件而已。

我个人在这段开发经历里，最大的收获其实是把“选型克制”这四个字刻在了脑子里。面对一个新技术平台，先用最简单可靠的方式跑通核心流程，再逐步迭代体验细节，比一上来就铺开所有 fancy 的库和框架要靠谱得多。希望你在这个项目里也能少踩坑、多出活。