消除 UIImage imageNamed: FUD [英] Dispelling the UIImage imageNamed: FUD

问题描述

2014 年 2 月请注意，此问题可追溯到 iOS 2.0！ 从那时起，图像要求和处理发生了很大变化.Retina 使图像更大，加载它们稍微复杂一些.借助对 iPad 和视网膜图像的内置支持，您当然应该在代码中使用 ImageNamed.

Edit Feb 2014: Note that this question dates from iOS 2.0! Image requirements and handling have moved on a lot since then. Retina makes images bigger and loading them slightly more complex. With the built in support for iPad and retina images, you should certainly use ImageNamed in your code.

我看到很多人说 imageNamed 不好，但同样数量的人说性能很好 - 特别是在渲染 UITableView 时.例如，请参阅这个问题或这篇文章 iPhoneDeveloperTips.com

I see a lot of people saying imageNamed is bad but equal numbers of people saying the performance is good - especially when rendering UITableViews. See this SO question for example or this article on iPhoneDeveloperTips.com

UIImage 的 imageNamed 方法用于泄漏，因此最好避免，但已在最近的版本中修复.我想更好地理解缓存算法，以便就我可以信任系统在哪里缓存我的图像以及我需要加倍努力并自己做的地方做出合理的决定.我目前的基本理解是，它是一个由文件名引用的 UIImages 的简单 NSMutableDictionary.它变得更大，当内存耗尽时，它会变得更小.

UIImage's imageNamed method used to leak so it was best avoided but has been fixed in recent releases. I'd like to understand the caching algorithm better in order to make a reasoned decision about where I can trust the system to cache my images and where I need to go the extra mile and do it myself. My current basic understanding is that it's a simple NSMutableDictionary of UIImages referenced by filename. It gets bigger and when memory runs out it gets a lot smaller.

例如，有没有人确定imageNamed 后面的图像缓存不会响应didReceiveMemoryWarning?苹果似乎不太可能不这样做.

For example, does anyone know for sure that the image cache behind imageNamed does not respond to didReceiveMemoryWarning? It seems unlikely that Apple would not do this.

如果您对缓存算法有任何见解，请在此处发布.

If you have any insight into the caching algorithm, please post it here.

推荐答案

tldr: ImagedNamed 很好.它可以很好地处理内存.使用它并停止担心.

Edit Nov 2012:请注意，此问题源自 iOS 2.0！从那时起，图像要求和处理发生了很大变化.Retina 使图像更大，加载它们稍微复杂一些.借助对 iPad 和视网膜图像的内置支持，您当然应该在代码中使用 ImageNamed.现在，为了后代:

Edit Nov 2012: Note that this question dates from iOS 2.0! Image requirements and handling have moved on a lot since then. Retina makes images bigger and loading them slightly more complex. With the built in support for iPad and retina images, you should certainly use ImageNamed in your code. Now, for posterity's sake:

Apple 开发者论坛上的姐妹主题获得了一些更好的流量.特别是 Rincewind 添加了一些权限.

The sister thread on the Apple Dev Forums received some better traffic. Specifically Rincewind added some authority.

在 iPhone OS 2.x 中存在一些问题，即使在内存警告之后，imageNamed: 缓存也不会被清除.同时，+imageNamed: 得到了很多使用，不是为了缓存，而是为了方便，这可能把问题放大了.

There are issues in iPhone OS 2.x where the imageNamed: cache would not be cleared, even after a memory warning. At the same time +imageNamed: has gotten a lot of use not for the cache, but for the convenience, which has probably magnified the problem more than it should have been.

同时警告

在速度方面，人们对正在发生的事情普遍存在误解.+imageNamed: 所做的最重要的事情是从源文件中解码图像数据，这几乎总是显着增加数据大小(例如，屏幕大小的 PNG 文件在压缩时可能会消耗几十 KB，但会消耗超过半 MB解压缩 - 宽 * 高 * 4).相比之下， +imageWithContentsOfFile: 将在每次需要图像数据时解压缩该图像.可以想象，如果您只需要一次图像数据，那么在这里您将一无所获，除了有图像的缓存版本，而且可能比您需要的时间更长.但是，如果您确实有需要经常重绘的大图像，那么还有其他选择，尽管我主要推荐的方法是避免重绘该大图像:)

On the speed front, there is a general misunderstanding of what is going on. The biggest thing that +imageNamed: does is decode the image data from the source file, which almost always significantly inflates the data size (for example, a screen sized PNG file might consume a few dozen KBs when compressed, but consumes over half a MB decompressed - width * height * 4). By contrast +imageWithContentsOfFile: will decompress that image everytime the image data is needed. As you can imagine, if you only need the image data once, you've won nothing here, except to have a cached version of the image hanging around, and likely for longer than you need it. However, if you do have a large image that you need to redraw often, then there are alternatives, although the one I would recommend primarily is to avoid redrawing that large image :).

关于缓存的一般行为，它根据文件名进行缓存(因此 +imageNamed: 的两个实例应该导致对相同缓存数据的引用)并且缓存将根据您的请求动态增长通过 +imageNamed: 获取更多图像.在 iPhone OS 2.x 上，一个错误会阻止缓存在收到内存警告时收缩.

With respect to the general behavior of the cache, it does cache based on filename (so two instances of +imageNamed: with the same name should result in references to the same cached data) and the cache will grow dynamically as you request more images via +imageNamed:. On iPhone OS 2.x a bug prevents the cache from being shrunk when a memory warning is received.

和

我的理解是 +imageNamed: 缓存应该遵守 iPhone OS 3.0 上的内存警告.有机会时进行测试，如果发现情况并非如此，请报告错误.

My understanding is that the +imageNamed: cache should respect memory warnings on iPhone OS 3.0. Test it when you get a chance and report bugs if you find that this is not the case.

所以，你有它.imageNamed:不会砸碎你的窗户或谋杀你的孩子.这很简单，但它是一个优化工具.可悲的是，它的名字很糟糕，并且没有任何等效物可以像使用一样容易 - 因此人们过度使用它并在它只是完成其工作时感到不安

So, there you have it. imageNamed: will not smash your windows or murder your children. It's pretty simple but it is an optimisation tool. Sadly it is badly named and there is no equivaluent that is as easy to use - hence people overuse it and get upset when it simply does its job

我向 UIImage 添加了一个类别来解决这个问题:

I added a category to UIImage to fix that:

// header omitted
// Before you waste time editing this, please remember that a semi colon at the end of a method definition is valid and a matter of style.
+ (UIImage*)imageFromMainBundleFile:(NSString*)aFileName; {
    NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
    return [UIImage imageWithContentsOfFile:[NSString stringWithFormat:@"%@/%@", bundlePath,aFileName]];
}

Rincewind 还包含一些示例代码来构建您自己的优化版本.我看不出值得维护，但这里是为了完整性.

Rincewind also included some example code to build your own optimised version. I can't see it is worth the maintentace but here it is for completeness.

CGImageRef originalImage = uiImage.CGImage;
CFDataRef imageData = CGDataProviderCopyData(
     CGImageGetDataProvider(originalImage));
CGDataProviderRef imageDataProvider = CGDataProviderCreateWithCFData(imageData);
CFRelease(imageData);
CGImageRef image = CGImageCreate(
     CGImageGetWidth(originalImage),
     CGImageGetHeight(originalImage),
     CGImageGetBitsPerComponent(originalImage),
     CGImageGetBitsPerPixel(originalImage),
     CGImageGetBytesPerRow(originalImage),
     CGImageGetColorSpace(originalImage),
     CGImageGetBitmapInfo(originalImage),
     imageDataProvider,
     CGImageGetDecode(originalImage),
     CGImageGetShouldInterpolate(originalImage),
     CGImageGetRenderingIntent(originalImage));
CGDataProviderRelease(imageDataProvider);
UIImage *decompressedImage = [UIImage imageWithCGImage:image];
CGImageRelease(image);

此代码的代价是解码图像使用更多内存但渲染速度更快.

The trade off with this code is that the decoded image uses more memory but rendering is faster.

这篇关于消除 UIImage imageNamed: FUD的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！