iOS內(nèi)存分析上-圖片加載內(nèi)存分析
簡介
對于大多數(shù)App來說，內(nèi)存占用主要就是圖片。本文將從實(shí)用的角度分析，iOS圖片的內(nèi)存占用、測量、優(yōu)化等。
iOS內(nèi)存-有什么影響
在移動操作系統(tǒng)設(shè)備中，是不能像PC一樣進(jìn)行內(nèi)存swap的，而隨著用戶的實(shí)用，打開的應(yīng)用越來越多，應(yīng)用使用的內(nèi)存也越來越多。當(dāng)占用的內(nèi)存達(dá)到某個(gè)臨界值時(shí)，iOS系統(tǒng)會嘗試按照優(yōu)先級逐個(gè)kill掉應(yīng)用程序，以維護(hù)系統(tǒng)的流暢和穩(wěn)定。
當(dāng)iOS系統(tǒng)在清理內(nèi)存過程中，優(yōu)先級到了前臺正在運(yùn)行的應(yīng)用程序，那么就會出現(xiàn)前臺應(yīng)用程序閃退的現(xiàn)象，也就是通常所說的OOM。
iOS內(nèi)存-關(guān)注什么
實(shí)際上，對于iOS系統(tǒng)內(nèi)存，根據(jù)劃分的方法方式，有很多內(nèi)存種類，比較常見的有clean memory, dirty memory，有virtual memory, resident memory，等等。那么這么多的內(nèi)存，重點(diǎn)要關(guān)注什么呢？
For the purposes of this guide, Persistent Bytes for All Heap & Anonymous VM represents your app's memory footprint.
這句話來自蘋果的官方技術(shù)文檔，翻譯過來就是，在內(nèi)存優(yōu)化中，需要關(guān)注的memory footprint就是“Persistent Bytes for All Heap & Anonymous VM”。也就是下圖中instruments-Allocation中的①。至于提到的memory footprint，可以參考wiki。
也就是說，iOS內(nèi)存優(yōu)化看“memory footprint”，“memory footprint”優(yōu)化看“Persistent Bytes for All Heap & Anonymous VM”
iOS內(nèi)存-圖片內(nèi)存怎么算
先打一個(gè)比喻，我們平時(shí)為了傳輸方便，往往會對文件進(jìn)行壓縮，得到一個(gè).rar或者.zip的壓縮包，當(dāng)我們要閱讀文件時(shí)，需要先解壓壓縮包，得到.doc或者.txt等文檔，然后再打開閱讀。
類似的，我們平時(shí)看到的.jpg，.png，就是上面所說的壓縮包，這個(gè)文件是不能直接上屏渲染的，需要先解壓縮，然后才能在上屏。而我們平時(shí)無感知，直接打開文件就能看，是因?yàn)榻獯a渲染很快，在你點(diǎn)擊的時(shí)候就完成了解碼+渲染的操作了，類似.zip壓縮包也可以不解壓直接預(yù)覽一樣。
那么顯而易見，我們看到的磁盤上的圖片和最終渲染出來的圖片是不同的，那么圖片實(shí)際加載渲染時(shí)的內(nèi)存要怎么算呢。在iOS中可以通過以下公式快速計(jì)算。其中4是每個(gè)像素占用的byte，在iOS中固定為4(至少目前為止是的)，Android中需要根據(jù)實(shí)際的調(diào)整，一般也是4。
內(nèi)存大小=像素寬*像素高*4
iOS內(nèi)存-圖片內(nèi)存怎么取
如果要進(jìn)行圖片內(nèi)存的優(yōu)化，首先得保證能監(jiān)測到圖片的內(nèi)存大小。圖片內(nèi)存的測量，各家有各家的方案，但是總的來說，都是在某個(gè)或多個(gè)圖片加載的入口，進(jìn)行侵入或非侵入AOP，進(jìn)行相關(guān)的計(jì)算。
這里推薦一個(gè)方法，實(shí)用NSHashtable，弱引用持有對象。將圖片的對象放到這個(gè)弱引用的hash表中，可以實(shí)時(shí)查看當(dāng)前仍存活的所有圖片對象，并據(jù)此計(jì)算圖片占用的內(nèi)存。
iOS中UIImage內(nèi)存占用：
UIImage內(nèi)存占用大?。篿mage.size.width*image.size.height*image.scale
iOS內(nèi)存-圖片內(nèi)存優(yōu)化
iOS圖片內(nèi)存優(yōu)化，大的方向就是：
少用，勤釋放
就是在頁面中同時(shí)加載的圖片數(shù)量要少，單張圖片的大小要小，圖片占用的內(nèi)存要勤釋放，用CPU換內(nèi)存。
一個(gè)典型的優(yōu)化就是，UITableView中，cell的reuse。單個(gè)cell的高度推薦小于1屏，cell要能夠重用，列表滾動時(shí)，cell中的圖片按需加載和釋放。能夠做到這些，一般的圖片內(nèi)存問題都能夠很好的解決。
iOS內(nèi)存-圖片按需加載
目前流行的圖片加載，都會選取CDN，將原圖進(jìn)行初步的壓縮，然后加載，但是這個(gè)更多的考慮的是服務(wù)的的性能，負(fù)載均衡等等，客戶端的收益基本就只有流量一條?？蛻舳藘?nèi)存的優(yōu)化微乎其微。
根據(jù)上面說的圖片內(nèi)存解釋，我們知道圖片內(nèi)存暴漲就是在對其解壓縮時(shí)。如果看過iOS最流行的圖片加載框架SDWebImage，和騰訊開源圖片框架LKImageKit，可以發(fā)現(xiàn)LKImageKit有一個(gè)很精細(xì)的圖片加載優(yōu)化，就是在圖片解碼時(shí)，根據(jù)加載圖片的view的frame，進(jìn)行解碼。這樣就避免了一個(gè)很小的view，加載一張很大的圖片，消耗大量內(nèi)存的情況。
在SDWebImage中，要實(shí)現(xiàn)這個(gè)feature會有點(diǎn)麻煩。需要將上層調(diào)用的frame透傳到最下面的解碼部分，且需要做一些錯誤校驗(yàn)。
此外，需要注意的是，壓縮率比較高的圖片，在進(jìn)行這種二次壓縮時(shí)，壓縮后的圖片有可能會有很嚴(yán)重的失真。
