如何findUIImage瓶颈
我有一个使用UIImage对象的应用程序。 到目前为止，我一直在使用像这样初始化的图像对象：
UIImage *image = [UIImage imageNamed:imageName];
在我的应用程序包中使用图像。 我一直在添加function，允许用户使用UIImagePickerController从相机或其库中使用图像。 显然，这些图像不能在我的应用程序包中，所以我以不同的方式初始化UIImage对象：
UIImage *image = [UIImage imageWithContentsOfFile:pathToFile];
这是在第一次调整图像大小，使其与我的应用程序包中的其他文件大小相似，都是使用Jpeg格式（有趣的是，即使对于相同的文件大小，PNG也慢得多）。 换句话说，由pathToFile指向的文件是与包中的图像大小相似的文件（像素尺寸匹配，并select了压缩，因此字节数相似）。
该应用程序经历了一个循环，从原始图像，除了其他事情与这篇文章无关的小块。 我的问题是，通过循环使用创build的第二种方式花费的时间比使用第一种方式创build的图像要长得多。
我意识到第一种方法caching图像，但我不认为这是相关的，除非我不理解caching如何工作。 如果是相关因素，我怎样才能把caching添加到第二种方法？
导致瓶颈的相关部分代码是这样的：
[image drawInRect:self.imageSquare];
这里，self是UIImageView的子类。 它的属性imageSquare只是一个CGRect定义了绘制的内容。 这两个方法的部分是相同的。 那么为什么第二种方法对于类似大小的UIImage对象来说太慢了？
有什么我可以做不同的优化这个过程？
编辑：我改变访问到imageWithContentsOfFile包中的图像，并执行循环的时间从约4秒改变到刚刚超过一分钟。 所以它看起来像我需要find一些像imageNamed做caching，但与非捆绑文件的方式。
UIImage imageNamed不会简单地caching图像。 它caching一个未压缩的图像。 花费的额外时间不是由从本地存储器读取RAM而是通过解压缩图像引起的。
解决scheme是创build一个新的未压缩UIImage对象，并将其用于代码的时间敏感部分。 代码段完成后，未压缩的对象将被丢弃。 为了完整起见，下面是一个类方法的副本，从压缩的UIImage对象中返回一个未压缩的UIImage对象，这要归功于另一个线程 。 请注意，这假定数据在CGImage 。 UIImage对象并不总是这样。
+(UIImage *)decompressedImage:(UIImage *)compressedImage { CGImageRef originalImage = compressedImage.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); return decompressedImage; }