Skip to content

案例 B-04:从占位曲线到双 Y 轴图表

内容类型:案例难度:进阶适合:需要在 WPF 中实现多轴实时图表的开发者阅读时间:约 7 分钟前置:已了解界面原型和实时数据显示基础

最初使用 Canvas / Polyline 并不一定错误。原型阶段只需要证明布局和视觉方向时,轻量占位比过早引入复杂图表库更快。

问题出现在需求升级后:开始需要真实坐标轴、单位、图例、双 Y 轴、缩放或较高刷新负载,此时“继续堆占位逻辑”才可能变成维护负担。

1. 先问:当前还是原型,还是已经进入真实数据展示?

原型阶段

目标通常只是:

  • 曲线区域大概放在哪里;
  • 页面密度是否合适;
  • 两组数据视觉上如何区分。

这时不必提前解决:

  • 高性能实时刷新;
  • 导出;
  • 游标;
  • 多轴联动;
  • 海量点数。

真实展示阶段

需求需要具体化:

text
Series:
Voltage / Current / ...

X Axis:
Index / Time / Frequency / Other

Y Axes:
单位、范围、自动/固定

Update:
FrameReplace / SlidingWindow

Load:
点数、刷新率、通道数、运行时长

没有这些事实,只说“做一个工业实时曲线”还不足以选库。

2. 双 Y 轴什么时候真的有必要

双 Y 轴通常适合:

  • 两组数据共用同一 X 语义;
  • Y 量纲不同,例如 V 和 A;
  • 或数值范围差异大到同轴会严重压缩其中一条曲线。

不适合只是为了“看起来专业”就加双轴。

必须让用户能清楚知道:

  • 哪条线属于左轴;
  • 哪条线属于右轴;
  • 单位是什么;
  • 缩放/自动范围后对应关系是否仍清楚。

3. 图表库不要按品牌印象选

历史版本曾写过“工业实时优先某库、MVVM 优先另一库”。这类结论会随着版本、授权、API 和项目要求变化,不适合作为长期固定规则。

更稳定的选型维度是:

维度要验证什么
WPF/.NET 兼容当前目标框架是否稳定支持
多轴双 Y 轴、多 Series 是否满足需求
数据规模当前点数/刷新率下 CPU、内存和延迟
更新模型是否适合 FrameReplace / SlidingWindow
交互缩放、游标、图例、导出是否需要
MVVM 集成是否能与当前架构自然集成
授权当前版本的许可是否符合项目交付
维护API 稳定性、团队熟悉度、升级成本
部署是否引入额外原生依赖或运行环境要求

具体库可以作为候选,但最终选择应以当前版本文档 + 小型 PoC + 实测结果为依据,而不是 star 数、流行度或过去项目印象。

4. 先做小 PoC,不要先把正式页面重写

高影响库选型适合做一个很小的验证:

text
相同测试数据
相同窗口大小
相同点数
相同刷新周期
相同两条 Series / 双 Y 轴

记录:

text
CPU
Working Set
UI p95 latency / render time(能测则测)
功能缺口
集成复杂度
授权限制

PoC 只回答“这个库能不能满足当前需求”,不需要先接真实设备。

5. 性能不能写“看起来不卡”

“刷新不明显卡顿”只能作为人工体验描述,不能成为性能结论。

如果性能是正式要求,应建立基线:

text
Test Data: 2 series × 5000 points
Refresh: 10 Hz
Duration: 60 min
Window: 1920×1080

再记录前后:

text
CPU
Working Set
UI latency
GC / allocation trend(必要时)

如果项目没有正式性能指标,可以保守写:

在当前 PoC 负载下未观察到明显交互阻塞。

而不是写“性能优秀”“满足长稳要求”。

对应方法:性能与长稳诊断

6. 图表数据仍然遵守三层生命周期

text
Persistent Data
Working Set
Display Window

图表库只能决定 Display Window 怎么画,不能顺手成为正式数据存储。

同样,图表需要降采样也不意味着正式数据可以一起降采样。

详见 ADC 曲线固定窗口刷新

7. 什么时候保留 Canvas / Polyline 反而更合理

如果需求只是:

  • 静态趋势示意;
  • 很少的点;
  • 无坐标交互;
  • 不需要多轴、缩放、导出;

继续使用简单实现可能比引入大型依赖更合理。

“成熟图表库”不是自动更专业。依赖越多,发布、许可、升级和长稳验证成本也越高。

8. 选型决策什么时候需要 ADR

只有同时满足:

  1. 未来很难替换;
  2. 不知道背景的人会觉得选择很意外;
  3. 确实比较过多个真实方案并做了取舍;

才值得写 ADR。

普通页面从一个简单控件换成另一个,并不自动需要 ADR。

9. 本案例推荐的验证层次

V1

  • 页面布局;
  • 轴标题和单位;
  • 图例归属;
  • 无数据状态。

V2

  • 真实数据模型接入;
  • FrameReplace / SlidingWindow 行为;
  • 配置变化;
  • 数据单位和时间轴一致。

Performance

  • 当前负载基线;
  • 长时间 UI/内存趋势;
  • 多通道压力。

HardwarePending

真实设备输入节奏尚未验证时明确保留,不因为模拟数据流畅就宣布现场性能通过。

10. 本案例最值得保留的经验

  1. 原型占位不是技术债本身。 需求升级以后再判断是否需要正式图表能力。
  2. 先确定数据语义,再选控件。 双轴只是表达方式,不是需求本身。
  3. 选库看当前版本和实测。 不把某个品牌写成长期默认答案。
  4. 性能有基线才有结论。 “不卡”不是工程指标。
  5. 显示窗口不等于正式数据。 图表优化不能污染采集和追溯。
  6. 依赖本身也有成本。 授权、部署、升级和团队维护都属于选型证据。

相关方法

下一步

别来无恙 · C# 上位机 AI 实战站 · 从零到交付 · QQ 群:1016188499