最近，遇到一個問題，有個控制器，一進去就crash,而且手機非常的燙，用instrument跑了跑，發現內存暴增幾百兆；如圖：

Snip20160725_3.png

　　圖中可以看出，內存暴增的罪魁禍首是YYImage，再進一步定位問題，如圖：

Snip20160725_6.png

[self sd_setImageWithURL:[NSURL URLWithString:imageUrl] placeholderImage:[UIImage imageNamed:@"defaulImage"] options:SDWebImageProgressiveDownload completed:nil];

instrument分析圖：

Snip20160725_4.png

Snip20160725_8.png

當完成圖片加載或者從本地加載圖片時，還會有輕微的卡頓。
因為當顯示或者繪制的時候，UIKit 只做了額外的延遲初始化和消耗很高解碼。
而下面的代碼片段，從后臺線程解壓縮成合適的格式，從而讓系統不必做額外的轉換。
然后在主線程上顯示

我又疑惑了，既然是為了優化，為啥會適得其反呢？我百思不得其解，最后在SDWebImage的issues找到了相關的討論：
https://github.com/rs/SDWebImage/issues/538
其中一個harishkashyap大神是這么回答的：

harishkashyap commented on Dec 23, 2014
Its the memory issue again. decodedImageWithImage takes up huge memory and causes the app to crash. I have added an option to put this off in the library but defaulting to YES so there aren't any breaking changes. If you put off the decodeImageWithImage method in both image cache and image downloader then you shouldn't be seeing the VM: CG Raster data on the top consuming lots of memory

decodeImageWithImage is supposed to decompress images and cache them so the loading on tableviews/collectionviews become better. However, with large set of images being loaded, the experience worsened and the memory of uncompressed images even with thumbnails can consume GBs of memory. Putting this off only improved performance.

[[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
[[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];

https://github.com/harishkashyap/SDWebImage/tree/fix-memory-issues

這位大神提到，decodeImageWithImage這個方法用于對圖片進行解壓縮并且緩存起來，以保證tableviews/collectionviews 交互更加流暢，但是如果是加載高分辨率圖片的話，會適得其反，有可能造成上G的內存消耗。該大神建議，對于高分辨率的圖片，應該在圖片解壓縮后，禁止緩存解壓縮后的數據，相關的代碼處理為：

[[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
[[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];

雖然這位大神給了肯定的答案，但是為什么會如此呢？
我查閱了apple官方文檔對CGBitmapContextCreate函數的注解：

Snip20160725_10.png

圖中紅框部分的參數，引起了我的注意：

bitsPerComponent 表示存入內存中的每個像素中的每一個組件所占的位數；
bytesPerRow 表示存入內存中的位圖的每一行所占的字節數；

我猜測，解壓縮操作中，每一個像素點都會分配一個空間來存儲相關值，那么分辨率越高的圖片，就意味著更多數量的像素點，也就意味著需要分配更多的空間！所以對于高分辨率圖來說，如果緩存解壓縮之后的數據，即使是幾M的圖片，也是有可能消耗上G的內存！
　　既然如此，我決定按照harishkashyap大神的方法，直接讓下載高分辨率圖的地方，避免緩存解壓縮后的數據操作！
　　項目中，高清圖涉及到的地方，都全部已經封裝起來了，那么就輕松了很多。為了保證封裝類不對外界產生影響，我只在調用封裝類時，禁用緩存解壓縮數據，調用完畢再恢復原設置即可。這樣既能保證高分辨率圖不crash，也能保證其他地方，普通圖片依舊可以通過緩存解壓縮數據進行優化。

SDWebImage 5.0解決辦法：

https://github.com/SDWebImage/SDWebImage/pull/2283#issuecomment-490424361

SDWebImage 4.x解決辦法：
　　由于封裝的是一個控制器，所以我決定在控制器loadView方法中禁用緩存解壓縮數據，在delloc方法中恢復原設置：
1、首先在封裝的控制器中定義變量用于存儲原設置：

static BOOL SDImageCacheOldShouldDecompressImages = YES;
static BOOL SDImagedownloderOldShouldDecompressImages = YES;

2、loadView中保存原設置并且禁用緩存解壓縮數據：

SDImageCache *canche = [SDImageCache sharedImageCache];
// SDImageCacheOldShouldDecompressImages = canche.shouldDecompressImages;
// canche.shouldDecompressImages = NO;
// 上面的被廢掉了，目前的寫法是：
SDImageCacheOldShouldDecompressImages = canche.config.shouldDecompressImages;
canche.config.shouldDecompressImages = NO;

SDWebImageDownloader *downloder = [SDWebImageDownloader sharedDownloader];
SDImagedownloderOldShouldDecompressImages = downloder.shouldDecompressImages;
downloder.shouldDecompressImages = NO;

3、dealloc中恢復原設置：

-(void)dealloc {
    SDImageCache *canche = [SDImageCache sharedImageCache];
    canche.config.shouldDecompressImages = SDImageCacheOldShouldDecompressImages;
    
    SDWebImageDownloader *downloder = [SDWebImageDownloader sharedDownloader];
    downloder.shouldDecompressImages = SDImagedownloderOldShouldDecompressImages;
}

再次用instrument跑了一下，方法果然有效，內存徹底降下來了，如圖：

Snip20160725_13.png

當然，你也可以設置SDWebImage的其他參數，比如是否緩存到內存以及內存緩存最高限制等，來保證內存安全：

shouldCacheImagesInMemory 是否緩存到內存
maxMemoryCost  內存緩存最高限制

號外：蘋果官方給出了一個下載高清大圖的demo,內存消耗很低。感興趣的朋友也可以看看：
https://developer.apple.com/library/ios/samplecode/LargeImageDownsizing/Introduction/Intro.html