为何后台线程加载UIImage可解决SceneKit内存异常问题？

1. 初始UIImage(named:)导致内存上涨的核心原因 #

UIImage(named:)加载的图片会被系统存入全局缓存池，这个缓存的生命周期由系统控制，只有当系统内存极度紧张时才会主动清理。每次重启关卡时，你都会通过这个方法加载新的图片实例，而旧的图片仍被系统缓存持有，无法被ARC回收，导致内存持续累积30MB左右。

Instruments没检测到“泄漏”是因为内存并非无主状态，而是被系统缓存强引用；僵尸对象大量出现，是因为旧关卡的相关对象被释放后，缓存的图片仍被某些残留的弱引用指向，触发了僵尸对象检测。

2. 改用UIImage(contentsOfFile:)优化甚微的原因 #

UIImage(contentsOfFile:)确实不会将图片存入系统全局缓存，但你在**主线程（viewDidLoad）**执行加载操作时，SceneKit的材质系统会在主线程同步处理图片解码、纹理转换，这个过程中会创建大量临时内存对象，且主线程RunLoop的循环周期会延迟这些临时对象的回收时机。同时，SceneKit渲染管线在主线程处理纹理时，可能会临时持有图片的强引用，导致图片对象无法及时被ARC回收，内存问题没有得到根本解决。

3. 后台线程加载解决内存问题的原因 #

将图片加载逻辑放到后台线程后，解决问题的核心点有三个：

• 避免主线程同步阻塞与临时内存堆积：图片解码、初始纹理转换在后台线程完成，不会占用主线程RunLoop的处理周期，临时内存对象能在后台线程的任务结束后及时被回收，不会在主线程累积。
• 优化对象生命周期管理：后台线程的局部变量（path、img）在任务完成后会立即失去强引用，图片对象仅被材质持有，生命周期与关卡绑定，关卡销毁时材质释放，图片也会被ARC及时回收。
• SceneKit内部的纹理处理策略：SceneKit对于后台线程传入的图片资源，会采用更高效的纹理缓存管理机制，及时清理解码过程中的临时缓存，不会像主线程处理那样产生残留的内存占用。

内容的提问来源于stack exchange，提问作者West1