消除 UIImage imageNamed: FUD

Question

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

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

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

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

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

Answer 1

根据我的经验，imageNamed 创建的图像缓存不会响应内存警告。我有两个应用程序，它们在内存管理方面尽我所能，但仍然由于缺乏内存而莫名其妙地崩溃。当我停止使用 imageNamed 加载图像时，两个应用程序都变得更加稳定。

我承认这两个应用程序都加载了一些较大的图像，但没有什么是完全不寻常的。在第一个应用程序中，我完全跳过了缓存，因为用户不太可能两次返回同一个图像。在第二个中，我构建了一个非常简单的缓存类，执行您提到的操作 - 将 UIImages 保存在 NSMutableDictionary 中，然后在收到内存警告时刷新其内容。如果 imageNamed: 像这样缓存，那么我不应该看到任何性能提升。所有这些都在 2.2 上运行 - 我不知道这是否对 3.0 有任何影响。

您可以从我的第一个应用程序中找到有关此问题的其他问题：
有关 UIImage 缓存的 StackOverflow 问题< /a>

另一项说明 - InterfaceBuilder 在幕后使用 imageNamed。如果您确实遇到此问题，请记住一些事情。

Answer 2

tldr：ImagedNamed 很好。它可以很好地处理内存。使用它，不再担心。

2012 年 11 月编辑：请注意，这个问题可以追溯到 iOS 2.0！从那时起，图像要求和处理发生了很大变化。视网膜使图像更大并且加载它们稍微复杂一些。由于内置了对 iPad 和视网膜图像的支持，您当然应该在代码中使用 ImageNamed。现在，为了子孙后代的缘故：

Apple 开发者论坛上的姐妹帖子获得了一些更好的流量。具体来说，Rincewind 添加了一些权限。

iPhone OS 2.x 中存在以下问题：即使在内存警告之后，imageNamed: 缓存也不会被清除。同时 +imageNamed: 得到了很多使用，不是为了缓存，而是为了方便，这可能比应有的情况更严重地放大了问题。

同时警告说

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

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

和

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

所以，你就知道了。 imageNamed：不会砸碎您的窗户或谋杀您的孩子。它非常简单，但它是一个优化工具。遗憾的是，它的命名很糟糕，并且没有一个易于使用的等效项 - 因此人们过度使用它，并且当它只是完成其工作时感到不安。

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

// 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 还包含一些示例代码来构建您自己的优化版本。我不认为它值得维护，但这是为了完整性。

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);

此代码的权衡是解码图像使用更多内存，但渲染速度更快。