原文鏈接：http://www.reibang.com/p/1c9de8dea3ea
最近巡莹，遇到一個(gè)問題司志，有個(gè)控制器，一進(jìn)去就crash,而且手機(jī)非常的燙降宅，用instrument跑了跑骂远，發(fā)現(xiàn)內(nèi)存暴增幾百兆；如圖：
Snip20160725_3.png
圖中可以看出腰根，內(nèi)存暴增的罪魁禍?zhǔn)资荵YImage激才，再進(jìn)一步定位問題，如圖：
Snip20160725_6.png
現(xiàn)在已經(jīng)可以很清楚的知道，具體是哪些代碼導(dǎo)致內(nèi)存飆升的瘸恼，這個(gè)方法“YYCGImageCreateDecodeCopy”劣挫，主要是對圖像進(jìn)行解壓縮操作；同樣的东帅，換成SDWebImage压固，也出現(xiàn)了相同情況，由于某些原因靠闭，之后的分析都將以SDWebImage為例帐我。
先貼上調(diào)用的SDWebImage的代碼：
[selfsd_setImageWithURL:[NSURLURLWithString:imageUrl] placeholderImage:[UIImageimageNamed:@"defaulImage"] options:SDWebImageProgressiveDownload completed:nil];
instrument分析圖：
Snip20160725_4.png
代碼定位：
Snip20160725_8.png
同樣的，也是在解壓縮的時(shí)候阎毅，出現(xiàn)內(nèi)存飆升焚刚，但是為什么會這樣呢？
首先我想到“Create”必須得對應(yīng)一個(gè)“Release”扇调，于是我認(rèn)真的看了每一行代碼矿咕，無論是YYImage還是SDWebImage，都嚴(yán)格遵守了這一準(zhǔn)則狼钮，既然都有Release碳柱，那么就不是內(nèi)存泄露了，應(yīng)該是在這幾行代碼執(zhí)行的過程中，產(chǎn)生的內(nèi)存消耗〈樽ィ可是怎么會消耗這么大呢糠雨？一張圖片也就幾M的大小啊，這個(gè)解壓縮存在的意義是什么呢标沪？
我從“H_偉華 博樂家園”的一篇博客中找到了解壓縮存在的意義(http://blog.163.com/huang1988519@126/blog/static/737875752013101803137445/)
當(dāng)完成圖片加載或者從本地加載圖片時(shí)，還會有輕微的卡頓。因?yàn)楫?dāng)顯示或者繪制的時(shí)候半火，UIKit只做了額外的延遲初始化和消耗很高解碼。而下面的代碼片段季俩，從后臺線程解壓縮成合適的格式钮糖，從而讓系統(tǒng)不必做額外的轉(zhuǎn)換。然后在主線程上顯示
我又疑惑了酌住，既然是為了優(yōu)化店归，為啥會適得其反呢？我百思不得其解酪我，最后在SDWebImage的issues找到了相關(guān)的討論：
https://github.com/rs/SDWebImage/issues/538
其中一個(gè)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這個(gè)方法用于對圖片進(jìn)行解壓縮并且緩存起來，以保證tableviews/collectionviews 交互更加流暢都哭，但是如果是加載高分辨率圖片的話肄满，會適得其反谴古，有可能造成上G的內(nèi)存消耗。該大神建議稠歉，對于高分辨率的圖片掰担，應(yīng)該在圖片解壓縮后，禁止緩存解壓縮后的數(shù)據(jù)怒炸，相關(guān)的代碼處理為：
[[SDImageCache sharedImageCache]setShouldDecompressImages:NO];[[SDWebImageDownloader sharedDownloader]setShouldDecompressImages:NO];
雖然這位大神給了肯定的答案带饱，但是為什么會如此呢？
我查閱了apple官方文檔對CGBitmapContextCreate函數(shù)的注解：
Snip20160725_10.png
圖中紅框部分的參數(shù)阅羹，引起了我的注意：
bitsPerComponent 表示存入內(nèi)存中的每個(gè)像素中的每一個(gè)組件所占的位數(shù)勺疼；
bytesPerRow 表示存入內(nèi)存中的位圖的每一行所占的字節(jié)數(shù)；
我猜測捏鱼，解壓縮操作中执庐，每一個(gè)像素點(diǎn)都會分配一個(gè)空間來存儲相關(guān)值，那么分辨率越高的圖片导梆，就意味著更多數(shù)量的像素點(diǎn)轨淌，也就意味著需要分配更多的空間！所以對于高分辨率圖來說看尼，如果緩存解壓縮之后的數(shù)據(jù)递鹉，即使是幾M的圖片，也是有可能消耗上G的內(nèi)存藏斩！
既然如此躏结，我決定按照harishkashyap大神的方法，直接讓下載高分辨率圖的地方狰域，避免緩存解壓縮后的數(shù)據(jù)操作媳拴！
項(xiàng)目中，高清圖涉及到的地方兆览，都全部已經(jīng)封裝起來了屈溉，那么就輕松了很多。為了保證封裝類不對外界產(chǎn)生影響拓颓，我只在調(diào)用封裝類時(shí)语婴，禁用緩存解壓縮數(shù)據(jù)描孟，調(diào)用完畢再恢復(fù)原設(shè)置即可驶睦。這樣既能保證高分辨率圖不crash，也能保證其他地方匿醒，普通圖片依舊可以通過緩存解壓縮數(shù)據(jù)進(jìn)行優(yōu)化场航。
由于封裝的是一個(gè)控制器，所以我決定在控制器loadView方法中禁用解壓縮廉羔，在delloc方法中恢復(fù)原設(shè)置：
1溉痢、首先在封裝的控制器中定義變量用于存儲原設(shè)置：
staticBOOLSDImageCacheOldShouldDecompressImages =YES;staticBOOLSDImagedownloderOldShouldDecompressImages =YES;
2、loadView中保存原設(shè)置并且禁用緩存解壓縮數(shù)據(jù)：
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中恢復(fù)原設(shè)置：
-(void)dealloc {? ? SDImageCache *canche = [SDImageCache sharedImageCache];? ? canche.config.shouldDecompressImages = SDImageCacheOldShouldDecompressImages;? ? ? ? SDWebImageDownloader *downloder = [SDWebImageDownloader sharedDownloader];? ? downloder.shouldDecompressImages = SDImagedownloderOldShouldDecompressImages;}
再次用instrument跑了一下髓削，方法果然有效，內(nèi)存徹底降下來了镀娶，如圖：
Snip20160725_13.png
當(dāng)然立膛，你也可以設(shè)置SDWebImage的其他參數(shù)，比如是否緩存到內(nèi)存以及內(nèi)存緩存最高限制等梯码，來保證內(nèi)存安全：
shouldCacheImagesInMemory 是否緩存到內(nèi)存
maxMemoryCost? 內(nèi)存緩存最高限制
號外：蘋果官方給出了一個(gè)下載高清大圖的demo,內(nèi)存消耗很低宝泵。感興趣的朋友也可以看看：
https://developer.apple.com/library/ios/samplecode/LargeImageDownsizing/Introduction/Intro.html
