一、內(nèi)存優(yōu)化的必要性
事實(shí)上，因?yàn)槟壳?iPhone 配備的內(nèi)存越來越高，當(dāng)內(nèi)存占用過高時(shí)，并不一定會(huì)超過系統(tǒng)設(shè)定的閾值而引發(fā)強(qiáng)殺進(jìn)程。
但這并不意味著減少內(nèi)存占用是沒有意義的，因?yàn)楫?dāng)內(nèi)存占用過高時(shí)，很容易引起一系列的副作用。最直接的表現(xiàn)是 App Crash，當(dāng)然還有很多更為深遠(yuǎn)的副作用。
1. FOOM
FOOM 是最直接的影響了，當(dāng)內(nèi)存占用過多導(dǎo)致整個(gè)系統(tǒng)的可用內(nèi)存不足時(shí)，App所在的進(jìn)程容易被殺掉。而且相比于一般的 Crash 來說，F(xiàn)OOM 更難以檢測(cè)，并且也更難排查。
2. 限制并發(fā)數(shù)量
如果一個(gè)任務(wù)占用了過多的內(nèi)存，但總的內(nèi)存是有限的，那么任務(wù)的并發(fā)數(shù)將會(huì)受到直接限制。表現(xiàn)上就是 App 里某個(gè)功能可同時(shí)執(zhí)行的數(shù)量有限，或者可以同時(shí)顯示的內(nèi)容有數(shù)量限制。
同時(shí)，因?yàn)閮?nèi)存是有限資源，當(dāng)占用內(nèi)存過多時(shí)，會(huì)容易導(dǎo)致操作系統(tǒng)殺掉其它 App 的進(jìn)程來給當(dāng)前的 App 提供足夠的內(nèi)存空間，這對(duì)用戶體驗(yàn)是不利的。
3. 增加耗電
由于 iOS 系統(tǒng)的 Memory Compressor 的存在，當(dāng)可用內(nèi)存不足時(shí)，一部分 Dirty Page 會(huì)被壓縮存儲(chǔ)到磁盤中，當(dāng)用到這部分內(nèi)存時(shí)，再從磁盤里加載回來。這會(huì)造成 CPU 花費(fèi)更多的時(shí)間來等待 IO, 間接提高 CPU 占用率，造成耗電。
二、原因分析
1. 圖片顯示原理
圖片其實(shí)是由很多個(gè)像素點(diǎn)組成的，每個(gè)像素點(diǎn)描述了該點(diǎn)的顏色信息。這樣的數(shù)據(jù)是可以被直接渲染在屏幕上的，稱之為 Image Buffer。
事實(shí)上，由于圖片源文件占用的存儲(chǔ)空間非常大，一般在存儲(chǔ)時(shí)候都會(huì)進(jìn)行壓縮，非常常見的就是 JPEG 和 PNG 算法壓縮的圖片。
因此當(dāng)圖片存儲(chǔ)在硬盤中的時(shí)候，它是經(jīng)過壓縮后的數(shù)據(jù)。經(jīng)過解碼后的數(shù)據(jù)才能用于渲染，因此需要將圖片顯示在屏幕上的話，需要先經(jīng)過解碼。解碼后的數(shù)據(jù)就是 Image Buffer 。
當(dāng)圖片顯示在屏幕上時(shí)，會(huì)復(fù)制顯示區(qū)域的Image Buffer去進(jìn)行渲染。
2. 圖片真實(shí)占用內(nèi)存
對(duì)于一張正在顯示在屏幕上的，尺寸為 1920*1080 的圖片來說，如果采用 SRGB 的格式(每個(gè)像素點(diǎn)的顏色由 red,green,blue,alpha 一個(gè)共 4 個(gè) bytes 來決定)的話，那么它占用的內(nèi)存為：
也就是說，一張非常普通的圖片，解碼后占用的內(nèi)存就是 7.9 MB，這是非常夸張的。而圖片顯示時(shí)所占的內(nèi)存大小是與尺寸和顏色空間正相關(guān)的，與壓縮算法、圖片格式、圖片文件的大小沒有關(guān)聯(lián)。
三、解決方式
1. 避免將圖片放在內(nèi)存里
對(duì)于不顯示在屏幕上的圖片，在絕大部分時(shí)間里，其實(shí)是沒有必要放在內(nèi)存里的。解碼后的 UIImage 是非常大的，對(duì)于不需要顯示的圖片是不需要解碼的。而對(duì)于不顯示在屏幕上的圖片，一般也沒有必要繼續(xù)持有著 UIImage 對(duì)象。
2.圖片縮放
圖片縮放是很常見的處理方式，一般來說，常見的思想可能是重新畫一張小一點(diǎn)的圖片，往往是用 UIGraphicsBeginImageContextWithOptions的方式：
這種方式存在以下問題：
第一，默認(rèn)是 SRGB 的格式，也就是說每個(gè)像素需要占4個(gè)bytes的空間，對(duì)于一些黑白或者僅有alpha通道的數(shù)據(jù)來說是沒有必要的。
第二，需要將原圖片完全解碼后渲染出來，原圖片的解碼會(huì)造成內(nèi)存占用的高峰。
對(duì)于問題一的解決，可以使用新的 UIGraphicsImageRenderer 的方式，這種情況下框架會(huì)自動(dòng)幫你選擇對(duì)應(yīng)的顏色格式，減少不必要的消耗。
這種方式在一定的場(chǎng)景有所優(yōu)化，但是沒有解決問題二中存在的內(nèi)存峰值的問題。由于處理前的圖片并不一定展示在屏幕上，解碼后的數(shù)據(jù)是冗余信息，因此應(yīng)該避免圖片的解碼。
對(duì)于峰值過高的問題，最直接的思想是采用流式的方式進(jìn)行處理。而底層的 ImageIO 的接口就采用了這種方式：
3. 降低峰值
通過 ARC 管理內(nèi)存的對(duì)象，注冊(cè)在某個(gè) Autoreleasepool 中，Autoreleasepool 在 drain 的時(shí)候釋放已經(jīng)沒有使用的對(duì)象。
一般沒有進(jìn)行特殊處理的話，會(huì)在 Runloop 結(jié)束后，有一次 Autoreleasepool 的 drain 操作，而這次 Runloop 中生成的對(duì)象也是由這個(gè) Autoreleasepool 來管理的。這部分的原理有很多的文章介紹，這里就不多贅述了。
在圖片批量處理的過程中，由于還在一個(gè) Runloop 里，此時(shí)引用計(jì)數(shù)為 0 的對(duì)象是不會(huì)被釋放的。因此需要在每次循環(huán)后觸發(fā) Autoreleasepool 的 drain 操作：
4. 裁剪顯示的圖片
在很多場(chǎng)景下,圖片是不會(huì)完整的顯示出來的，例如下圖所示的情況：
在這種情況中，即使給 UIImageView 一張完整的圖片，最后渲染的時(shí)候也只會(huì)截取顯示區(qū)域的 Image Buffer 去進(jìn)行渲染。
這就意味著，區(qū)域外的數(shù)據(jù)，其實(shí)是沒有必要的。因此在這種場(chǎng)景下，其實(shí)只需要裁減顯示區(qū)域的圖片即可。
舉個(gè)例子，以前面提到 1920 * 1080 的圖片為例, 顯示時(shí)需要占用的內(nèi)存為 829440 bytes。如果它是以 ScaleAspectFill 的方式放置在一個(gè) 300 x 300 的 UIImageView 中時(shí)，那么其實(shí)一張 300 x 300 的圖片就足以展示，而此時(shí)這張圖片占用的內(nèi)存為 360000 bytes, 僅為前者的 43% 。
上一篇：鍵盤上怎么打出頓號(hào)？
責(zé)任編輯：
