图表接入最容易出问题的地方，往往不是画线，而是画线之前的数据契约。一份时间序列明明只有十几条记录，屏幕上却出现折返、尖刺和突然消失的低谷。排查渲染组件之前，应该先问三个问题：同一时刻的数据有没有被重复写入，空值是否被误当作零，压缩点数时有没有把真正重要的极值删掉。这篇用 TrendGuardDemo 的离线样例讨论图表适配层。它不绑定某一个未确认兼容性的三方图表组件，也不假设取得了设备传感器真实数据；核心交付是任何折线实现都能复用的一份、输入和输出明确的 PlotPoint[]。图中的日志与数值是设计用例，不是 DevEco 运行记录。## 一、问题不在折线，而在时间轴被污染业务侧交来一批十二条点位：每条包含毫秒时间戳 tMs、数值 value 和到达序号 arrival。页面展示十分钟内的趋势，业务值按本 Demo 的规定限制在 0～100。这个范围并不是 HarmonyOS 图表 API 的系统限制，而是示例数据格式的业务边界。生产系统需要按照温度、评分或者传感器量程重新设置。这批样例有两条非有限值：一条 NaN、一条 Infinity；10:05 还出现了两条合法记录，先到的是 69，后到的是 70。因此可计算的点先从十二条减为十条，按时间戳去重后剩九条。最后，为了让窄屏折线的采样点数确定，我们给本页制定六点展示预算。图表页最终显示 12 → 10 → 9 → 6，而不是凭肉眼猜一条平滑曲线。假如一开始便把原始数组交给图表组件，问题会被转移到组件内部：有的实现直接跳过非法数，有的会绘出不合理坐标，还有的按输入顺序连线形成时间倒走的折返。不同库对空值、重复 X 轴值的处理规则未必相同，所以数据适配层不能依靠默认行为。接入三方库的工作，首先是隔离这种不确定性。## 二、准入检查必须早于排序需要解决的问题是：让非法数据在进入图形计算之前被明确记录，而不是等到绘制失败才回头寻找。这里保留到达序号，便于在同一时间戳发生冲突时作可解释的选择。tsexport interface RawPoint { tMs: number; value: number; arrival: number;}export interface PlotPoint { tMs: number; value: number;}export function admitPoints(rows: RawPoint[]): RawPoint[] { return rows.filter((p: RawPoint): boolean => Number.isFinite(p.tMs) && Number.isFinite(p.value) && Number.isInteger(p.arrival) && p.value >= 0 && p.value <= 100 );}````Number.isFinite` 的作用是排除 `NaN`、正负无穷等非有限数值，不是判断网络数据是否可信。`arrival` 代表适配层收到数据的业务序号，不能代替可信服务端版本，更不能据此断言最后到达的数据一定准确。工程中可对非法条目记录行号、来源和原因；涉及个人数据时不要直接将完整原始记录写入 HiLog。还要特别防止把“不存在”写成“零”。零在很多趋势图中具有真实业务含义，非有限值和字段缺失则表示不能参与计算。如果简单写成 `value || 0`，合法的零和非法数就被折叠成同一类，后续很难再解释骤降。因此数据准入宁可标记缺口，也不要制造看似完整的曲线。## 三、同时间戳的取舍，需要写成团队契约第二段逻辑处理去重和时序整理。我们的示例约定：同一时间戳保留 `arrival` 最大的合格记录，再按 `tMs` 升序排列。这个决定适合“后续修订覆盖早期读数”的演示数据，不适合金融成交逐笔、具有审计要求的原始日志等需要保留全部事件的业务。tsexport function normalizePoints(rows: RawPoint[]): PlotPoint[] { const newest: Map<number, RawPoint> = new Map<number, RawPoint>(); admitPoints(rows).forEach((p: RawPoint): void => { const old: RawPoint | undefined = newest.get(p.tMs); if (old === undefined || p.arrival > old.arrival) { newest.set(p.tMs, p); } }); const unique: RawPoint[] = Array.from(newest.values()); unique.sort((a: RawPoint, b: RawPoint): number => a.tMs - b.tMs); return unique.map((p: RawPoint): PlotPoint => ({ tMs: p.tMs, value: p.value }));}````Map<number, RawPoint> 明确了一条时间戳对应一条展示记录；排序在去重之后进行，避免每次新数据进来都让原始数组反复重排。这里的复杂度主要由排序产生，适合这个小型演示序列；如果生产数据达到几十万点，应该采用有界批次和流式聚合，而不是长期持有全部历史记录。同序号重复记录是另一个边界：当前实现保留先进入 Map 的记录。若业务允许同一序号重传却内容不同，应当再增加请求 ID 或修订版本检测，并把冲突单独上报。不要为了图上只有一条线，就偷偷删除了具有业务含义的差异。展示层去重和数据源的持久化去重，也不应该混成一回事。## 四、六点预算不能牺牲峰谷在小屏幕上减少点数通常是合理的，但等步长取点并不能保证保留真正的最大值与最小值。这里采用一个非常轻量的策略：固定保留首尾记录，再把中间数据分成两组；每组按数值选择极小和极大，最后按时间重新排列。因为恰好取两组、每组两点，加上首尾，正常情况下得到六个候选点。```tsfunction extrema(bin: PlotPoint[]): PlotPoint[] { if (bin.length === 0) return []; let low: PlotPoint = bin[0]; let high: PlotPoint = bin[0]; bin.forEach((p: PlotPoint): void => { if (p.value < low.value) low = p; if (p.value > high.value) high = p; }); return low.tMs === high.tMs ? [low] : [low, high];}export function selectForPreview(points: PlotPoint[]): PlotPoint[] { if (points.length <= 6) return points.slice(); const interior: PlotPoint[] = points.slice(1, points.length - 1); const cut: number = Math.ceil(interior.length / 2); const picked: PlotPoint[] = [points[0], ...extrema(interior.slice(0, cut)), ...extrema(interior.slice(cut)), points[points.length - 1]]; picked.sort((a: PlotPoint, b: PlotPoint): number => a.tMs - b.tMs); return picked;}```这不是 LTTB，也不是平台自带的通用降采样接口，而是一条故意保持简单、便于审查的应用规则。它在六点预算下能保留每个分段里的数值极值，却不能保证波形面积、斜率、周期频率或视觉感知误差最小。若图表需要连续缩放与大数据分析，应选择经过验证的多分辨率聚合方案，并保留未经压缩的源数据。本轮样例可被整理成九条规范点，再选出六条：10:00 71、10:02 74、10:03 70、10:05 70、10:08 72、10:09 74。这些是预置输入经过上述算法推导出的期望值；图中出现同样的数字，不能证明它们经过设备端实际执行。要验证实现，应把这些输入写进独立测试，逐条断言结果顺序、数量和峰谷归属。![](https://i-blog.csdnimg.cn/direct/492ab301664749a7a6190d3343e71ccf.png)## 五、三方组件只接收稳定输出适配接口建议放在 entry/src/main/ets/adapter/TrendAdapter.ets，页面放在 entry/src/main/ets/pages/TrendReviewPage.ets。业务页只消费 PlotPoint[]，并持有自己的 CHART_R05_01批次标识和PLOT_READY状态。真正引入三方图表前，先阅读目标版本的 ohpm 元数据、HarmonyOS SDK 兼容声明和组件文档；本篇没有为一个未核实的库编造setSeries()或renderChart() 方法。对异步源还需增加快照边界。数据查询在时间范围发生变化后，即使旧请求稍晚返回，也不应该覆盖新的查询区间。最简单的工程做法是在业务页面创建递增查询代次，在提交计算结果前再次比较代次。这里故意没有把业务代次写成平台 API，避免与三方图表内部缓存机制混淆。日志应围绕可复核的转变而不是“绘制成功”四个字：CHART_R05_01 raw=12 admitted=10 unique=9 plotted=6、invalid=2 duplicate=1、status=PLOT_READY。若对接真实流数据，再加上输入窗口、修订号、异常比例和渲染耗时，但耗时必须实测，不能把设计目标填进诊断栏当结果。![](https://i-blog.csdnimg.cn/direct/1b171441ae2b43a08e0917dc9f0e8f45.png)## 六、验证顺序与适用边界先以十二条固定样例验证“非法值过滤→同时间戳修订→时间升序→分段极值”的每一道输出，再改变顺序随机打散输入，检查同一批次是否得到相同结果。然后分别测试全非法数组、单条数据、六条以内、重复序号冲突和全部值相等等边界；等这些都稳定，再去评价图表组件本身的动画与布局。遇到异常时应把准入计数和展示计数分开记录，避免把“点数少了”误判为丢帧。释放方面，页面离开后应终止自身的数据订阅、定时器和请求回调，并清理三方组件实例中由应用创建的资源；具体销毁方法取决于实际选定的库，不能假定所有图表库暴露同一个 dispose`。对于屏幕外不可见的图表，应控制重绘频率，防止仍按高频流输入做无意义渲染。这套处理值得保留的不是某个六点公式，而是明确的责任分界：原始数据可以不完美，适配层必须可解释，图表组件才有资格只负责画图。它适用于轻量趋势预览，不适用于需要逐事件审计或高精度信号还原的场景。示例代码尚未在真实 DevEco 工程中编译；运行截图和日志均为与预置数据一致的静态技术演示。资料核对：HarmonyOS 官方 DevEco Studio 工具说明、三方依赖管理及 oh-package.json5 文档；ArkTS 基础数值运算与排序属于应用业务代码，本文不宣称其为 HarmonyOS 专有图表 API。参考链接：DevEco Studio 工具概述；oh-package.json5 配置。