通信解压迁移至 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。

4.3 KiB Raw Blame History