# 通信 SDK 跨 Frame 请求缓冲清理与

## 修复提交

| 仓库 | 分支 | 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. 2026-08-21 在 Pura 90 API 24 模拟器执行有效的首页、行情、交易、发现四 Tab 定向循环 20 轮，每次切换等待 1 秒；进程持续存活，Crash 日志中未发现 OOM、JS Crash、CppCrash、SIGSEGV 或 SIGABRT。
3. 设备有效循环前 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 轮白盒计数测试为依据。