You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

使用VNGeneratePersonSegmentationRequest时如何释放未回收的内存?

VNGeneratePersonSegmentationRequest首次调用后产生的300MB常驻内存是Vision框架的正常行为,不属于业务代码内存泄漏。Vision框架首次执行人像分割请求时,会全局加载对应神经网络模型、初始化Metal计算上下文、神经网络引擎调度缓存,这部分资源由系统框架统一持有,不属于业务层分配的对象,因此autoreleasepool无法回收,手动触发内存警告也不会被释放。框架默认留存这部分资源是为了避免后续重复请求时反复加载产生性能损耗,这也是你后续发起多次请求内存不会持续上涨的原因。

对应的优化方案如下:

  • 若仅偶尔使用背景移除功能,无高频调用需求,可以把人像分割逻辑放到独立的应用扩展(比如图片编辑扩展)中执行,扩展进程执行完任务退出后,这部分内存会被系统完全回收,不会占用主进程内存空间。
  • 调整请求参数降低框架常驻内存:将qualityLevel从.accurate改为.balanced或.fast,对应加载的模型体积更小,初始常驻内存可降到100MB以内;也可以尝试使用更高版本的VNGeneratePersonSegmentationRequest revision,新版本系统的模型推理框架有内存占用优化。
  • 避免重复创建请求对象:无需每次处理图片都新建VNGeneratePersonSegmentationRequest实例,全局复用同一个请求对象即可,虽然不会降低初始常驻内存,但可以减少每次请求的额外性能开销。
  • 业务侧对象及时释放:代码中持有的self.personMask使用完后及时手动置为nil,可避免不必要的内存占用。

只要通过Xcode的Leaks工具排查确认没有业务侧的内存泄漏,这部分框架级的常驻内存不会导致App Store审核被拒,苹果对系统框架自身的缓存占用是认可的,无特殊需求无需额外处理。

内容的提问来源于stack exchange,提问作者Ebarella

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.09.29 18:36:01