3.5 KiB
3.5 KiB
交易 SDK 成交推送去重与排序优化
修复提交
| 仓库 | 分支 | Commit ID | 说明 |
|---|---|---|---|
harmony-ths-futures |
work-20260818-clz-FUHM-1979-apm-appfreeze |
ce0719178530b5ca64272c6c1e90b5bcdb8297fc |
接入本地 libs/FuTrade-1.0.13-match-push-opt.har（含成交推送去重与排序） |
harmony_futures_trade_sdk |
feature/FUHM-1979-match-push-optimization |
9e56923cfaadb14fff0fa928cabe4e5aef615490 |
优化成交推送处理（去重与稳定排序） |
harmony_futures_trade_sdk |
feature/FUHM-1979-match-push-optimization |
31256eff45b51a96551a2ba8f2b31bb02e4258af |
优化推送缓存查重 |
SDK 侧成交推送去重/排序来源于 harmony_futures_trade_sdk 仓库上述源码提交，本仓库以本地 HAR 携带，接入提交见上表首行。
问题
成交推送进入 MatchOrderSummary.updateMatchOrders() 时，旧逻辑需要遍历全部成交记录判断重复成交，并在每次新增后对完整数组执行一次排序。成交推送频繁或历史成交较多时，会重复消耗 CPU，并增加成交列表更新的耗时。
优化方案
- 在
MatchOrderSummary中增加Set<string>，缓存已有成交的matchIdentify().identify。重复推送直接通过Set.has()过滤，避免遍历成交数组。 - 首次新增推送仍执行完整排序，确保查询结果初始顺序不确定时可以恢复到成交排序规则。
- 首次排序完成后，后续推送使用二分查找确定插入位置，再插入
matchOrderRsps，避免每次对全部成交记录重新排序。 - 二分插入在比较结果相同时继续向后查找，使相同成交时间和开平方向的记录保持稳定顺序。
- 增加单元测试，覆盖重复成交、稳定排序插入和不同账号推送过滤。
影响范围
- 交易 SDK 的成交汇总、成交推送和成交列表排序。
- 当前项目通过本地
libs/FuTrade-1.0.13-match-push-opt.har使用该版本，依赖配置位于根目录oh-package.json5。 - 成交量、平仓盈亏、盯市平仓盈亏的汇总规则不变。
- 账号过滤规则和成交唯一标识规则不变；
Set仅用于查重，不参与成交列表排序。
预期收益与边界
重复推送判断由数组遍历变为近似 O(1)，后续新增成交由全量排序变为二分查找加数组插入。优化主要针对高频成交推送和较大历史成交列表，业务展示顺序不应发生变化。
matchOrderRsps 仍是公开可变数组。如果外部代码直接修改、排序或替换数组内容，可能导致成交数组、去重 Set 和有序状态不一致；业务代码应通过 SDK 的成交汇总接口读取，避免直接修改该数组。初始查询数据中的重复项也不会由本次改动主动清理。
验证建议
单元测试
在交易 SDK 的 FuTrade 模块运行 MatchOrderSummary 测试，确认以下场景：
- 相同成交推送只保留一条，汇总值不重复增加；
- 首次推送后成交记录按既有时间和开平方向规则排序；
- 后续推送插入到正确位置，相同排序值保持稳定顺序；
- 不同账号的成交推送被过滤；
- 空初始列表、白盘/夜盘边界和不同开平方向均可正常插入。
当前项目验证
确认 oh-package.json5 指向本地 HAR 后，执行：
./claude_tool/claude_compile.sh
并在成交页面回归查询成交、接收新成交推送、重复推送和账号切换，检查成交条数、成交量、盈亏汇总及列表顺序均保持正确。