docs: add stability remediation evidence

2026-08-24 17:13:00 +08:00
commit b5d837cc45
20 changed files with 912 additions and 0 deletions
@@ -0,0 +1,35 @@
+# Repository Guidelines
+
+## Project Structure & Scope
+
+This repository is an evidence bundle for HarmonyOS futures-app freeze and OOM remediation; it does not contain buildable application source code.
+
+- `harmony-ths-futures-freeze/doc/change-notes/` contains freeze/performance remediation notes, numbered `01`–`11`.
+- `harmony-ths-futures-apm-oom/doc/change-notes/` contains memory-retention remediation notes, numbered `10`–`15`.
+- `change-notes.zip` is the distributable archive of those two directories. Keep it synchronized only when a deliverable archive is requested.
+
+Treat notes as technical records: distinguish changes made in the app, communication HAR, and trade SDK repositories, and do not imply that an upstream change is present here.
+
+## Documentation Style & Naming
+
+Write Markdown in Chinese, matching the existing material. Use direct `#` and `##` headings and concise paragraphs. New notes should follow the established numbered, kebab-case pattern, for example `12-new-memory-audit.md`.
+
+Use fenced code blocks for commands and backticks for paths, module names, APIs, package versions, branches, and commit IDs. Preserve exact measurements, units, dates, device details, and command output; identify estimates and limitations explicitly. Prefer tables for baseline-versus-result comparisons.
+
+## Validation and Development Commands
+
+There is no local build, formatter, linter, or test suite. Do not run application builds from this repository. Record validation performed in the relevant upstream HarmonyOS checkout, for example:
+
+```sh
+devecocli build --modules entry@default
+devecocli check lint
+devecocli log --crash --bundle-name <bundle-id>
+```
+
+State whether each command was actually run, its target (module/device), and any skipped coverage. Do not present a suggested command as a completed verification.
+
+## Change Notes and Review
+
+Each remediation note should include: the fix commit(s) and branch(es), problem statement, changed scope, implementation/mitigation, behavior and risk boundaries, and concrete verification results. Keep unrelated cleanup and temporary test artifacts out of documented production changes.
+
+This bundle has no Git metadata, so no local commit-message convention can be inferred. Use a short imperative subject such as `docs: add table request cleanup note`. Pull requests should name the affected upstream repository and commit, link the incident or ticket when available, and include before/after metrics or screenshots/log excerpts for behavior claims.
@@ -0,0 +1,44 @@
+# 行情表格请求切换的订阅与缓冲清理
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `5f6e007c7f431521350a68543c4db5314a8c644f` | 修复 `TableRequestClient` 订阅泄漏 |
+| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `2ca4759c4e0212b4c80c41b94a0ae1339569e89c` | 完善请求切换时的统一清理逻辑 |
+
+## 问题
+
+行情列表通过 `TableRequestClient` 发起请求，并在带 `newrealtime=1` 的请求中向 `RealDataManager` 注册实时订阅。请求队列映射、实时订阅和请求缓冲分别以 instanceId、instanceId、`frameId + pageId + instanceId` 关联。
+
+原有 `setPageId()` 先覆盖成员 `pageId`，再移除请求队列映射；随后无法获得旧 instanceId，也没有同步清理旧实时订阅与旧请求缓冲。切换行情分组时，`RealDataManager` 可能持续持有旧表格订阅并合并推送数据，造成 Local Heap 持续增长，最终有 OOM 风险。
+
+## 优化方案
+
+1. `setPageId()` 在覆盖成员前保存旧 `pageId`，递增请求生命周期版本并取消待执行通知，再统一解绑旧请求。
+2. 新增私有 `detachCurrentRequest(oldPageId)`：调用 `RequestQueueManagement.removeByClient(this)` 原子取得并移除旧 instanceId 映射；当旧 ID 有效时，用该 ID 移除 `RealDataManager` 订阅，并以旧 `pageId` 删除对应请求缓冲。
+3. `removeSubscriber()` 与 `release()` 复用同一解绑逻辑，避免多个生命周期出口清理策略不一致。
+4. 保留既有异步版本校验和 `setTimeout` 取消逻辑，防止过期解析结果或通知闭包继续持有表格数据。
+
+## 影响范围
+
+- 仅修改 `lib_baseUI` 的 `TableRequestClient` 请求切换和释放生命周期。
+- 不修改协议报文、请求参数、表格解析、实时数据合并或 UI 展示逻辑。
+- 请求未建立队列映射时，清理操作保持幂等并直接返回。
+
+## 预期收益与边界
+
+每次行情分组切换和页面销毁都会同时释放旧请求的队列映射、实时订阅及请求缓冲，避免孤儿订阅继续持有全量表格并接收实时推送，从而抑制 Local Heap 随切页线性增长。
+
+该修改只治理 `TableRequestClient` 链路的引用滞留；图形内存、Web、Native/CPP 堆及其他业务模块的内存增长仍需按各自链路继续分析。`removeSubscriber` 与缓冲删除均按旧 instanceId 执行，因此不会误删新请求。
+
+## 验证建议
+
+1. 执行 `devecocli build --modules entry@default`，确认 ArkTS 编译和打包通过。
+2. 安装新 HAP 后，在“行情 → 国内”页的“全部主力 / 能源”等分组间连续切换 20～50 次，再离开列表页。
+3. 使用临时调试计数验证每次切换后旧订阅和旧请求缓冲各减少一项，待执行通知数归零；验证完成后不保留计数日志或缓冲快照统计代码。
+4. 检查应用崩溃日志，并结合 APM/HiLog 观察 Local Heap 在循环切换期间不再线性增长。
+
+## 本次验证结果
+
+在模拟器上完成 20 次同一活跃 `TableRequestClient` 的分组切换：每轮旧订阅数由 2 降至 1、请求缓冲数由 4 降至 3，待执行通知数始终为 0；离开行情列表后订阅数由 1 降至 0。未发现该应用的崩溃日志。上述计数日志仅用于本次验收，已从正式代码移除。
@@ -0,0 +1,37 @@
+# 行情表格实时通知合并
+
+## 修复提交
+
+| 仓库 | 分支 | 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；验证日志已删除，未纳入正式代码。
@@ -0,0 +1,42 @@
+# 交易 SDK 市价缓存去重与正确删除
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony_futures_trade_sdk` | `feature/FUHM-1979-match-push-optimization` | `fbfb85d704510fcbe94d1c58f732e0add4a76292` | 修复市价缓存重复写入和删除失效 |
+
+## 问题
+
+交易 SDK 的 `DefaultMarketPriceCacheCenter` 使用数组保存 `ContractMarketPrice`。原有 `removeCache()` 误用 `slice(i, 1)`，该调用只返回数组片段，不会修改原数组，因此已消费的缓存节点仍被单例缓存中心长期持有。
+
+原有 `cachePrice()` 对相同 `ContractBean + MarketPriceType` 的价格也会无条件新增节点。交易页反复取价或刷新时，同一缓存键会持续产生重复对象；即使业务调用删除，旧节点仍无法从数组移除，导致缓存数组和 Local Heap 随调用次数增长。
+
+## 优化方案
+
+1. `removeCache()` 使用 `splice(i, 1)` 原地删除命中的缓存节点。
+2. `cachePrice()` 写入前查找相同合约和价格类型；命中时只更新最新价格并返回，不再追加重复节点。
+3. 验证阶段由主工程临时接入本地构建的 `FuTrade.har`，并在当前已安装依赖源码中同步修复，以支持不执行 `ohpm install` 的直接 Hvigor 构建；压力测试、测试入口和本地联调改动均不进入正式提交。
+
+## 影响范围
+
+- 生产代码修改位于兄弟仓库 `../harmony_futures_trade_sdk/FuTrade` 的市价缓存中心。
+- 主工程不修改交易协议、报价来源或下单流程；正式依赖仍保持 `1.0.13`，待交易 SDK 发布包含该修复的新版本后再升级版本号和锁定结果。
+- 缓存键仍为既有的 `ContractBean + MarketPriceType`；不同合约或价格类型之间不会互相覆盖。
+
+## 预期收益与边界
+
+相同缓存键连续更新时，缓存节点数量从随调用次数线性增长收敛为最多一个；缓存被消费后会立即从数组移除。以本次 100 万次重复更新为例，节点数由潜在的 100 万个降至 1 个，删除后降至 0，重复节点消除率接近 100%。
+
+根据 `ContractMarketPrice` 的对象字段、数组引用和价格字符串开销保守估算，100 万次重复更新可避免约 60～120 MB 的常驻堆增长；20 万次缓存/删除循环可避免约 12～24 MB 的残留。实际 PSS 和 JS Heap 收益受 Ark Runtime 对象布局、字符串表示及 GC 时机影响，仍应以修复前后的同场景 Profiler Trace 为准。
+
+该修改只治理交易 SDK 市价缓存数组的重复节点和错误删除，不覆盖全局行情请求缓冲、实时订阅、整表解析与 UI 全量刷新等其他 OOM 链路。
+
+## 验证结果
+
+1. `FuTrade@default` 构建成功并生成新的 `FuTrade.har`；主工程 `entry@default` 和 `entry@ohosTest` 均通过直接 Hvigor 构建。
+2. 在 Pura 90 模拟器执行 100 万次相同缓存键更新，耗时 148 ms；最终读取到最新价格，删除后缓存为空。
+3. 在同一测试进程执行 20 万次缓存/删除循环，耗时 90 ms；循环结束后缓存为空。
+4. Instrumented Test 共执行 4 个用例，结果为 `Pass 4 / Failure 0 / Error 0`，总测试耗时 239 ms。
+5. 测试完成后未发现 `com.hexin.plat.hmn.futures` 的 OOM、JS Crash 或 CppCrash 记录。
+6. 提交前已清理主工程的本地 HAR 路径、`oh_modules` 同步修改、临时 Instrumented Test 接入和 SDK 测试代码，避免提交不可移植的联调依赖或压力测试代码。
@@ -0,0 +1,37 @@
+# WebView 行情总览销毁时释放请求 Client
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `da5599387d82f06256e9224eb8c8001410de1a6b` | 补齐总览页面销毁解绑并断开 bridge 引用 |
+
+## 问题
+
+`OverViewEvent` 只处理 WebView 前后台切换，没有注册页面销毁回调。三个行情 client 已登记到全局 `RequestQueueManagement` 并写入请求缓冲后，如果 WebView 直接销毁，全局队列仍可能持有 client，client 又反向持有 `WebViewJavaScriptBridge`，形成跨页面 retained reference。
+
+## 优化方案
+
+1. 注册 `addAboutToDisappearCallBack()`，页面销毁时统一调用 `stopRequest()`。
+2. `stopRequest()` 在取消三个请求后清空每个 client 的 bridge 引用和 `OverViewEvent` 成员引用，使重复调用保持幂等。
+3. 销毁回调最后清空 `OverViewEvent.webViewJSBridge`，切断事件对象到 WebView bridge 的引用。
+
+## 影响范围
+
+- 仅修改行情总览 JS 事件的销毁生命周期。
+- 不修改三个行情协议的 frameId、pageId、请求文本、解析或回调数据结构。
+- 前后台恢复行为保持不变；已收到 JS 事件时仍会在回到前台后重新创建请求。
+
+## 预期收益与边界
+
+每次总览页销毁会确定释放 3 个请求 client、对应请求缓冲和队列映射，避免其随反复进出页面线性累积。实际节省内存取决于 bridge、请求参数和页面对象引用图，本次没有设备堆快照，因此不估算具体 MB 或百分比。
+
+该修复只覆盖 `OverViewEvent` 的三条行情请求，不代表其他 WebView JS 事件或全局行情链路已全部完成生命周期审计。
+
+## 验证结果
+
+1. 对实际 `OverViewEvent.ets` 转译后使用模拟 bridge、请求缓冲和队列执行 20,000 轮“注册 → 发起 3 个请求 → 页面销毁”；每轮销毁后 retained request 为 0、retained client 为 0。
+2. 使用直接 Hvigor 构建 `entry@default` Debug HAP 成功，完整 ArkTS 编译、HAP 打包和签名通过；未执行安装。
+3. 临时压力测试文件和日志已删除，生产代码未保留计数、测试入口或调试日志。
+4. 确认“行情 → 总览”页面可加载；主 Tab 切换只改变前后台状态，不销毁 `OverViewPage`，当前产品入口无法在不终止 Ability 的情况下重复触发本修复的页面销毁回调，因此未将主 Tab 循环冒充为 `OverViewEvent` 销毁验证。
+5. 同次设备测试检查应用 Crash 日志及近 20 分钟错误日志，未发现 OOM、JS Crash、CppCrash、SIGSEGV 或 SIGABRT。
@@ -0,0 +1,41 @@
+# 通信 SDK 跨 Frame 请求缓冲清理与 HAR 接入
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `ohos_mobile_lib_communication` | `work-freeze-lib-communication-1.1.1` | `4784e4698a3d335471f275fd7c8dd9c113323b78` | 清理旧 frame 请求缓冲及关联客户端 |
+| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `da5599387d82f06256e9224eb8c8001410de1a6b` | 替换主工程本地通信 HAR |
+
+## 问题
+
+通信 SDK 在 `frameId` 变化时调用的 `clearRequestPageList()` 为空实现，导致旧 `_sReqList`、`_sTempReqBuff`、`_sTemqReqList` 和队列 client 引用继续保留。重复请求还可能通过 instance 映射形成伴随 client，仅删除主 instance 不能完整释放引用链。
+
+## 优化方案
+
+1. SDK 在切换 frame 时收集旧缓冲的全部 instanceId，释放主 instance 及其伴随 instance。
+2. 清空三个缓冲并重置当前 frame，再按原流程写入新 frame。
+3. 保留切换前已登记的新 client，不使用破坏范围更大的全局队列清空。
+4. 构建新的 `lib_communication.har` 并替换主工程 `libs/lib_communication20250903.har`；依赖版本仍为 `1.1.1-beta.1`，lockfile 不变。
+
+## 影响范围
+
+- SDK 修改位于 `../ohos_mobile_lib_communication/lib_communication`。
+- 主工程只替换本地通信 HAR，不修改调用 API 或请求协议。
+- `HQ2RequestManager`、实时行情整表复制和 UI 全量解析不在本次范围。
+
+## 预期收益与边界
+
+跨 frame 切换后，请求缓冲由历史 frame 累积收敛为仅保留当前 frame；旧请求文本和 client 引用不再随切页次数线性增长。压力测试 20,000 轮后缓冲仍为 1 项，说明该场景的历史缓冲残留消除率为 100%。
+
+上述结论只针对测试中的缓冲项和 client 计数，不等同于整进程 PSS 降幅；图片、Web、Native 堆及行情整表分配仍可能影响 OOM。
+
+## 验证结果
+
+1. SDK 实际源码压力测试执行 20,000 轮，每轮创建两个相同请求 client 并切换 frame；最终请求缓冲为 1、当前活跃 client 为 2，旧主/伴随 client 均为 0。
+2. 直接 Hvigor 构建 SDK Release HAR 成功，耗时 9.145 秒；接入产物 SHA-256 为 `b6919758c15761d5f9f75dcc0bf608d6ab2b46bd5ada9c92ddf1237be8b39621`。
+3. 主工程直接 Hvigor 构建 `entry@default` Debug HAP 成功，耗时 34.940 秒；未执行 `ohpm install`、安装或启动。
+4. 临时 API 24 配置、压力测试代码和日志均已清理；因本机缺少 API 20 SDK，API 20 构建与设备 OOM/PSS 验证未执行。
+5. 2026-08-21 在 Pura 90 API 24 模拟器执行有效的首页、行情、交易、发现四 Tab 定向循环 20 轮，每次切换等待 1 秒；进程持续存活，Crash 日志中未发现 OOM、JS Crash、CppCrash、SIGSEGV 或 SIGABRT。
+6. 设备有效循环前 Total PSS / ArkTS heap PSS / Native heap PSS 分别为 562,024 / 110,843 / 211,017 kB；20 轮后空闲 15 秒分别为 679,879 / 199,328 / 244,622 kB。整进程内存未回到基线，且生产包没有请求缓冲计数能力，因此该设备结果不能单独证明跨 frame 缓冲已释放，也不能据此将剩余增长归因于本链路；缓冲收敛结论仍以 20,000 轮白盒计数测试为依据。
+7. 首次尝试因首页 VIP 广告遮挡底部 Tab，点击未实际切页，该组数据已作废且未计入上述 20 轮结果。
@@ -0,0 +1,43 @@
+# 广告悬浮球 PixelMap 与 Dialog ID 生命周期清理
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures-apm-oom` | `work-20260820-clz-FUHM-1979-apm-oom` | `da5599387d82f06256e9224eb8c8001410de1a6b` | 释放广告 PixelMap、失效异步创建并清空 ID |
+
+## 问题
+
+`AdsBallManager` 创建完整图和半图 PixelMap 后未保存并显式释放所有权。任一图片加载失败时，另一张已成功创建的 PixelMap 会直接遗漏；弹窗销毁也只 dismiss dialog，不释放 Native 图片资源。`floatBallIds` 使用只增不删的数组，主题切换和广告刷新会长期保留历史 ID。
+
+异步图片加载期间如果发生新的创建或销毁，旧任务还可能在完成后覆盖新弹窗，使旧图片和 dialog 生命周期错配。
+
+## 优化方案
+
+1. manager 明确持有当前完整图和半图 PixelMap，并在 dialog dismiss 后延迟 300 ms 释放，避免关闭动画仍使用图片。
+2. 单图失败、弹窗 show 失败和异步任务过期时立即释放已创建但未展示的 PixelMap。
+3. 使用 generation 标记使旧异步创建失效，避免旧结果覆盖新弹窗。
+4. `floatBallIds` 改为 `Set<string>`，销毁后清空；兜底 dismiss 仍按历史登记 ID 匹配当前页面 dialog。
+5. 对同一 PixelMap 被同时作为完整图和半图的异常情况只调用一次 `release()`。
+
+## 影响范围
+
+- 仅修改首页广告悬浮球的图片与 dialog 生命周期管理。
+- 不修改广告数据、图片地址、展示样式、点击行为或 300 ms 创建防抖。
+- 延迟释放只持有已 dismiss 的当前两张图片 300 ms，避免立即释放与弹窗关闭动画竞争。
+
+## 预期收益与边界
+
+成功展示的每个悬浮球最多持有当前 2 张 PixelMap，销毁后释放；单图失败不再残留另一张；ID 集合在销毁后归零。Native 图片内存收益取决于图片尺寸、像素格式和系统解码缓存，本次未取得真实图片尺寸与设备 PSS，因此不估算具体 MB。
+
+该修复不治理其他广告弹窗、网络图片缓存、系统图形缓存或 GPU/DMA 内存，也不代表 Native PSS 会在 release 后立即同步下降。
+
+## 验证结果
+
+1. 对实际 `AdsBallManager.ets` 转译后执行 5,000 轮成功创建/销毁、5,000 轮半图失败和 1 轮异步过期压力测试。
+2. 共创建 15,001 个模拟 PixelMap，全部恰好释放一次；最终 retained dialog ID 为 0、retained dialog 为 0。
+3. 新实现随主工程通过直接 Hvigor `entry@default` Debug HAP 构建，完整 ArkTS 编译、打包和签名成功；未执行安装。
+4. 压力测试中将 300 ms 延迟计时器同步触发以校验所有权计数；真实设备关闭动画时序、Native PSS 回落和 OOM 日志未验证。
+5. 临时压力测试代码与日志已删除，未在生产代码中保留调试计数。
+6. 2026-08-21 在 Pura 90 API 24 模拟器确认首页 VIP 广告真实展示并成功关闭，关闭后底部 Tab 恢复可操作；同次测试未发现 OOM、JS Crash、CppCrash、SIGSEGV 或 SIGABRT。
+7. 本次设备操作只完成 1 次真实广告展示/关闭，未取得 PixelMap Native 归属计数，也未完成 50～100 轮重复广告创建，因此不宣称真实设备 Native PSS 稳态已经验证；重复释放正确性仍以 15,001 个模拟 PixelMap 的白盒压力测试为依据。
@@ -0,0 +1,38 @@
+# 通信库源码联调依赖说明
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `ohos_mobile_lib_communication` | `work-freeze-lib-communication-1.1.1` | `031d4cf221b4da6d9aaf2db443ba293559a0d4a5` | 通信 Worker 解码与队列优化（本说明所支撑的修复） |
+
+> 本笔记为通信库源码联调/依赖说明，非生产修复本身；其支撑的修复见 `03`、`04`。
+
+## 目的
+
+解压与曲线修复基于 `lib_communication` `1.1.1-beta.1`，基线提交为 `7d3f126`，与应用原有 `lib_communication20250903.har` 的源码版本一致。性能验证期间曾将相邻仓库中的通信模块复制到当前工程 `lib_communication/`，以便临时加日志、打点和抓取 trace。
+
+## 修改文件
+
+- `oh-package.json5`
+- `build-profile.json5`
+- `base_ugc/oh-package.json5`
+- `biz_forecast/oh-package.json5`
+- `service_aigroup/oh-package.json5`
+- `lib_communication/`
+
+## 接入配置
+
+验证期间，根依赖和 `overrides` 使用 `file:./lib_communication`，模块内直接依赖使用 `file:../lib_communication`，根 `build-profile.json5` 将其注册为 HAR 模块。构建 `entry` 时直接编译这份通信源码。
+
+新增 Worker 的运行时导入闭包在验证期间按最小范围登记到子线程门禁：
+
+- `ConcurrentDecodeWorker.ts -> @ohos.worker`
+- `ConcurrentDecodeWorker.ts -> HXZip.ts`
+
+## 影响与风险
+
+本地源码保留原公开接口，包含 Worker 解压和曲线解析实现。该目录仅用于性能验证，不应作为正式交付方式。验证结束后已删除根 `build-profile.json5` 中的模块注册，并将根工程及三个业务模块的依赖恢复为 `libs/lib_communication20250903.har`。
+
+## 验证
+
+同一源码构建的通信库 debug HAR 及 `entry@default` debug HAP 均已完成构建、安装和运行验证。三轮 A/B 测试确认主线程 CPU 时间中位数下降 20.2%，详细数据见 `06-communication-worker-ab-performance.md`；正式交付仍需发布并接入包含修复的新版 HAR。
@@ -0,0 +1,45 @@
+# 网络响应 XML 异步解析
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `e16813f86b8dbabcf6e6e4a18df72c80c69cc9db` | 认证 XML 解析迁移至 TaskPool（`ConcurrentXmlParser`） |
+
+## 背景与目标
+
+Top 20 冻屏日志中，主线程采样命中 Upass 响应的 GBK 解码和 `XmlPullParser.parse()`。进一步扫描发现验证码响应、账户手机号查询也在通信回调中同步解码并解析 XML。本次统一将三条活动链路迁移到 TaskPool，避免响应体异常放大时阻塞主线程。
+
+## 修改范围
+
+- `biz_common/src/main/ets/utils/xml/ConcurrentXmlParser.ets`
+- `biz_hxservice/src/main/ets/cookie/UpassSessionNetClient.ets`
+- `biz_auth/src/main/ets/auth/verifycode/CheckCodeLoginClient.ets`
+- `biz_auth/src/main/ets/auth/UserQueryClient.ets`
+- `claude_tool/subthread-import-guard/subthread-import-policy.json`
+
+`biz_auth/src/main/ets/auth/UpassSessionNetClient.ets` 未发现导出或调用关系，属于当前不可达的遗留实现，本次不修改。
+
+## 通用方案
+
+新增 `parseXmlAttributes()` 并发方法，参数为原始字节、字符编码、目标属性列表和可选结束标签。TaskPool 内完成文本解码与 XML 扫描，统一关闭 DOCTYPE；没有指定结束标签时，获取全部目标属性后立即停止。主线程只处理返回值，不向子线程传递业务对象。
+
+三处调用配置：
+
+- Upass：`gbk`，提取 `sessionid`。
+- 验证码：`gbk`，提取 `code`、`msg`，遇到 `wlh_thsreg_modify` 结束标签停止。
+- 用户查询：`utf-8`，提取 `ckmobile`。
+
+并发入口只包含 `@ohos.util` 和 `@ohos.xml` 两条运行时依赖边，已精确登记到子线程导入策略。
+
+## 功能影响
+
+- Upass SessionId 获取、持久化及 Cookie 建立。
+- 手机号登录或注册时的验证码结果回调。
+- 登录完成或推送更新时的账户手机号回填与偏好存储。
+
+请求协议、公开回调接口和存储键不变。解析失败会进入原有失败处理；用户查询异步期间若发生用户切换，会丢弃旧响应。验证码日志不再输出完整 XML，只记录状态码和消息。
+
+## 验证
+
+`node claude_tool/subthread-import-guard/check-subthread-imports.mjs` 已通过：通用入口包含 1 个本地闭包文件和 2 条运行时依赖边。按当前要求未执行完整编译。运行期仍需覆盖 Upass 登录态、验证码成功/失败、手机号回填、用户切换和损坏 XML 场景，并确认主线程采样栈不再出现 XML 解析热点。
@@ -0,0 +1,59 @@
+# 通信解压迁移至 Worker
+
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `ohos_mobile_lib_communication` | `work-freeze-lib-communication-1.1.1` | `031d4cf221b4da6d9aaf2db443ba293559a0d4a5` | `HXZip` 解压与曲线解析迁移到通信 HAR 内持久 Worker，并重构队列分发 |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `ce0719178530b5ca64272c6c1e90b5bcdb8297fc` | 重建并接入 `libs/lib_communication20250903-worker-opt.har` |
+
+## 目的
+
+冻屏采样栈显示主线程在 `HXZip.unzip()` 及解压后的行列转置循环中持续执行。压缩行情包越大，阻塞时间越长。
+
+## 线上真实数据补充
+
+2026-08-21 补充的 TOP10 耗时函数线上统计中，通信库仍有两条采样命中：
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 1 | `writeReceiveTime entry\|@kernel/lib_communication\|1.1.1-beta.1\|src/main/ets/components/communication/protocol/MiniDataHead.ts` | 1 | 2 | 600ms |
+| 2 | `anonymous entry\|@kernel/lib_communication\|1.1.1-beta.1\|src/main/ets/request/QueueManagement.ts` | 1 | 2 | 600ms |
+
+这两条不是 `HXZip.unzip()` 本身，但说明同一通信回调链路在线上仍能出现在主线程耗时采样中。`writeReceiveTime()` 只是写包头的短函数，单点优化价值低；`QueueManagement` 当前仍通过 `Map` 全量遍历完成注册、映射和分发查找，后续可将 `instanceId -> clients` / companion 映射拆成索引，减少行情响应分发阶段的线性扫描。
+
+## TOP20 线上数据补充
+
+同日 TOP20 统计中，通信库出现同一条分层回调链：
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 7 | `anonymous entry\|@kernel/lib_communication\|1.1.1-beta.1\|.../handler/Response...` | 59 | 590 | 177000ms |
+| 8 | `fireConnectionRead entry\|@kernel/lib_communication\|1.1.1-beta.1\|.../connection/Abstract...` | 58 | 580 | 174000ms |
+| 9 | `connectionRead entry\|@kernel/lib_communication\|1.1.1-beta.1\|.../communication/handler/...` | 58 | 580 | 174000ms |
+| 10 | `invokeChannelRead entry\|@kernel/lib_communication\|1.1.1-beta.1\|.../connection/Abstract...` | 58 | 580 | 174000ms |
+
+上述 4 项是同一次通信管线逐层转发的采样帧，不能将 699000ms 视为 4 个独立耗时问题。统计来自旧版 `1.1.1-beta.1`；当前工程已接入 Worker 解码和队列索引优化 HAR，需用新包重新采样确认是否仍上榜。
+
+## 修改文件
+
+- `lib_communication/.../protocol/ConcurrentDecodeClient.ts`
+- `lib_communication/.../protocol/ConcurrentDecodeWorker.ts`
+- `lib_communication/.../protocol/MobileDataProcessor.ts`
+- `lib_communication/.../protocol/ReceiveDataProcess.ts`
+- `lib_communication/.../handler/ResponseStructDecodeHandler.ts`
+- `lib_communication/build-profile.json5`
+
+以上修改基于相邻的 `ohos_mobile_lib_communication` 源码仓库，验证时临时复制到当前工程，验证结束后已移除。
+
+## 实现
+
+通信库主体为 `.ts`，不能直接导入只允许在 `.ets` 中声明的 `@Concurrent` 任务。因此改为复用一个 HAR 内持久 Worker，通过请求 ID 匹配结果，在 Worker 中完成 `HXZip` 解压及行列转置。解码调用链改为异步；每个 `ResponseStructDecodeHandler` 使用 Promise 队列串行处理响应，避免并发完成导致消息乱序。
+
+## 影响与风险
+
+主线程只负责组装 `HXDataInputStream` 和继续分发。Worker 参数与结果均为可序列化的基础类型或 `Uint8Array`。单次消息仍受 16 MB 序列化限制，Worker 异常会拒绝等待中的请求，响应队列捕获错误后继续处理后续消息。
+
+## 验证
+
+基于 `1.1.1-beta.1` 的通信库 HAR 和默认 debug HAP 已构建、安装并完成行情周期切换验证。三轮 A/B 测试中，主线程 CPU 时间中位数下降 20.2%，8 ms 以上连续运行片段减少 53.3%；详细结果与限制见 `06-communication-worker-ab-performance.md`。
@@ -0,0 +1,33 @@
+# 曲线解析迁移至 Worker
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `ohos_mobile_lib_communication` | `work-freeze-lib-communication-1.1.1` | `031d4cf221b4da6d9aaf2db443ba293559a0d4a5` | `HXZip` 解压与曲线解析迁移到通信 HAR 内持久 Worker |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `ce0719178530b5ca64272c6c1e90b5bcdb8297fc` | 重建并接入 `libs/lib_communication20250903-worker-opt.har` |
+
+## 目的
+
+冻屏日志显示曲线解析在主线程执行 `points × fields` 双重循环，并反复完成整数读取与 HXLong 浮点转换，是曲线点数较大时的 CPU 热点。
+
+## TOP20 线上数据补充
+
+TOP20 的 TOP7–TOP10 命中的是通信响应读取、连接转发和通道回调的分层函数，没有直接命中曲线解析函数。由于这些函数属于同一条响应管线，不能据此证明曲线解析仍是独立瓶颈；当前 Worker 版本的收益仍需使用新包按曲线大包场景重新采样确认。
+
+## 修改文件
+
+- `lib_communication/.../protocol/ConcurrentDecodeClient.ts`
+- `lib_communication/.../protocol/ConcurrentDecodeWorker.ts`
+- `lib_communication/.../protocol/MobileDataProcessor.ts`
+
+## 实现
+
+扩展数据仍按原逻辑解析；剩余曲线字节、字段类型和点数提交给通信 HAR 内的持久 Worker。子线程保持原协议的小端读取、`MD_TYPE_MASK` 分支、HXLong 符号/指数/空值语义，返回按字段排列的数值列。宿主线程仅按字段 ID 重建 `dataTable` 和 `typeTable`。
+
+## 影响与风险
+
+公开的 `StuffCurveStruct` 数据结构不变，重复字段 ID 仍以后出现的列为准。若实际单包接近 Worker 的 16 MB 序列化上限，需要进一步改为分块或共享缓冲区。
+
+## 验证
+
+基于 `1.1.1-beta.1` 的通信库 HAR 和默认 debug HAP 已构建、安装并完成行情周期切换验证。当前结果证明通信解析阶段的主线程负载下降，但 `CurveView` 刷新耗时和超时帧没有稳定改善；详细结果与限制见 `06-communication-worker-ab-performance.md`。
@@ -0,0 +1,57 @@
+# 交易 SDK Native 锁竞争应用侧优化
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `d04f7720c13b130bd9bdab69109d6a93c6edcfca` | 应用侧减少交易 SDK Native 锁竞争（`FuturesApiInterceptor`/`TradeApiManager`） |
+| `futures_trade_sdk`（原生 lib-weituosdk） | `work-clz-FUHM-1979-native-lock-opt` | `1ba241ef8d9aae16dde1b0c4e406d6cd41cca216` | 链接复用计数由 `recursive_mutex` 改为 `std::atomic`，降低锁竞争 |
+
+Native 锁优化 SO（`futures-trade-sdk-so-1.2.0-lock-opt.har`）由上述 SDK 提交构建（lib-weituosdk 的 `futures_spi_api_manager.cpp`/`futures_quants_spi.cpp`/`.h`）。应用侧止血见上表首行；本工程 `oh-package.json5` 指向该 SO 的接入改动尚未提交。
+
+
+
+## 问题
+
+冻屏日志显示，主线程调用交易 SDK 时阻塞在 `getReuseSpiApiByMode`、`hasLoggingInRequest` 等 Native 锁上。高频入口包括交易请求发送前检查和自动重登检查。
+
+## 线上真实数据补充
+
+2026-08-21 补充的 TOP10 耗时函数线上统计中，交易 SDK 发送链路仍被采样命中：
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 7 | `sendMsg entry\|@b2c-f/futures_ohos_trade_sdk\|1.0.13\|src/main/ets/trade/api/rpc/RspSendMsgCenterImpl.ts` | 1 | 10 | 3000ms |
+| 4 | `isNumber entry\|@b2c-f/futures_ohos_trade_sdk\|1.0.13\|src/main/ets/trade/util/StringUtil.ts` | 1 | 2 | 600ms |
+
+`sendMsg()` 是交易请求进入 SDK/Native 的关键同步入口，和本 notes 记录的 Native 锁竞争止血方向一致。`isNumber()` 为短函数，单独看不像根因，更可能是交易列表或请求参数处理链路中的采样帧；应结合完整调用栈判断是否被 `sendMsg()` 或列表刷新长任务包裹。
+
+同日 TOP20 统计进一步命中交易 SDK 的两组调用链：
+
+| TOP | 函数/调用链 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 1–4 | `getReuseIpForLogin → getRequestIpForLogin → libweituo_sdk_ohos.so` | 75 | 750 | 900000ms（分层重复采样） |
+| 5–6 | `FuturesApiInterceptor.interceptSendMsg*` | 67/64 | 670/640 | 201000/192000ms |
+| 11–18 | `enqueue → awaitEnqueue → innerEnqueue → startSendRequest → proceedSendMsg` | 47–48 | 470–480 | 141000–144000ms/项（分层重复采样） |
+| 19–20 | `TradeApiManager.tryToReLoginAccount` 及其匿名闭包 | 44 | 440 | 132000ms/项 |
+
+TOP1–4 和 TOP19–20 共同指向自动重登录入口的同步复用 IP 查询；TOP11–18 是同一请求链的多层采样，不能直接累加为独立损耗。该 TOP20 文件记录的是旧版 `1.0.11/1.1.1`，当前工程已接入 `1.0.13/1.2.0` 锁优化 SO；应用侧仍保留首次同步 `getReuseIpForLogin()` 风险，需新包线上复采确认。
+
+## 优化方案
+
+1. 删除 `FuturesApiInterceptor` 中无实际拦截效果的请求前检查。原逻辑会在每次交易请求前同步查询登录中、在线状态，但两个判断分支中的拦截代码均已注释。删除后不改变当前请求行为，同时避免业务请求重复进入 Native 锁域。
+2. `TradeApiManager` 按交易账号复用正在执行的重登 Promise。同一账号由认证、交易页或推送重复触发重登时，只执行一次 SDK 登录，其余调用复用结果并保留各自成功、失败回调。
+3. 在线检查和复用连接查询前先判断该账号是否正在重登，避免登录过程中再次同步查询 Native 状态。
+
+## 影响范围
+
+- 交易接口发送、自动重登、推送触发的在线检查和交易页切换重登。
+- 不修改交易 SDK、Native SO、登录参数、失败重试次数及成功/失败业务处理。
+- 不将 SDK 对象迁移到 Worker 或 TaskPool，不改变其线程归属。
+
+## 预期收益与边界
+
+优化可减少主线程进入交易 SDK 互斥锁的频率，并阻止同账号重复登录放大锁竞争。`tryToReLoginAccount` 首次判断仍需调用一次 `getReuseIpForLogin`，因此这属于应用侧止血；彻底消除锁等待仍需要 SDK 缩小 Native 锁范围并发布新的 SO。
+
+## 验证建议
+
+在持续发送交易请求时反复执行断网重连、前后台切换、推送唤起和交易账号切换，确认同账号并发登录数不超过 1，并检查冻屏主线程栈中是否仍出现 `mutex::lock → getReuseSpiApiByMode/hasLoggingInRequest`。
@@ -0,0 +1,39 @@
+# 通信 Worker A/B 性能验证
+## 验证对象（对应修复）
+
+该验证针对 `HXZip` 解压与曲线解析迁移至 Worker 的收益，属于笔记 `03`、`04` 的量化回放，完整修复提交见 `03`/`04`（`ohos_mobile_lib_communication` `031d4cf221b4da6d9aaf2db443ba293559a0d4a5`、`harmony-ths-futures` `ce0719178530b5ca64272c6c1e90b5bcdb8297fc`）。
+
+## 验证目标
+
+对比 `lib_communication` `1.1.1-beta.1` 在同步解压/曲线解析与 Worker 异步处理下的主线程负载。测试只评价通信解压和曲线解析改造，不包含 XML、交易 SDK 或图表绘制优化。
+
+## 测试方法
+
+- 时间：2026-08-18
+- 设备：Pura 90 手机模拟器，`127.0.0.1:5555`
+- 页面：国内行情“乙二醇2609”详情页
+- 操作：依次点击 `1分 -> 5分 -> 15分 -> 日K -> 分时`，连续执行 3 组，共 15 次切换
+- 轮次：旧同步版和 Worker 新版各 3 轮；每轮重新启动应用进程并采集 20 秒 hitrace
+- 分析：使用 DevEco `trace_streamer` 转换为 SQLite，统计目标进程 `lat.hmn.futures` 的主线程调度片段
+
+## 测试结果
+
+下表使用三轮中位数，括号内为三轮范围。
+
+| 指标 | 旧同步版 | Worker 新版 | 变化 |
+| --- | ---: | ---: | ---: |
+| 主线程 CPU 时间 | 2959 ms（2923～3309） | 2361 ms（2330～2512） | -20.2% |
+| 进程总 CPU 时间 | 3765 ms（3731～4201） | 3075 ms（3069～3250） | -18.3% |
+| 主线程 `>= 8 ms` 连续运行片段 | 30 次（23～36） | 14 次（14～17） | -53.3% |
+| 主线程调度片段 P99 | 5.747 ms（5.304～5.865） | 4.644 ms（4.452～4.692） | -19.2% |
+| 主线程最大连续运行片段 | 23.698 ms（13.252～31.006） | 19.360 ms（12.924～24.345） | -18.3% |
+
+## 结论与限制
+
+Worker 改造使主线程计算量下降约 20%，8 ms 以上连续运行片段减少一半以上，主要收益是降低大包解压和曲线解析占用主线程导致的冻屏风险。
+
+`CurveView` 刷新总耗时中位数由 221.5 ms 变为 236.0 ms，没有稳定改善。超过 16.67 ms 的帧中位数由 9 次变为 13 次，帧尾部数据也未呈现一致收益。因此本次结果不能解释为整体帧率提升，优化范围仅限通信解析阶段。
+
+自动框架识别未生成应用绘帧记录，因此未套用 ArkUI 丢帧分类结果。后续建议在真机上使用固定响应包、增加解压和曲线解析起止 trace 点，并扩大轮次，以进一步隔离网络波动、模拟器调度和图表渲染噪声。
+
+原始 trace 和 SQLite 数据未纳入仓库，测试时临时保存在 `/tmp/sdk-worker-ab.psA7Sp/`。
@@ -0,0 +1,63 @@
+# 交易 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，并增加成交列表更新的耗时。
+
+## 线上真实数据补充
+
+2026-08-21 补充的 TOP10 耗时函数线上统计没有直接命中 `MatchOrderSummary.updateMatchOrders()`，但命中了同属交易 SDK 的 `RspSendMsgCenterImpl.sendMsg()`：1 次故障、10 次调用、总耗时 3000ms。该数据不能证明成交推送优化已覆盖此线上样本，只能说明交易 SDK 1.0.13 仍存在主线程高频 SDK 调用采样；成交推送优化需要继续依赖新 HAR 接入后的成交推送专项回归和新日志闭环。
+
+TOP20 统计同样没有直接命中 `MatchOrderSummary.updateMatchOrders()`。TOP11–TOP18 命中的是交易请求发送链的 `enqueue/awaitEnqueue/proceedSendMsg` 分层函数，属于请求排队和发送链路，不足以证明成交推送去重与排序优化已经生效或失效；仍需通过成交推送专项采样验证。
+
+## 优化方案
+
+1. 在 `MatchOrderSummary` 中增加 `Set<string>`，缓存已有成交的 `matchIdentify().identify`。重复推送直接通过 `Set.has()` 过滤，避免遍历成交数组。
+2. 首次新增推送仍执行完整排序，确保查询结果初始顺序不确定时可以恢复到成交排序规则。
+3. 首次排序完成后，后续推送使用二分查找确定插入位置，再插入 `matchOrderRsps`，避免每次对全部成交记录重新排序。
+4. 二分插入在比较结果相同时继续向后查找，使相同成交时间和开平方向的记录保持稳定顺序。
+5. 增加单元测试，覆盖重复成交、稳定排序插入和不同账号推送过滤。
+
+## 影响范围
+
+- 交易 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 后，执行：
+
+```bash
+./claude_tool/claude_compile.sh
+```
+
+并在成交页面回归查询成交、接收新成交推送、重复推送和账号切换，检查成交条数、成交量、盈亏汇总及列表顺序均保持正确。
@@ -0,0 +1,55 @@
+# 交易页前台在线状态查询改为读缓存
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `8c3170778f50bf767c9146ea177e82080d629da2` | 交易页前台在线状态改为读缓存 `currentAccount.isOnline` |
+
+## 问题
+
+冻屏日志聚类 20020090（3 次）：应用切回前台触发 `TradePage.isAbilityForeGroundChanged()` 时，主线程同步调用 `ApiCommon.isOnlineAccount()`，经 JSI 桥穿透到 `libweituo_sdk_ohos.so` 的 `SpiApiManager::getLoginSuccSpiApi` 并等待 `recursive_mutex`。当 SDK 网络线程（asio 断线/连接回调链路）持有该锁时，主线程卡在 `__timedwait_cp` 等锁 3.1/6.2 秒，3S/6S 抓栈逐帧一致，触发冻屏上报。
+
+交易 SDK 1.0.13 的 `TradeAccount` 已维护应用侧在线状态：登录成功（`setLoginSuccess`）、断网（`checkAccountOnline`）、重登成功/失败（`TradeApiManager`）及退出登录（`resetUnLogined`）时经 `updateOnlineStatus()` 更新 `isOnline` 字段并广播 `ACCOUNT_ONLINE_STATUS_CHANGED` 事件。交易页已监听该事件，前台切换所需的"是否在线"用缓存即可回答，无需同步穿透 Native 查询。
+
+## 线上真实数据补充
+
+2026-08-21 补充的 TOP10 耗时函数线上统计中，交易页前台链路仍被采样命中：
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 10 | `onForeground entry\|biz_trade\|1.0.0\|src/main/ets/views/tab/TradeGuaDanListView.ts` | 1 | 10 | 3000ms |
+
+该样本不是 `TradePage.isAbilityForeGroundChanged()` 的同一函数，但同属交易页前台恢复路径。当前 `TradeGuaDanListView.onForeground()` 会立即触发 `GuaDanViewModel.sendRequest()`，其中包含条件单标签查询和挂单查询；如果前后台切换、刷新和交易推送相互叠加，仍可能造成主线程连续调度和 SDK 请求入口放大。后续可对前台刷新增加去重、节流或复用正在进行的查询。
+
+## TOP20 线上数据补充
+
+TOP20 未直接命中 `TradeGuaDanListView.onForeground()`，但命中了交易页自动重登录入口：
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 19 | `tryToReLoginAccount entry\|biz_trade\|1.0.0\|.../TradeApiManager.ts` | 44 | 440 | 132000ms |
+| 20 | `anonymous entry\|biz_trade\|1.0.0\|.../TradeApiManager.ts` | 44 | 440 | 132000ms |
+
+该结果说明前台恢复、推送和交易页刷新仍可能汇聚到自动重登录链路，但两个函数属于同一入口的分层采样，不能重复计为两项独立耗时。`TradePage` 的在线状态查询已改为读缓存；`TradeApiManager` 的同步复用 IP 查询仍需结合新版 SDK 线上采样继续确认。
+
+## 优化方案
+
+1. `TradePage.isAbilityForeGroundChanged()` 中的 `ApiCommon.isOnlineAccount(currentAccount)` 替换为读缓存 `currentAccount.isOnline`。
+2. 删除 `TradePage` 中不再使用的 `ApiCommon` import（全文件仅此一处使用）。
+
+## 影响范围
+
+- 交易页前台切换时在线状态判断的数据来源，由 Native 同步查询改为应用侧缓存。
+- 条件单查询时机不变：在线时立即 `checkConditionTriggeredForCurrentAccount()`，离线时置 `needQueryConditionTriggeredAfterTradeLogin`，登录成功后由 `onTradePushLoginResult`、切换账户后由 `onTradeLogin` 补查。
+- 不修改交易 SDK、Native SO、`isOnline` 状态的维护链路及其事件广播。
+
+## 预期收益与边界
+
+消除该主线程等锁入口，前台切换不再同步进入交易 SDK 锁域。`isOnline` 为应用侧维护状态，SDK 断线回调尚未到达的极短窗口内可能读到旧值，最多导致多查一次条件单（请求失败无害）；彻底消除等锁风险仍需要 SDK 缩小 Native 锁范围并发布新的 SO。
+
+## 验证建议
+
+1. 执行 `./claude_tool/claude_compile.sh` 编译通过。
+2. 真机登录后反复前后台切换，确认条件单查询行为与改动前一致，hilog 中不再出现主线程 `isLoggedInAccount` 同步调用。
+3. 断网后回前台、恢复网络、重登成功，确认 `onTradePushLoginResult` 兜底补查条件单的路径正常。
+4. 检查冻屏主线程栈中是否仍出现 `mutex::lock → SpiApiManager::getLoginSuccSpiApi`。
@@ -0,0 +1,35 @@
+# 画线绘制候选集去重 O(n²) → O(n)
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `hmdrawlinebasicsdk` | `work-clz-fuhm-1979-drawline-dedup` | `c3f8e6bc2ca44af9afa9bf0163d88d2508d55a0a` | 画线绘制候选集去重 O(n²)→O(n) |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `ce0719178530b5ca64272c6c1e90b5bcdb8297fc` | 接入 `libs/drawlinebasic-1.2.1-dedup-opt.har` 及主工程 overrides |
+
+## 问题
+
+冻屏聚类 20020217（5 次）、20020340（3 次）：主线程栈停在 `DrawingApiImpl.appendUniqueLines → findIndex → isSameLine`。`drawLines()` 每帧渲染都会调用 `getLinesToDraw()` 重建绘制候选集，其中 `appendUniqueLines` 用 `source.forEach` 嵌套 `target.findIndex` 判重，复杂度 O(n·m)。画线数量较多或跨周期线合并时，主线程持续繁忙触发 3S/6S 冻屏上报。
+
+判重语义（原 `isSameLine`）：同对象引用、本地 ID 或远端 ID 任一非空且相等即判为同一条线。注意本地 ID 不同但远端 ID 相同的两条线也判同一条，因此不能用单一 key 去重。
+
+## 优化方案
+
+1. `appendUniqueLines` 改为三个 Set（对象引用 `refSet`、本地 ID `localIdSet`、远端 ID `lineIdSet`）一次遍历完成判重，复杂度降为 O(n)；判重语义与原 `isSameLine` 逐条等价，目标列表插入顺序不变；原私有方法 `isSameLine` 随之删除。
+2. 补丁基于 `hmdrawlinebasicsdk` 仓库 `feature-zyh-20260708-FUHM-1578-cross-period` 分支（画线 SDK 1.2.1 的发布源，与 ohpm 发布包源码树逐字节一致；master 仍为 1.1.2，无此代码），仓库内 commit `c3f8e6b`，本地构建产物为 `libs/drawlinebasic-1.2.1-dedup-opt.har`。
+3. 主工程三处接入：根 `oh-package.json5` 依赖与 `overrides`、`biz_quote/oh-package.json5` 依赖均改为 `file:` 引用本地 HAR。`overrides` 同时将 `drawlinepane@1.1.0` 传递依赖的 `drawlinebasic@1.2.0` 强制指向同一本地 HAR，保证最终产物只有一份 drawlinebasic。
+
+## 影响范围
+
+- 仅画线绘制候选集的去重实现；画线数据模型、持久化、云端合并、绘制样式与命中逻辑不变。
+- 每帧绘制候选集重建仍会分配三个 Set，列表本身不缓存；进一步可考虑按 cache 版本缓存合并结果（本次未做）。
+
+## 预期收益与边界
+
+候选集去重由 O(n·m) 降为 O(n)，画线数量越大收益越明显，直接消除该冻屏聚类的热点函数。判重语义与原实现逐条等价（含"本地 ID 不同但远端 ID 相同判同一条"的边界情形），重复描边、线条层级行为不变。画线 SDK 侧彻底根治仍建议上游将 `getLinesToDraw` 的合并结果按缓存版本缓存，避免每帧重建。
+
+## 验证建议
+
+1. 执行 `./claude_tool/claude_compile.sh` 编译通过。
+2. 真机在画线较多（数十条以上）的 K 线页面滑动、切换周期，确认绘制行为与改动前一致，冻屏主线程栈不再出现 `appendUniqueLines → findIndex`。
+3. 回归跨周期画线：新建、云端合并、编辑态切换、删除场景下无重复描边，线条层级与命中结果不变。
+4. 检查最终产物中 `@b2c-f/drawlinebasic` 仅存在一份（overrides 生效）。
@@ -0,0 +1,39 @@
+# TOP10 线上耗时函数后续候选项
+## 修复说明
+
+本笔记为线上 TOP10 耗时函数的分析、候选项与建议修复顺序，未包含生产修复本身；候选的实现见 **`11-top10-followup-fixes.md`**（对应本仓库 commit `0d10cf71a01c8c5d875ca4c950d6d2fd71d3fd42`）。
+
+## 数据来源
+
+2026-08-21 从 `~/Downloads/TOP10耗时函数列表.md` 补充线上真实 TOP10 耗时函数统计。该列表是函数采样聚合，不等价于完整冻屏根因；短函数命中通常表示它处在更长的调用链上，需要结合完整 faultlog/采样栈判断。
+
+| TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
+| ---: | --- | ---: | ---: | ---: |
+| 1 | `writeReceiveTime entry\|@kernel/lib_communication\|1.1.1-beta.1\|src/main/ets/components/communication/protocol/MiniDataHead.ts` | 1 | 2 | 600ms |
+| 2 | `anonymous entry\|@kernel/lib_communication\|1.1.1-beta.1\|src/main/ets/request/QueueManagement.ts` | 1 | 2 | 600ms |
+| 3 | `anonymous entry\|@b2b/hq_table\|1.0.0-rc.9\|src/main/ets/model/data/TableDataSource.ts` | 1 | 10 | 3000ms |
+| 4 | `isNumber entry\|@b2c-f/futures_ohos_trade_sdk\|1.0.13\|src/main/ets/trade/util/StringUtil.ts` | 1 | 2 | 600ms |
+| 5 | `transFormServerColor entry\|@b2c/lib_baseui\|1.0.0\|src/main/ets/utils/ColorUtils.ts` | 1 | 2 | 600ms |
+| 6 | `isArbitrageEnabled entry\|biz_trade\|1.0.0\|src/main/ets/trade/manager/TradeCustomTabManager.ts` | 1 | 4 | 1200ms |
+| 7 | `sendMsg entry\|@b2c-f/futures_ohos_trade_sdk\|1.0.13\|src/main/ets/trade/api/rpc/RspSendMsgCenterImpl.ts` | 1 | 10 | 3000ms |
+| 8 | `showOrderNameCell entry\|biz_trade\|1.0.0\|src/main/ets/views/tab/ContractNameCellView.ts` | 1 | 4 | 1200ms |
+| 9 | `anonymous entry\|biz_futures_chart\|1.0.0\|src/main/ets/view/View.ts` | 1 | 6 | 1800ms |
+| 10 | `onForeground entry\|biz_trade\|1.0.0\|src/main/ets/views/tab/TradeGuaDanListView.ts` | 1 | 10 | 3000ms |
+
+## 当前判断
+
+- `hq_table` 表格数据合并是优先级最高的新增候选：`TableDataSource.notifyDataSetChanged()` 仍在主线程逐行 merge、创建默认行并触发可见行更新，TOP3 达到 10 次调用、3000ms。
+- `lib_communication` 队列管理仍有结构性优化空间：`QueueManagement` 通过遍历 `Map<ITCPClient, Map<InstanceId, InstanceId[]>>` 完成注册、删除、映射和分发查找，可改为维护 `instanceId` 索引减少线性扫描。
+- `biz_trade` 套利开关可做缓存：`isArbitrageEnabled()` 会进入 `TradeFunctionSwitch.isSupportArbitrageTrade()` 和 `GrayTestManager.isFeatureEnable()`，灰度命中时包含日志和 `JSON.stringify(grayConfig)`，不适合在列表构建中高频调用。
+- `ContractNameCellView.showOrderNameCell()`、`ColorUtils.transFormServerColor()`、`StringUtil.isNumber()` 和 `BaseView` 绘制/布局闭包本身都较短，当前不应只针对短函数微调，应先定位其上层列表刷新、图表刷新或交易请求链路。
+
+## 建议修复顺序
+
+1. 在 `hq_table` 源码侧优化 `TableDataSource.notifyDataSetChanged()`：减少全量行合并、只更新可见区、批量合并 `notifyChange()`，必要时将可 Sendable 的数据预处理继续前移到子线程。
+2. 在通信 SDK 源码侧重构 `QueueManagement` 索引：新增 `instanceId -> clients` 和 companion 映射，保留原公开接口，避免响应分发时扫描全部客户端。
+3. 在 `TradeCustomTabManager` 或 `TradeFunctionSwitch` 增加账号维度套利灰度缓存，并在灰度配置变更、账号切换、设置变更时失效。
+4. 对 `TradeGuaDanListView.onForeground()` 的挂单刷新做去重/节流，避免前台恢复、手动刷新和推送触发重复查询。
+
+## 验证口径
+
+每个候选项修复后，需要用新包重新采集线上或真机冻屏采样，确认对应函数不再进入 TOP 耗时列表。仅凭本次 TOP10 采样不能判定短函数为唯一根因。
@@ -0,0 +1,90 @@
+# TOP10 线上耗时函数后续修复
+## 修复提交
+
+| 仓库 | 分支 | Commit ID | 说明 |
+| --- | --- | --- | --- |
+| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `0d10cf71a01c8c5d875ca4c950d6d2fd71d3fd42` | 挂单请求合并、套利开关缓存、通信队列索引、行情表格延迟合并 |
+| `ohos_mobile_lib_communication` | `work-freeze-lib-communication-1.1.1` | `031d4cf221b4da6d9aaf2db443ba293559a0d4a5` | `QueueManagement` 队列索引（instanceId→client / companion） |
+
+## 问题来源
+
+基于 2026-08-21 `TOP10耗时函数列表.md` 的线上采样，继续处理仍有明确优化空间的主线程热点：
+
+- `@b2b/hq_table` `TableDataSource`：1 次故障、10 次调用、总耗时 3000ms。
+- `@kernel/lib_communication` `QueueManagement`：1 次故障、2 次调用、总耗时 600ms。
+- `biz_trade` `TradeCustomTabManager.isArbitrageEnabled()`：1 次故障、4 次调用、总耗时 1200ms。
+- `biz_trade` `TradeGuaDanListView.onForeground()`：1 次故障、10 次调用、总耗时 3000ms。
+
+## TOP20 线上数据补充
+
+同日 `/Users/clz/Downloads/TOP20耗时函数列表.md` 汇总数据如下：故障出现次数 `1134`，调用次数 `11340`，记录总耗时 `3402000ms`。所有记录的单个故障最大耗时均为 `3000ms`。这些数值是采样记录的分层汇总，不代表一次冻屏实际耗时，不能直接相加计算收益。
+
+TOP20 主要归并为以下调用链：
+
+| 调用链 | TOP | 故障/调用 | 总耗时 | 当前判断 |
+| --- | ---: | ---: | ---: | --- |
+| 重登录复用 IP 与 Native 锁 | 1–4、19–20 | 75/750；44/440 | 900000ms；132000ms/项 | 锁优化 SO 已接入，应用侧仍有同步查询边界，待新包复采 |
+| 交易请求拦截与发送 | 5–6、11–18 | 47–67/470–670 | 141000–201000ms/项 | 已移除拦截器同步状态检查，通用请求仍需观察并发放大 |
+| 通信响应回调转发 | 7–10 | 58–59/580–590 | 174000–177000ms/项 | 属同一管线分层采样，Worker/索引优化已接入，待新包复采 |
+
+TOP20 显示的交易 SDK 与通信库版本分别为旧版 `1.0.11/1.1.1` 和 `1.1.1-beta.1`；当前工程依赖已更新为交易 SDK `1.0.13/1.2.0` 及 Worker 优化通信 HAR。因此本表用于记录线上问题来源和修复映射，不能作为当前版本仍全部复现的证据。
+
+## 修复内容
+
+1. `GuaDanViewModel.sendRequest()` 增加进行中请求合并：挂单查询未返回时，后续前台/刷新触发只记录一次尾随刷新，避免短时间重复进入 SDK 查询链路。
+2. `TradeCustomTabManager.isArbitrageGrayOpened()` 增加当前账号维度缓存；`TradeSettingEvents.SETTING_UPDATE` 触发时失效，避免列表构建高频进入 `GrayTestManager.isFeatureEnable()` 的日志和配置序列化路径。
+3. 通信 SDK `QueueManagement` 增加 `instanceId -> client` 和 companion 映射索引，`getNetworkClient()` 从全量扫描改为按索引取主请求和 companion 请求。
+4. `hq_table_20260616.har` 内 `TableDataSource` 对非可见区 `SendableRow` 做延迟合并：当前刷新只合并可见行，非可见行缓存到 `pendingSendableRows`，滚动取数时再落到 `RowData`。
+5. 重新构建通信 HAR，并替换当前工程 `libs/lib_communication20250903-worker-opt.har`；`hq_table` 无相邻源码仓库，本次直接以最小差异更新现有 HAR。
+
+## 影响范围
+
+- 挂单列表前台恢复、手动刷新和交易推送叠加时的请求频率。
+- 独立交易页期权/套利 Tab 显示判断。
+- 通信响应分发中的请求匹配。
+- 行情表格 Sendable 数据进入主线程后的行合并时机。
+
+业务协议、接口签名、表格展示数据结构和交易请求返回处理不变。挂单请求合并保留尾随刷新，避免丢掉进行中期间发生的最后一次刷新诉求。
+
+## 验证与压测
+
+- `node claude_tool/subthread-import-guard/check-subthread-imports.mjs`：PASS。
+- 通信 SDK：`devecocli build --modules lib_communication@default`：BUILD SUCCESSFUL。
+- 主工程：`./claude_tool/claude_compile.sh`：BUILD_SUCCESS。
+- 模拟器：Pura 90，`127.0.0.1:5555`，HarmonyOS 6.1.1(24)。
+  - `devecocli run --module entry --device 127.0.0.1:5555 --product default --build-mode debug --skip-build`：安装并启动成功。
+  - 应用进程 `com.hexin.plat.hmn.futures` 存活，前台任务 `EntryAbility` 存在。
+  - 前后台压力：Home/重新拉起 20 轮完成，无 crash、无 `APPFREEZE` 日志。
+  - UI 基础场景：行情 Tab 切换、行情页上下滑动 8 轮、交易 Tab 切换、交易入口前后台 5 轮完成，无 crash、无 `APPFREEZE` 日志。
+  - 备注：未登录交易账号，挂单真实请求返回链路未覆盖；本轮覆盖交易入口页加载和前台恢复基础路径。
+- 临时 stdin 压测脚本未落盘，覆盖 100000 个通信实例索引查询、100000 行表格 Sendable 延迟合并、1000 次挂单刷新触发合并：
+  - `queueIndexedMs`: 4ms
+  - `tableDeferredMs`: 4ms
+  - `requestRealSendAfter1000Triggers`: 2
+
+### 新模拟器真实账户验证
+
+- 设备：Mate X7，`127.0.0.1:5557`，HarmonyOS 6.1.1(24)；通过 `devecocli ui` 完成控件树检查和交互。
+- 真实账户登录成功，交易首页权益、可用资金和行情盘口加载完成。
+- 进入当日委托/挂单页面，连续 10 轮切换挂单、委托、成交并触发刷新；页面保持响应，无 `APPFREEZE`，无应用 crash。
+- 该轮未执行下单、撤单或改价，避免产生真实资金业务副作用。
+- 设备网络不可用时出现 DNS/监控上传错误；同时观察到已有 SQLite 空表名查询错误，均未导致应用退出或冻屏，不纳入本次 TOP 修复结论。
+- 最后一次误触打开交易时间提醒 WebView，页面仍正常展示；该路径不属于本次交易 SDK 压测范围。
+
+### Wukong 滑动压力验证
+
+- 设备：Mate X7，`127.0.0.1:5557`；仅允许 `com.hexin.plat.hmn.futures`，固定种子 `20260821`。
+- Wukong 随机测试报告：`task status=success`、`task time=149s`、`task count=100`，事件为 100 次滑动；点击、键盘、旋转和应用切换比例均为 0。
+- Wukong 异常统计为空；设备 `APPFREEZE` 查询为空，应用 crash 查询为空。
+- 报告目录：`/data/local/tmp/wukong/report/20260821_152309/`。该轮未执行交易点击，真实账户无资金业务副作用。
+
+### 按修改点专项复验
+
+- `hq_table`：国内行情大表执行 Wukong 50 次纯滑动，报告 `task status=success`、`task count=50`、滑动事件 50 次、异常为空；页面仍可正常进入合约详情。
+- Worker 解码：合约详情连续 8 轮切换分时、日 K、1/5/15 分钟，图表和行情数据正常，无 `APPFREEZE` 或 crash。
+- `GuaDanViewModel` 与 `QueueManagement`：真实账户交易页在设置更新后重新进入当日委托，连续 5 轮切换挂单/委托并刷新；页面正常，无 `APPFREEZE` 或 crash。
+- `TradeCustomTabManager`：当前真实账户和灰度环境未展示期权/套利独立下单 Tab，仅触发交易设置更新事件并返回交易页验证回退/重建路径；期权/套利 Tab 的直接专项验证待灰度开放后补测。
+
+## 后续验证
+
+需要用新包重新采集线上或真机冻屏采样，确认 `TableDataSource`、`QueueManagement`、`isArbitrageEnabled`、`TradeGuaDanListView.onForeground` 不再进入 TOP 耗时函数。短函数如 `ColorUtils.transFormServerColor()`、`StringUtil.isNumber()` 和 `BaseView` 绘制闭包仍应结合完整栈判断，不单独做微调。
@@ -0,0 +1,80 @@
+# 期货 HarmonyOS 客户端稳定性治理需求开发文档
+
+## 1. 文档目的
+
+本文将现有冻结（App Freeze）与内存溢出（OOM）整改记录整理为可研发落地、可测试验收的需求。目标是在不改变行情、交易、画线业务协议及用户可见规则的前提下，降低主线程阻塞、请求重复与对象滞留风险。
+
+本文记录的是已验证改造的需求基线，不代表所有项均已随正式版本发布；版本接入与线上复采必须以各上游仓库和发布包为准。
+
+## 2. 范围与代码归属
+
+| 域      | 主要归属                                                                | 本次目标                  |
+| ------ | ------------------------------------------------------------------- | --------------------- |
+| 应用业务   | `harmony-ths-futures`                                               | 交易、行情与 WebView 生命周期治理 |
+| 通信     | `ohos_mobile_lib_communication`                                     | 解码、曲线解析、请求队列与缓冲释放     |
+| 交易 SDK | `harmony_futures_trade_sdk` `futures_trade_sdk`（原生 `lib-weituosdk`） | Native 锁规避、成交推送、市价缓存  |
+| 画线 SDK | `hmdrawlinebasicsdk`                                                | 绘制候选集去重               |
+
+本仓库仅保存变更说明，不能直接构建或产出 HAP/HAR。
+
+## 3. 功能需求
+
+### FR-01 通信与解析异步化
+
+1. XML 响应的字节解码和属性解析必须在 TaskPool 中完成；主线程仅消费解析结果。解析入口只允许携带可序列化数据，禁用 DOCTYPE，并保持登录会话、验证码、手机号查询的原有回调与失败语义。
+2. `HXZip` 解压及曲线的 `points × fields` 解析必须在通信 HAR 的持久 Worker 中执行。响应须按请求顺序串行回调；Worker 异常须拒绝当前等待任务，但不得阻断后续消息。
+3. `QueueManagement` 必须维护 `instanceId → client/companion` 索引，避免响应分发遍历全部客户端；跨 `frameId` 切换时，必须释放旧请求缓冲、主/伴随 client 映射。
+
+### FR-02 行情与绘制主线程削峰
+
+1. 表格实时通知在同一事件循环内仅保留最新一份 `TableData`，已有定时器时不得继续创建闭包；切页或释放时必须取消定时器并清空待通知数据。
+2. 画线候选集去重必须保持“同对象、本地 ID 相同或远端 ID 相同即重复”的既有语义与插入顺序，复杂度由 O(n²) 降为 O(n)。
+
+### FR-03 交易链路防重复与锁规避
+
+1. 前台交易页的在线判断必须读取 `currentAccount.isOnline` 缓存，不得同步调用 Native 在线查询；断网、重登、切账号后的条件单补查行为保持不变。
+2. 同一账号重登必须复用进行中的 Promise；无实际拦截效果的交易发送前 SDK 状态检查必须移除。
+3. 挂单查询进行中再次触发时，只保留一次尾随刷新；列表构建中的套利灰度判断按账号缓存，并在设置更新、账号或灰度配置变化时失效。
+4. 成交推送必须按唯一标识去重。首次加载可全量排序，后续记录必须以稳定二分插入，且不改变成交量、盈亏、账号过滤与展示顺序。
+5. 市价缓存须按“合约 + 价格类型”更新同一节点；消费后必须用可修改数组操作删除节点，禁止重复累积。
+
+### FR-04 页面与请求资源释放
+
+1. `TableRequestClient` 切页、取消订阅或释放时，必须幂等地移除旧队列映射、实时订阅、请求缓冲与待通知数据。
+2. WebView 总览页销毁时，必须停止三个行情请求并清空 client 与 JS bridge 的双向引用。
+
+## 4. 影响面
+
+| 需求域 | 用户/业务入口 | 受影响组件 | 保持不变 | 重点回归 |
+| --- | --- | --- | --- | --- |
+| 通信与解析 | 登录、验证码、行情包与 K 线加载 | XML Parser、通信 Worker、`QueueManagement` | 协议、回调结果、消息顺序 | 损坏 XML、大包、周期连续切换、跨 Frame 请求 |
+| 行情与画线 | 行情列表刷新、合约详情、K 线绘制 | `TableRequestClient`、画线 SDK | 行情数据、线条样式、命中与层级 | 高频推送、分组切换、滚动、跨周期线合并 |
+| 交易 | 前后台、账号切换、挂单/委托/成交页 | `TradePage`、`TradeApiManager`、交易 SDK | 下单/撤单、账户过滤、成交汇总与排序规则 | 断网重登、重复刷新、重复推送、真实账户切换 |
+| 页面生命周期 | WebView 行情总览页退出 | `OverViewEvent`、请求 client、JS bridge | 总览请求参数、前后台恢复行为 | 反复进入/退出总览页、页面销毁后回调 |
+
+## 5. 非功能要求与边界
+
+- 所有异步任务仅传递基础类型、`Uint8Array` 或其他可序列化数据；单个 Worker 消息受 16 MB 限制，接近上限时需分块设计。
+- 不修改网络协议、公开接口、交易下单/撤单规则、行情数据模型或画线样式。
+- 不将 SDK 对象迁移至 Worker；Native 锁的根治依赖交易 SDK 缩小锁粒度，应用侧仅减少进入锁域的次数。
+- 临时 HAR 路径、压测代码、计数日志和 API SDK 替换不得进入正式提交。
+
+## 6. 验收标准
+
+1. 在上游项目执行 `devecocli build --modules <module>@default` 或对应 HAP 构建成功，且 `devecocli check lint` 无新增问题。
+2. 覆盖登录/断网重登、前后台、账号切换、挂单/委托/成交刷新、行情分组切换、K 线周期切换及 WebView 总览销毁；无 JS Crash、CppCrash、OOM 或 `APPFREEZE`。
+3. 成交去重、稳定排序、缓存删除和请求解绑须具备单元或白盒压力测试；测试后不存在旧订阅、旧缓冲、待通知数据或缓存节点残留。
+4. 新包须在真机或模拟器重新采集冻屏采样。`QueueManagement`、`isArbitrageEnabled` 与 `TradeGuaDanListView.onForeground` 不应继续作为可归因的 TOP 耗时热点；分层采样不得重复相加作为性能收益。
+
+## 7. 交付与追溯
+
+每个交付项需提供：所属仓库/分支/commit、HAR 或 HAP 版本与校验值、修改文件清单、构建日志、测试设备与场景、前后指标、未覆盖项及回滚包。详细历史证据见 `harmony-ths-futures-freeze/doc/change-notes/` 和 `harmony-ths-futures-apm-oom/doc/change-notes/`。
+
+## 8. Change-notes 追溯
+
+| 需求域    | 改动仓库                                                                                            | 原始功能改动记录（括号内为改动仓库）                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| ------ | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 通信与解析  | `harmony-ths-futures`<br>`ohos_mobile_lib_communication`                                        | <ul><li>[02-xml-taskpool-refactor.md](harmony-ths-futures-freeze/doc/change-notes/02-xml-taskpool-refactor.md)（`harmony-ths-futures`）</li><li>[03-communication-taskpool-decompression.md](harmony-ths-futures-freeze/doc/change-notes/03-communication-taskpool-decompression.md)（`ohos_mobile_lib_communication`、`harmony-ths-futures`）</li><li>[04-curve-parsing-taskpool.md](harmony-ths-futures-freeze/doc/change-notes/04-curve-parsing-taskpool.md)（`ohos_mobile_lib_communication`、`harmony-ths-futures`）</li><li>[14-communication-request-buffer-frame-cleanup.md](harmony-ths-futures-apm-oom/doc/change-notes/14-communication-request-buffer-frame-cleanup.md)（`ohos_mobile_lib_communication`、`harmony-ths-futures`）</li></ul>                                                                                                                                           |
+| 行情与画线  | `harmony-ths-futures`<br>`hmdrawlinebasicsdk`                                                   | <ul><li>[09-drawline-dedup-optimization.md](harmony-ths-futures-freeze/doc/change-notes/09-drawline-dedup-optimization.md)（`hmdrawlinebasicsdk`、`harmony-ths-futures`）</li><li>[10-table-request-client-subscription-cleanup.md](harmony-ths-futures-apm-oom/doc/change-notes/10-table-request-client-subscription-cleanup.md)（`harmony-ths-futures`）</li><li>[11-table-request-client-notification-coalescing.md](harmony-ths-futures-apm-oom/doc/change-notes/11-table-request-client-notification-coalescing.md)（`harmony-ths-futures`）</li></ul>                                                                                                                                                                                                                                                                                                                                   |
+| 交易     | `harmony-ths-futures`<br>`futures_trade_sdk`（原生 `lib-weituosdk`）<br>`harmony_futures_trade_sdk` | <ul><li>[05-trade-sdk-native-lock-app-mitigation.md](harmony-ths-futures-freeze/doc/change-notes/05-trade-sdk-native-lock-app-mitigation.md)（`harmony-ths-futures`、`futures_trade_sdk` 的原生 `lib-weituosdk`）</li><li>[07-trade-sdk-match-push-optimization.md](harmony-ths-futures-freeze/doc/change-notes/07-trade-sdk-match-push-optimization.md)（`harmony-ths-futures`、`harmony_futures_trade_sdk`）</li><li>[08-trade-page-online-status-cache.md](harmony-ths-futures-freeze/doc/change-notes/08-trade-page-online-status-cache.md)（`harmony-ths-futures`）</li><li>[11-top10-followup-fixes.md](harmony-ths-futures-freeze/doc/change-notes/11-top10-followup-fixes.md)（`harmony-ths-futures`）</li><li>[12-trade-sdk-market-price-cache-cleanup.md](harmony-ths-futures-apm-oom/doc/change-notes/12-trade-sdk-market-price-cache-cleanup.md)（`harmony_futures_trade_sdk`）</li></ul> |
+| 页面生命周期 | `harmony-ths-futures`                                                                           | <ul><li>[13-webview-overview-request-cleanup.md](harmony-ths-futures-apm-oom/doc/change-notes/13-webview-overview-request-cleanup.md)（`harmony-ths-futures`）</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |