iphone - 性能方面 : A lot of small PNGs or one large PNG?

Question

为 iPhone 开发一个简单的游戏，什么可以提供更好的性能？

1. 为 UIView 的背景使用大量小型(10x10 到 30x30 像素)PNG。
2. 使用一个大的 PNG 并剪裁到我的 UIView 的边界。

我的想法是，第一种技术每个单独的 UIView 需要更少的内存，但使 iPhone 处理大量图像的方式变得复杂，因为它试图将图像组合成更大的纹理，或者尝试在所有小纹理之间切换很多。

另一方面，第二种技术使 iPhone 有机会处理一个大的 PNG，但不必要地增加了每个 UIView 必须承载的图像重量。

• iPhone 按照我描述的方式处理图像的尝试，我的看法正确吗？
• 那么，该怎么走呢？

看到到目前为止的答案，仍然存在疑问。似乎需要权衡两个参数:复杂性和 CPU 密集型编码。 决定使用哪种技术的临界点是什么？

Answer 1

如果您最终引用相同的 CGImageRef(例如通过共享 UIImage *)，则不同 View 不会多次加载图像。这是 videowall Core Animation demo at the WWDC 07 keynote 使用的技术。这是 OSX 代码，但 UIView 与 CALayers 非常相似。

Core Graphics 处理图像的方式(无论如何，根据我的观察)进行了大量调整，以便在内存紧张时及时加载和积极释放。

使用大图像时，如果 CGImageRef 指向的解码图像的内存已被系统回收，您最终可能会在绘制时加载图像。

重要的不是您拥有多少图像，而是 UIKit 遍历您的代码的频率。

UIView 和核心动画 CALayers 仅在您要求 (-setNeedsDisplay) 时才会重新绘制，瓶颈通常是您的代码以及将渲染内容传输到图形芯片的纹理中。

所以我的建议是，以一种允许一起更改的部分同时更新的方式来思考你的 UIView 布局，这将变成单个纹理上传。