行情表格实时通知合并

修复提交

仓库	分支	Commit ID	说明
`harmony-ths-futures-apm-oom`	`work-20260820-clz-FUHM-1979-apm-oom`	`909ab7e83795ca418138da81dc8273c29046ce55`	合并同一事件循环内的行情表格实时通知

问题

TableRequestClient.notifyDataReceive() 原先会为每条行情通知创建一个 setTimeout 回调，并将对应的 TableData 闭包保存在待执行回调中。实时推送频繁、UI 线程暂时繁忙时，同一轮事件循环内可能堆积多个回调，每个回调都引用一份完整表格数据，放大瞬时 Local Heap 占用。

优化方案

将待通知状态改为单个定时器 ID 和最新一份 TableData | string。
新数据到达时仅覆盖待发送数据；已有定时器时不再创建新的回调。
定时器执行时读取并清空最新数据，再按既有请求生命周期版本校验后通知 UI。
请求切换和释放时取消该定时器并清空待通知数据，避免异步回调继续引用旧表格。

影响范围

仅修改 lib_baseUI 中 TableRequestClient 的通知调度方式。
表格解析、实时订阅、请求参数和 UI 回调接口均不变。
同一事件循环内 UI 只接收最新一份表格数据；中间的过期快照不再逐份分发。

预期收益与边界

待执行通知从“每条推送一个闭包”收敛为“一个定时器加一份最新数据”，降低高频行情期间短时间内同时存活的完整表格数量，并避免页面切换后遗留的待通知数据。

该优化会合并同一事件循环内的中间 UI 刷新，因此不保证逐条推送都触发一次 UI 回调；最终展示的数据保持为最新快照。网络接收、表格解析和实时订阅的吞吐不受本次修改限制。

验证结果

使用现有依赖直接执行 Hvigor assembleHap，构建成功；子线程导入检查通过。
在 Pura 90 模拟器安装并启动应用，进入“行情 → 国内”，在“全部主力 / 能源”之间连续切换 20 轮，列表持续正常渲染。
离开行情页后查询应用崩溃日志，未发现 JS Crash 或 CppCrash。
同次验证临时记录了请求切换清理计数：每轮旧订阅由 2 降至 1、请求缓冲由 4 降至 3，且待通知数为 0；验证日志已删除，未纳入正式代码。

2.4 KiB Raw Blame History