鸿蒙端执行uni.request时，会出现内存暴涨(上涨100mb +)是什么原因？

此问题并非内存泄露，而是和arkts模块加载有关系。uni.request 存储获取cookie使用的是webview.WebCookieManager，此方法会加载webview模块，导致初次调用时内存会增加不少，后续再调用就不会出现内存增加的情况了。后续考虑换成rcp模块的cookie管理功能（从api 23开始支持），https://developer.huawei.com/consumer/cn/doc/harmonyos-references/remote-communication-rcp#getcookiesbyurl

在你的原生工程内增加两行代码即可复现内存增加的情况

import webview from '@ohos.web.webview';  
function xxx() {  
  webview.WebCookieManager.fetchCookieSync('https://httpbin.org/get');  
}

欢迎到专业群（ uni-app x技术交流群 ） 咨询，群中有相关专业的管理员和群友。

结论先行：这大概率是正常的系统底层初始化行为，而非内存泄漏。

在鸿蒙 Next 上首次调用 uni.request 时内存上涨 100MB+，通常是因为底层网络栈（如 cronet 或鸿蒙系统网络库）的惰性初始化（Lazy Initialization）机制被触发。Android 和 iOS 由于系统架构差异，初始化开销较小或未在监控面板中显性体现。

技术原因分析

1. 鸿蒙网络栈的初始化开销

uni-app x 在鸿蒙平台底层可能集成了高性能网络库（如 cronet 或基于 rcp 的封装）。这类库在首次创建网络请求时会执行以下重操作：

• 加载动态库：映射 .so 或系统网络服务库到内存（可能占用 30-50MB）。
• 初始化 SSL/TLS 上下文：加载系统证书库、创建加密上下文（OpenSSL/BoringSSL 初始化）。
• 创建线程池：启动 IO 线程、网络线程、DNS 解析线程等（每个线程栈空间约 1MB，可能创建 10-20 个线程）。
• 建立系统服务连接：与鸿蒙系统的网络管理服务（NetManager）建立 IPC 通道，分配缓冲区。

这些资源在首次请求时一次性分配，之后会被复用。因此你会看到第一次点击按钮时内存陡增，后续请求趋于平稳。

2. 与 Android/iOS 的差异

• Android：uni-app x 的 Android 网络层基于 okhttp 或系统 HttpURLConnection，初始化开销较小（通常 10-30MB），且 Android 的内存监控（Profiler）通常显示的是 Java Heap + Native Heap，部分系统库内存可能被归类到共享内存，不易察觉。
• iOS：URLSession 是系统级 API，内存开销由系统统一管理，App 进程内看到的增长较少。
• 鸿蒙：作为新系统，其网络栈可能采用了更重的隔离设计或安全校验机制，导致初始化内存 footprint 较大。

3. 如何验证是否为正常初始化

你可以通过以下方式确认：

1. 二次请求测试：第一次请求后内存上涨 100MB，不退出页面，再次点击按钮发起第二次请求。如果内存不再显著上涨（或仅上涨几 MB），则确认是初始化开销。
2. 对比空页面：新建一个空页面，不执行任何请求，仅跳转到该页面，观察内存是否上涨。如果空页面不上涨，只有点击请求按钮才上涨，则定位到网络模块初始化。
3. 查看内存分类：在 DevEco Studio 的 Profiler 中查看内存分配详情，看增长部分主要是 Native 还是 ArkTS/JS。如果是 Native 层增长，基本可确认是网络库初始化。

排查与优化建议

如果确认是首次初始化开销，通常无需处理；但如果内存持续不释放或每次请求都暴涨，则需进一步排查：

1. 检查是否重复创建网络实例

确保你没有在每次点击时都创建新的网络栈实例。uni-app x 的 uni.request 是全局单例管理的，但如果你使用了某些 uts 插件或自定义网络库，请确保：

• 网络 client 是全局单例，非每次请求新建。
• 没有在 success/fail 回调中意外持有大对象引用。

2. 验证是否存在内存泄漏

如果每次请求后内存都上涨且不回落，可能是泄漏：

• 检查回调闭包：确保 success/fail 回调中没有持有页面 this 或大型数据结构的强引用。
• 手动触发 GC：在 DevEco Studio 中强制触发垃圾回收，观察内存是否回落。如果回落，说明是正常缓存；如果不回落，可能是泄漏。

3. 鸿蒙特定优化（如确认为问题）

如果 100MB 的初始化开销确实影响体验（如低端机 OOM），可尝试：

• 延迟初始化：在 App 启动时（onLaunch）提前发起一个轻量级请求（如 HEAD 请求到空接口），将初始化开销提前，避免用户首次点击时卡顿。
• 检查 HBuilderX 版本：确保使用最新版 HBuilderX（5.15+ 或 5.23 Alpha），官方可能已优化鸿蒙网络库的初始化策略。

4. 对比测试

使用鸿蒙原生 ArkTS 创建一个空项目，直接调用 @kit.NetworkKit 的 http.createHttp().request()，观察内存增长是否也在 100MB 左右。如果原生也有同样表现，则确认是系统行为，uni-app x 无法避免。

总结

当前建议：先按上述"二次请求测试"验证。如果确认是初始化开销，这属于鸿蒙平台网络栈的正常行为，与 Android/iOS 的实现差异有关。如果后续发现内存持续增长不释放，建议通过 DCloud Issue 系统 提交复现 Demo，并注明鸿蒙版本、HBuilderX 版本和内存监控截图。

你可以看一下uni-appx的编译产物，在unpackage目录下，它调的也是arkts的网络

这个请求有重定向吗？返回的headers里面有cookie相关的吗？测试uni.request的时候success、fail都清空测试的吗？