38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
# 行情表格实时通知合并
|
|
|
|
## 修复提交
|
|
|
|
| 仓库 | 分支 | Commit ID | 说明 |
|
|
| --- | --- | --- | --- |
|
|
| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `909ab7e83795ca418138da81dc8273c29046ce55` | 合并同一事件循环内的行情表格实时通知 |
|
|
|
|
## 问题
|
|
|
|
`TableRequestClient.notifyDataReceive()` 原先会为每条行情通知创建一个 `setTimeout` 回调，并将对应的 `TableData` 闭包保存在待执行回调中。实时推送频繁、UI 线程暂时繁忙时，同一轮事件循环内可能堆积多个回调，每个回调都引用一份完整表格数据，放大瞬时 Local Heap 占用。
|
|
|
|
## 优化方案
|
|
|
|
1. 将待通知状态改为单个定时器 ID 和最新一份 `TableData | string`。
|
|
2. 新数据到达时仅覆盖待发送数据；已有定时器时不再创建新的回调。
|
|
3. 定时器执行时读取并清空最新数据，再按既有请求生命周期版本校验后通知 UI。
|
|
4. 请求切换和释放时取消该定时器并清空待通知数据，避免异步回调继续引用旧表格。
|
|
|
|
## 影响范围
|
|
|
|
- 仅修改 `lib_baseUI` 中 `TableRequestClient` 的通知调度方式。
|
|
- 表格解析、实时订阅、请求参数和 UI 回调接口均不变。
|
|
- 同一事件循环内 UI 只接收最新一份表格数据；中间的过期快照不再逐份分发。
|
|
|
|
## 预期收益与边界
|
|
|
|
待执行通知从“每条推送一个闭包”收敛为“一个定时器加一份最新数据”，降低高频行情期间短时间内同时存活的完整表格数量，并避免页面切换后遗留的待通知数据。
|
|
|
|
该优化会合并同一事件循环内的中间 UI 刷新，因此不保证逐条推送都触发一次 UI 回调；最终展示的数据保持为最新快照。网络接收、表格解析和实时订阅的吞吐不受本次修改限制。
|
|
|
|
## 验证结果
|
|
|
|
1. 使用现有依赖直接执行 Hvigor `assembleHap`，构建成功；子线程导入检查通过。
|
|
2. 在 Pura 90 模拟器安装并启动应用，进入“行情 → 国内”，在“全部主力 / 能源”之间连续切换 20 轮，列表持续正常渲染。
|
|
3. 离开行情页后查询应用崩溃日志，未发现 JS Crash 或 CppCrash。
|
|
4. 同次验证临时记录了请求切换清理计数：每轮旧订阅由 2 降至 1、请求缓冲由 4 降至 3，且待通知数为 0；验证日志已删除，未纳入正式代码。
|