iOS UIImage存储格式，内存使用和编码/解码 [英] iOS UIImage storage formats, memory usage and encoding / decoding
问题描述
iOS如何存储从压缩数据（jpeg2000，png，jpg等）加载的图像
How does iOS store images that are loaded from compressed data (jpeg2000, png, jpg, etc.)
示例： [UIImage imageWithData ：pngData]
它是在内部存储实际的编码字节并按需解压缩，还是永久解压缩为原始像素或其他格式？
Does it store the actual encoded bytes internally and decompress on demand, or is it decompressed into raw pixels permanently or some other format?
推荐答案
我在iPad 2上创建了一个测试应用程序，该应用程序加载了200个384x384像素的jpeg2000图像文件（117,964,800字节的原始像素） ）使用以下三种方法： [UIImage imageNamed] ， [UIImage imageWithContentsOfFile：] 和 [UIImage imageWithData] 。 jpeg2000文件集是100个纹理，然后我将其复制到一个带有copy后缀的额外100个文件中，以查看iOS是否进行了任何重复的文件检查。更多信息如下。
I created a test app on an iPad 2 that loaded 200 384x384 pixels jpeg2000 image files (117,964,800 bytes worth of raw pixels) using the following three methods: [UIImage imageNamed], [UIImage imageWithContentsOfFile:] and [UIImage imageWithData]. The jpeg2000 file set was 100 textures which I then copied into an extra 100 files with a "copy" suffix, to see if iOS does any duplicate file checking, which it does. More on that down below.
- 只需加载图像并将其存储在一个数组中。
- 一个单独的按钮为每个图像创建UIImageViews并显示它们。
以下是结果：
步骤1：仅增加内存关于所有jpeg2000文件的总和（每个大约50K，所以内存大约增加了5 MB）。我假设此时重复文件没有重复，并且由iOS进行了某种程度的整合，因为如果没有重复检查，此时内存将增加10MB。
Step 1: Memory only increased by about the sum total of all the jpeg2000 files (which were about 50K each, so memory went up by about 5 MB). I assume the duplicate files were not duplicated at this point and were somehow consolidated by iOS as memory would have gone up by 10MB at this point if there were no duplicate checking.
步骤2：内存显着上升（约200 MB），大概是因为图像被解码为BGRA格式以准备显示在的UIImageView。看起来在这个阶段没有重复过滤，并且为每个图像分配了单独的原始内存。我不知道为什么，但这比实际的原始像素内存使用量大约多80 MB。
Step 2: Memory went up significantly (to about 200 MB), presumably because the images were decoded into BGRA format in preparation to display in UIImageView. It looks like there was no duplicate filtering at this stage and that separate raw memory was allocated for every image. I'm not sure why, but this was about 80 MB more than the actual raw pixel memory usage should have been.
第1步：内存使用情况与 [UIImage imageNamed：] 完全相同，因此有重复过滤这个阶段。
Step 1: Memory usage was identical to [UIImage imageNamed:], so there was duplicate filtering at this stage.
第2步：内存使用量增加到130 MB。由于某种原因，这比 [UIImage imageNamed：] 低70 MB。这个数字更接近于200张图像的预期原始像素内存量。
Step 2: Memory usage went up to 130 MB. For some reason this is 70 MB lower than [UIImage imageNamed:]. This number is much closer to the expected amount of raw pixel memory for the 200 images.
[NSData dataWithContentsOfFile：] 首先使用。
第1步：内存用法是15 MB。我假设这里没有重复过滤，因为它接近所有jpeg2000数据的总文件大小。
Step 1: Memory usage was 15 MB. I assume there was no duplicate filtering here as this is close to the total file size for all the jpeg2000 data.
第2步：内存使用量增加到139 MB。这超过 [UIImage imageWithContentsOfFile：] ，但不是很多。
Step 2: Memory usage went up to 139 MB. This is more than [UIImage imageWithContentsOfFile:], but not by much.
iOS似乎引用了使用上述三种方法加载的 UIImage 的压缩数据，直到实际需要原始像素为止，此时它已解码。
iOS appears to reference the compressed data for a UIImage loaded using the above three methods until the raw pixels are actually needed, at which point it is decoded.
[UIImage imageNamed：] 由于我的所有图片视图都引用了图像，因此从未取消分配内存。如果我交错加载并允许运行循环执行，它将释放未引用的图像的内存。一个优点是重复的 [UIImage imageNamed：] 对同一图像的调用基本上是免费的。不要将此方法用于GUI图像以外的任何内容，否则可能会耗尽内存。
[UIImage imageNamed:] never deallocated the memory because of all my image views referencing the images. It would have deallocated memory of non-referenced images had I staggered the loading and allowed the run loop to execute. One advantage is that repeated [UIImage imageNamed:] calls to the same image were essentially free. Do not use this method for anything other than GUI images, or you may run out of memory.
[UIImage imageWithContentsOfFile：] 在内存使用情况下的行为类似于 [UIImage imageNamed：] ，直到需要原始像素为止，此时由于某种原因，它在内存使用方面效率更高。当取消分配UIImage时，此方法还会立即释放内存。使用相同文件重复调用 [UIImage imageWithContentsOfFile：] 似乎使用缓存副本，直到所有 UIImage 为止引用该文件已被解除分配。
[UIImage imageWithContentsOfFile:] behaves like [UIImage imageNamed:] in memory usage until the raw pixels are needed, at which point it is much more efficient in memory usage for some reason. This method also causes the memory to be freed immediately when the UIImage is deallocated. Repeated calls to [UIImage imageWithContentsOfFile:] with the same file appear to use a cached copy until all the UIImage's referencing the file are deallocated.
[UIImage imageWithData：] 不进行缓存或重复检查，并始终创建一个新的图像。
[UIImage imageWithData:] does no caching or duplicate checking and always creates a new image.
我测试了与PNG文件相同的设置，imageNamed的步骤1结果和imageWithContentsOfFile显示使用的内存更少（约0.5 MB），imageWithData显示了压缩的所有PNG文件的总和。我的猜测是iOS只是存储对文件的引用，并且在解码时间之前不会对其执行任何其他操作。 PNG的第2步结果是相同的。
I tested the same set as PNG files and the step 1 results for imageNamed and imageWithContentsOfFile showed even less memory being used (about 0.5 MB), and imageWithData showed the sum total of all the PNG files compressed. My guess is that iOS simply stores a reference to the file and doesn't do anything else with it until decoding time. The step 2 results for PNG were identical.
这篇关于iOS UIImage存储格式，内存使用和编码/解码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
