前段日子，在做一个预览网络图片的小功能，遇到了一个问题，在打开图片时，有时候会发现内存会暴增到一百甚至几百多兆，最后导致程序奔溃。经过排查，发现内存暴增的时候，图片分辨率很高。
一、图片解压缩
通过Instrucments分析，内存暴增的部分代码发生在SDWebImage库中的图片解压方法CGBitmapContextCreate。
这篇博客对其做了比较好的分析和处理意见：使用SDWebImage和YYImage下载高分辨率图，导致内存暴增的解决办法
然而，解除了图片解压缩处理，发现内存并没有降下来：
发现内存的主要消耗发生在图像的内存映射mmap（具体是什么也不是很清楚，后续研究下），然后取消图片显示，发现内存并未降下来，分析是图像缓存到了内存当中并未释放导致。
题外话-图片加载的性能优化
图片的加载主要有两种方式：
1. UIImage imageName: 自带缓存方式，也就是说，只要加载一次，便一直处于内存当中，直到程序退出。所以，第二次加载会很快，适合大量使用的场景。
2. UIImage imageWithContentsOfFile: 适用于大图，并且一次加载或少加载。不用时，可释放内存。
一些比较耗时的图片，可以考虑加载到CALayer上，CALayer有GPU加速，对性能提升有比较大的改善，缺点是可能会导致view层上动画失效，所以方案上，可以把一些耗时的图片，放在layer的层。
二、图片内存缓存
SDImageCache有个属性shouldCacheImagesInMemory，其默认值是YES，意思是缓存图像到内存中。可以将其置为NO已解除内存缓存。
SDImageCache *cache = [SDImageCache sharedImageCache];
cache.shouldCacheImagesInMemory = YES;
再次运行，发现当图片不在显示时，内存会回到正常水平。但依然存在一个问题，就是图片加载出来时，内存依然会达到一百多兆，看来我们还需对图片本身进行处理了。
上述两种方式，主要解决内存累加的问题。但如果第一次进入view，图片全部渲染在view上时，内存就崩溃了。那我们只能在图片上做文章了。我们加载的高清大图如果差不多都是3000*2000，也可能比这个还大，就算我们的程序是iPadApp，iPad 4的分辨率才多少，这些图远远大于设备的分辨率，完全是资源浪费，所以我们通常的一个做法，便是将这样的图以小尺寸渲染到view上。
附：图片加载到ios内存后是基本以原生形式保存的，也就是长*宽*4个字节（RGBA），因此分辨率很大的图片会占用相当大的内存。解决方法可以这样：将图片压缩到合适的长宽大小,同时保存比例。
三、图片压缩
图片本身过大，可以压缩后再显示。图片压缩的方法可以用苹果自带的API：
UIImageJPEGRepresentation(UIImage * __nonnull image, CGFloat compressionQuality)
这里如果无论怎么调compressionQuality的值还是不能减少内存的占用，则需要对图片进行裁切。
“对于每张图片进行压缩，其实有一个最小值，此后无论再怎么改小压缩系数都无济于事。”
例如：
- (NSData*)imageWithImage:(UIImage*)image scaledToSize:(CGSize)newSize
{
UIGraphicsBeginImageContext(newSize);
[image drawInRect:CGRectMake(0,0,newSize.width,newSize.height)];
UIImage* newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();returnUIImageJPEGRepresentation(newImage,0.8);
}
偶然看到一个评论，对压缩解释的比较好：
图片的压缩其实是俩概念，
1、是 “压” 文件体积变小，但是像素数不变，长宽尺寸不变，那么质量可能下降，
2、是 “缩” 文件的尺寸变小，也就是像素数减少。长宽尺寸变小，文件体积同样会减小。
这个 UIImageJPEGRepresentation(image, 0.0)，是1的功能。这个 [sourceImage drawInRect:CGRectMake(0,0,targetWidth, targetHeight)] 是2的功能。
所以，这俩你得结合使用来满足需求，不然你一味的用1，导致，图片模糊的不行，但是尺寸还是很大。
参考：
2. ios 对图片进行压缩
