60 lines
4.3 KiB
Markdown
60 lines
4.3 KiB
Markdown
# 通信解压迁移至 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`。
|