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,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` 绘制闭包仍应结合完整栈判断，不单独做微调。