访问SCNSkinner.boneIndices引发GB级内存分配的原因及解决办法

我开发了一款分析骨骼对顶点影响的应用，在循环中访问SCNSkinner的boneIndices数据时，虽未在循环内主动分配内存，却产生了GB级内存分配，导致应用崩溃。通过Instruments工具追踪发现：

• 约5秒内分配了15GB内存
• 所有内存分配均来自同一方法
• 工具明确指向.boneIndices的访问操作

该问题在Objective-C（SCNSkinner分类）和Swift版本中均存在，运行环境为macOS 14.2.1（未验证iOS）。此外，访问.bones属性会产生352字节的内存分配，虽影响较小但仍存疑问。现咨询：

1. 为何每次只读访问SCNSkinner.boneIndices都会产生内存分配？
2. 如何规避该问题（仅需读取该缓冲区）？

1. 内存分配的原因 #

SCNSkinner的boneIndices属性返回的是NSData（Objective-C）或Data（Swift）实例。每次访问这个属性时，SceneKit内部会复制一份底层的骨骼索引缓冲区数据返回给调用者，而非直接暴露原始内存指针。这是因为NSData/Data是不可变容器，SceneKit通过返回副本的方式保证线程安全，防止外部代码意外修改内部数据结构，同时避免内存生命周期管理的冲突。

至于.bones属性的352字节分配，这是返回的数组容器（NSArray/[SCNNode]）的内部结构开销，并非骨骼节点数据的副本，因此内存占用极小。

2. 规避方案：一次性缓存数据 #

核心思路是在循环外一次性读取并缓存boneIndices的数据，避免在循环内重复触发副本分配。以下是具体实现：

Swift 实现 #

// 循环外完成数据读取与缓存
guard let boneIndicesData = skinner.boneIndices else {
    // 处理数据为空的异常情况
    return
}

// 将Data转换为可直接访问的内存缓冲区，或转为Array长期持有
let indicesArray: [UInt16] = boneIndicesData.withUnsafeBytes { buffer in
    Array(buffer.bindMemory(to: UInt16.self)) // 骨骼索引通常为UInt16，根据模型调整类型
}

// 循环内直接使用缓存的数组
for index in indicesArray {
    // 处理单个骨骼索引逻辑
}

Objective-C 实现 #

// 循环外缓存数据
NSData *boneIndicesData = skinner.boneIndices;
if (!boneIndicesData) {
    // 处理数据为空的情况
    return;
}

// 获取原始内存指针与数据长度
const uint16_t *indicesPtr = (const uint16_t *)boneIndicesData.bytes;
NSUInteger indicesCount = boneIndicesData.length / sizeof(uint16_t);

// 循环内通过指针直接访问数据
for (NSUInteger i = 0; i < indicesCount; i++) {
    uint16_t index = indicesPtr[i];
    // 处理单个骨骼索引逻辑
}

注意事项 #

• 数据类型确认：多数情况下骨骼索引是16位无符号整数（UInt16/uint16_t），若模型骨骼数量超过65535，需改为32位整数（UInt32/uint32_t）。
• 内存生命周期：Swift中withUnsafeBytes闭包内的指针仅在闭包生效，若需长期使用需转为Array；Objective-C中只要boneIndicesData未释放，指针就可安全访问。
• 进阶优化：若需频繁处理这类底层数据，可直接从模型原始资产（如DAE/USDZ）解析骨骼索引，绕开SceneKit的SCNSkinner封装，完全控制内存分配逻辑，但实现成本更高。

内容的提问来源于stack exchange，提问作者AirXygène