Question

我必须将50个方形图像（600px x 600px）分成9个相等尺寸（200x200）的方形部分。为了获得每个部分，我使用方法：

-(UIImage *)getSubImageFrom:(UIImage *)img WithRect:(CGRect)rect
{
UIGraphicsBeginImageContext(rect.size);
CGContextRef context = UIGraphicsGetCurrentContext();

// translated rectangle for drawing sub image
CGRect drawRect = CGRectMake(-rect.origin.x, -rect.origin.y, img.size.width, img.size.height);

// clip to the bounds of the image context
// not strictly necessary as it will get clipped anyway?
CGContextClipToRect(context, CGRectMake(0, 0, rect.size.width, rect.size.height));

// draw image
[img drawInRect:drawRect];

// grab image
UIImage* subImage = UIGraphicsGetImageFromCurrentImageContext();

CGContextRelease(context);

return subImage;
}

这对我来说足够快......从今天开始。我曾经使用[UIImage imageNamed：]方法加载图像。这个方法不会自动释放内存，直到应用程序收到内存警告......这对我来说是不可接受的。

所以我开始使用[UIImage imageWithContentsOfFile]。内存分配问题消失了...不幸的是我的裁剪方法（ - （UIImage *）getSubImageFrom：（UIImage *）img WithRect：（CGRect）rect）开始工作慢20倍！现在几个小时自从我开始寻找解决方案......没有结果。希望你能帮帮我。

祝你好运！

PS。我尝试使用此问题CGContextDrawImage is EXTREMELY slow after large UIImage drawn into it中的提示，但没有任何结果。

Answer 1

这就是我们所说的“权衡”。您抱怨+[UIImage imageNamed:]使事情变得更快但使用更多内存，+[UIImage imageWithContentsOfFile:]速度慢但不使用尽可能多的内存。后者慢的原因是，每当你调用+[UIImage imageWithContentsOfFile:]时，它必须从“磁盘”读取和解码图像，这需要时间（如你所知，这是非常重要的时间）。当您使用+[UIImage imageNamed:]时，它会被读取并解码一次，然后读取/解码操作的结果将保留在内存中，直到出现内存警告。这意味着后续访问该映像（在内存警告之前）会很快。

这听起来像是一种很好的方法，可以将图像缓存在可以控制其生命周期的缓存中。 NSCache是显而易见的选择，因为它也被挂钩到系统内存钩子中，但您可以使用-removeObjectForKey:

更快地删除事物

另一种方法可能是创建子图像一次并将其写入磁盘（查找NSCachesDirectory以获得放置此类内容的好地方）。这将消除不止一次执行此（相对昂贵的）子集操作的需要，并且较小的图像（假设您不需要它们一次全部）从磁盘加载的速度可能比更大的图像。

玩魔鬼的拥护者一分钟：如果UIImage在发出内存警告时做了正确的事情，你为什么要关心它使用内存？这个内存使用是否真的导致你的应用程序被杀？（我从经验中知道记忆警告并不是联锁的 - 也就是说你没有足够的时间在你的过程被杀之前减少你的消耗 - 但你真的遇到了这个问题吗？换句话说，你的机会是否有可能？减少内存消耗的努力可能有资格作为过早优化吗？

CoreGraphics：大规模图像分区

1 个答案: