【问题标题】:IOS - Best practice to handle large number of images (Performance + Size on disk)IOS - 处理大量图像的最佳实践(性能+磁盘大小)
【发布时间】:2015-10-10 23:00:20
【问题描述】:

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

我也是 cocos2d-x 的开发者。在 cocos 环境中,我使用plist 来“绑定”每个图像,然后通过plist 剪切它。这是出色的性能和尺寸节省,但据我所知,这在 UIKit 上是不可能的。

所以我的问题是,除了将文件拖放到 XCode 中并照常使用之外,还有更好的方法来存储/提取这些图像以提高磁盘容量和提高性能吗?

【问题讨论】:

  • 100 个 100x100 的图像并没有那么多内存。假设全部都加载进去,解码时就是(100 * 100 * 100 * 4)字节的内存,也就是4MB。 UIKit 将处理您的资源的重复数据删除,以及在低内存环境中缓存/释放它们,所以我认为这只是过早的优化。
  • Richard 是对的,因为内存量并不算太差,但如果您真的需要,您可以将这些图像制作成一个单独的精灵,然后使用坐标调用它。我以前用这个网站做 CSS Sprite spritegen.website-performance.org
  • @Cole 这对 iOS 上的性能不利 - 缓存局部性所获得的收益微乎其微,正如我之前提到的 UIKit 使用一些高级缓存技术来确保只有正在使用的图像留在内存中在任何给定时间。此外,超过 1024x1024 的图像在旧设备上的性能非常差(由于纹理缓冲区中的硬件限制,图像必须由 UIKit 平铺)。
  • @Richard 呵呵,我从没想过。我只记得在 CSS 中将它们用于按钮。你知道的越多!
  • @Cole for CSS/web 然而这是一个不同的场景。当您处理网络时(在 HTTP/2.0 之前),您必须为每个包含图标的文件发送单独的请求,从而显着增加您的加载时间(因为 HTTP 标头握手非常延迟,甚至更多TLS 也是如此),所以它被用作内容交付的优化,而不是内容渲染。

标签: ios xcode image performance size


【解决方案1】:

[任意数量] 图像在 iOS 上并不是真正的问题,因为有高级缓存系统可以处理图像的重用。 iOS的渲染系统也非常棒,所以你不必担心。

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

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

对于 iOS,有一些你应该知道的陷阱:

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

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

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

希望对你有帮助!

【讨论】:

  • 感谢您的回复,colorWithPatternImage 可能造成的内存泄漏是非常有用的细节,还有关于侧面信息:) 谢谢!
【解决方案2】:

如果这很重要的话,iOS 9 中将会有 ;) 它被称为按需资源,可让您使用 Apple 存储内容并在需要关卡等时下载内容。它非常适合游戏应用程序,这就是他们在 WWDC 上用作示例。

在这里查看:https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/

【讨论】:

  • 非常有用的信息,感谢您回答@Drmorgan!
猜你喜欢
  • 1970-01-01
  • 2013-09-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-05-10
  • 2014-11-02
  • 2014-09-04
相关资源
最近更新 更多