IOS - 处理大量图像的最佳实践(性能+磁盘大小)

Question

我的应用 UIKit 存储了大约 100 个 (100x100) jpeg 文件，假设用作“图案图像”。每张图片的平均大小有时约为 20~40 kb。

我也是 cocos2d-x 开发者。在 cocos 环境中，我使用 plist 来“绑定(bind)”每个图像，而不是通过 plist 剪切它。这是很好的性能和大小节省器，但据我所知，它在 UIKit 上是不可能的。

所以我的问题是，除了将文件拖放到 XCode 中并像往常一样使用它之外，是否有更好的方法来存储/提取此图像以提高磁盘容量和性能？

Answer 1

[任意数量] 的图像在 iOS 上并不是真正的问题，因为有先进的缓存系统负责图像的重用。 iOS 的渲染系统也非常好，所以你不必担心。

虽然为 Sprite 编写系统当然是可能的，但我不建议您这样做。此方法主要用于 Web 开发(因为每个图像都必须提供新请求 *note no longer true with HTTP/2 )，显然也用于游戏开发(因为绑定(bind)纹理调用越少越好)。

还有一个很好的例子来说明为什么不使用 sprite——如果你正在开发 Watch 应用程序并且你想做动画，你可以通过 flipboard 风格的图像(名为 1.png - 100.png 的图像序列)来实现，而不是使用大型图像集。虽然它会猜测他们为什么决定那样做(我的猜测是因为它在内部工作得很好 + 蓝牙的吞吐量)，但很明显它也是 Apple 的首选，所以我们应该遵循.

对于 iOS，您应该了解一些陷阱:

• 任何从 Web 加载的图像都不应该在主线程上加载，这同样适用于屏幕加载时不存在的每个图像(UITableViewCell 中的图像是很好的例子，因为如果滚动浏览时图像很大)
• 如果您有很多层，alpha channel != 1 的图像会严重降低性能(但通常是不可避免的)
• 应谨慎使用使用 UIColor.colorWithPatternImage() 创建的背景图像，因为此方法被认为有问题 ( details here )

现在关于图片的异步加载，我建议你看看下面的库:

• 哈内克 ( Obj-C , Swift )
• SDWebImage ( Obj-C )

它们都很棒，所以这真的是偏好问题(我更喜欢 Haneke)​​，但它们允许您在不同的线程上下载图像，无论是从 Web 还是从您的包。它们还有 UIImageView 的扩展，允许您使用 1 行函数轻松加载所有图像。

希望对您有所帮助!