docs: refine impact scope and traceability

2026-08-25 14:56:53 +08:00
parent b5d837cc45
commit 6cfad5fa82
10 changed files with 94 additions and 74 deletions
@@ -15,10 +15,10 @@

 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 |
+| 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 映射拆成索引，减少行情响应分发阶段的线性扫描。

@@ -1,10 +1,10 @@
 # 交易 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`，降低锁竞争 |
+| 仓库                                    | 分支                                          | 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 的接入改动尚未提交。

@@ -16,7 +16,7 @@ Native 锁优化 SO（`futures-trade-sdk-so-1.2.0-lock-opt.har`）由上述 SDK

 ## 线上真实数据补充

-2026-08-21 补充的 TOP10 耗时函数线上统计中，交易 SDK 发送链路仍被采样命中：
+2026-08-21 补充的 TOP10 耗时函数线上统计中：

 | TOP | 函数 | 故障出现次数 | 调用次数 | 总耗时 |
 | ---: | --- | ---: | ---: | ---: |
@@ -13,11 +13,6 @@ SDK 侧成交推送去重/排序来源于 `harmony_futures_trade_sdk` 仓库上

 成交推送进入 `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` 分层函数，属于请求排队和发送链路，不足以证明成交推送去重与排序优化已经生效或失效；仍需通过成交推送专项采样验证。

 ## 优化方案

@@ -11,27 +11,6 @@

 交易 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`。
@@ -15,8 +15,6 @@
 ## 优化方案

 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。

 ## 影响范围

@@ -35,7 +35,7 @@ TOP20 显示的交易 SDK 与通信库版本分别为旧版 `1.0.11/1.1.1` 和 `
 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。
+

 ## 影响范围

@@ -62,9 +62,9 @@ TOP20 显示的交易 SDK 与通信库版本分别为旧版 `1.0.11/1.1.1` 和 `
  - `tableDeferredMs`: 4ms
  - `requestRealSendAfter1000Triggers`: 2

-### 新模拟器真实账户验证
+### 真实账户验证

- 设备：Mate X7，`127.0.0.1:5557`，HarmonyOS 6.1.1(24)；通过 `devecocli ui` 完成控件树检查和交互。
+- 通过 `devecocli ui` 完成控件树检查和交互。
 - 真实账户登录成功，交易首页权益、可用资金和行情盘口加载完成。
 - 进入当日委托/挂单页面，连续 10 轮切换挂单、委托、成交并触发刷新；页面保持响应，无 `APPFREEZE`，无应用 crash。
 - 该轮未执行下单、撤单或改价，避免产生真实资金业务副作用。