我尽可能快地连续运行该方法，并且越快越好，所以很明显如果CGDataProviderCopyData()实际上是逐字节复制数据，那么我认为必须有更快的方法直接访问该数据......它只是内存中的字节。任何人都知道CGDataProviderCopyData() 是否真的复制了数据？还是只是创建一个指向现有数据的新指针？
【问题讨论】：
标签： iphone performance core-graphics bytebuffer
字节被复制。
使用数据提供者的内容在内部创建一个 CFData (CFDataCreate)。 CFDataCreate 函数总是进行复制。
【讨论】：
CGAccessSessionCreate 然后CGAccessSessionGetBytePointer。
有人确定 CGDataProviderCopyData() 是否真的复制数据吗？还是只是创建一个指向现有数据的新指针？
这些都是一样的。指针是内存地址；根据定义，如果您有相同的数据在两个地址，它是相同的数据在两个地方，所以你必须复制它（从一个到另一个或都来自一个共同的起源）。
所以，让我们相应地重申这个问题：
还是只是复制现有的指针？
Quartz 不一定能做到这一点，因为 data providers do not necessarily provide an existing pointer，因为它们可以实现为本质上基于流（顺序）的提供程序。
直接访问提供商呢？ Even those need not cough up a byte pointer;提供商可能会简单地提供range-on-demand access。
但是如果它确实提供了一个字节指针呢？好吧，the documentation for that 说：
在 Quartz 调用您的
CGDataProviderReleaseBytePointerCallback函数之前，您不得移动或修改提供程序数据。
因此，可以想象，Quartz 可以重用指针。但是，如果您在释放数据之前释放数据提供者（导致您的 ReleaseBytePointer 回调被调用）怎么办？
如果 Quartz 实现了 CFData 或 NSData 的私有自定义子类，该子类实现故障或接管调用ReleaseBytePointer 的工作，这仍然是安全的，因此如果您创建直接访问提供程序并从中创建 CFData并释放提供者，您仍然可以使用 CFData 对象。
但这是很多假设。他们可能只是创建了一个普通的旧（创建时字节复制）CFData，这使其成为一个有效的性能问题。
分析它，看看它给你带来了多大的痛苦。如果足够担心，那么您需要一些解决方案：
ReleaseBytePointer 实现为无操作（空函数体）并分别释放字节，确保在释放提供程序和数据后这样做。理论上，如果它使用原始字节指针并且 Quartz 没有实现自定义 CFData 子类，则可以防止字节从 CFData 下流出。有点毛。不幸的是，Apple 不能真正依靠你来做这件事，所以我怀疑它是否真的会有所帮助。CGDataProviderCreateWithCFData 的文档没有说明它是否返回直接访问数据提供程序，因此如果您正在创建数据提供程序，则必须谨慎行事。
【讨论】：