我注意到有些人在CGContext上重画图像。以防止延迟解压，这导致我们的应用程序出现错误。
错误在于图像的大小声称保持不变，但 CGImageDataProvider数据附加了额外的字节。
例如，我们从网上下载了一张797x500的PNG图片，AsyncImageView重绘并返回重绘的图像。
这是代码:
UIImage *image = [[UIImage alloc] initWithData:data];
if (image)
{
// Log to compare size and data length...
NSLog(@"BEFORE: %f %f", image.size.width, image.size.height);
NSLog(@"LEN %ld", CFDataGetLength(CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage))));
// Original code from AsyncImageView
//redraw to prevent deferred decompression
UIGraphicsBeginImageContextWithOptions(image.size, NO, image.scale);
[image drawAtPoint:CGPointZero];
image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
// Log to compare size and data length...
NSLog(@"AFTER: %f %f", image.size.width, image.size.height);
NSLog(@"LEN %ld", CFDataGetLength(CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage))));
// Some other code...
}
日志显示如下:
BEFORE: 797.000000 500.000000
LEN 1594000
AFTER: 797.000000 500.000000
LEN 1600000
我决定一一打印每个字节，果然有十二个0为每行附加 s。
基本上，重绘导致图像数据成为 800x500 图像的数据。因此，当我们的应用程序想要查看797 * row + column时，它查看了错误的像素。第一个像素。
我们没有使用任何大图像，因此延迟解压缩不会造成任何问题，但如果我决定使用此方法来重绘图像，我可能会引入一个微妙的错误。
有人能解决这个问题吗？或者这是苹果引入的一个错误，我们真的无能为力？
最佳答案
正如您所发现的，行会被填充到方便的大小。这通常是为了使向量算法更加高效。如果您要以这种方式使用 CGImage，您只需要适应该布局即可。您需要调用CGImageGetBytesPerRow来找出实际分配的字节数，然后根据该值调整偏移量(bytesPerRow * row + column)。
这可能最适合您，但如果您需要消除填充，您可以通过创建自己的 CGBitmapContext 并渲染到其中来实现。如果您不熟悉的话，这是一个关于 Stack Overflow 的热门话题。例如:How to get pixel data from a UIImage (Cocoa Touch) or CGImage (Core Graphics)?
关于iOS 重绘图像以防止延迟解压导致图像变大，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43669682/