深入分析iOS應用中對於圖片緩衝的管理和使用_IOS

我們的 iOS 應用都包含了大量的映像。建立富有吸引力的視圖，主要依賴於大量的裝飾圖片，所有這些首先必須從遠程伺服器擷取。如果每次開啟應用都要從伺服器一次又一次的擷取每個映像，那麼使用者體驗肯定達不到好的效果，所以本機快取遠程映像是非常有必要的。

兩種方式載入本地圖片
1.通過imageNamed:方法載入圖片
用過這種方式載入圖片，一旦圖片載入到記憶體中，那麼就不會銷毀，一直到程式退出。（也就是說imageNamed:會有圖片緩衝的功能，當下次訪問圖片的時候速度會更快。）
用這種方式載入圖片，圖片的記憶體管理並不受程式員控制。

複製代碼 代碼如下:

UIImage *image = [UIImage imageNamed: @“image”]

的意思是建立一個UIImage對象，並不是說image這個本身就是一張圖片，而是image指向一張圖片。在建立這個對象的時候實際上並沒有把真正的圖片載入到記憶體裡，而是等到用到圖片的時候才會載入。
如上例，如果把image對象設定為nil，如果是其它對象，那麼沒有強指標指向一個對象，這個對象就會銷毀；但是即使image = nil，它會指向的圖片資源也不會銷毀。
2.通過imageWithContentsOfFile:方式載入圖片
使用這個方法載入圖片，當指向圖片對象的指標銷毀或指向其它對象，這個圖片對象沒有其它強指標指向，這個圖片對象會銷毀，不會一直在記憶體中停留。

因為沒有緩衝，所以如果相同的圖片多次載入，那麼也會有多個圖片對象來佔用記憶體，而不是用緩衝的圖片。

使用這個方法，需要file的全路徑（之前用NSString, NSArray之類的負載檔案也是一樣的，比如stringWithContentsOfFile:，看到file就知道是需要傳入全路徑。）

複製代碼 代碼如下:

NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageName ofType:@"png"];
UIImage *image = [UIImage imageWithContentsOfFile:imagePath];

注意如果圖片在Images.xcassets中，是不能使用這個方法的。所以說想要自己進行圖片的記憶體管理（不希望有緩衝圖片），那麼要將圖片資源直接拖入工程，而不是放在Images.xcassets中。

快速隊列和慢速隊列
我們設定了兩個隊列，一個串列，一個並行。在螢幕上被迫切要求的圖片進入並行隊列（fastQueue），可能晚點才需要的圖片進入串列隊列（slowQueue）。
就UITableView的實現而言，這意味著在螢幕上的表格單元從fastQueue擷取圖片， 每個關閉的螢幕行的圖片從slowQueue預先載入。

現在不需要處理圖片

假設我們要從伺服器上請求包含30條事件的一頁資訊回來，一旦這些內容請求回來時我們就可以排隊等待預取其中的每一張圖。

複製代碼 代碼如下:

- (void)pageLoaded:(NSArray *)newEvents {   
    for (SGEvent *event in newEvents) {       
       [SGImageCache slowGetImageForURL:event.imageURL thenDo:nil];   
    }
}

slowGetImageForURL:這個方法將圖片添加到slowQueue這個隊列當中，允許它們在不阻塞網路通訊的前提下被一張一張的取出來。
thenDo:這個代碼塊在這裡是沒有被實現，是因為我們目前還不需要對圖片做任何事情。所有我們需要做的就是確保它們在本地磁碟緩衝當中，並且隨時準備在螢幕上滑動表格時來使用。

現在就要處理圖片

顯示在螢幕上的表格希望立即顯示它們的圖片，所以在table cell子類當中實現：

複製代碼 代碼如下:

- (void)setEvent:(SGEvent *)event {   
    __weak SGEventCell *me = self;   
    [SGImageCache getImageForURL:event.imageURL thenDo:^(UIImage *image) {       
       me.imageView.image = image;    }
    ];
}

getImageForURL:這個方法將抓取圖片的過程添加到fastQueue這個隊列當中，意味著只要iOS系統允許，它們會並行被地執行。如果抓取圖片的過程已經存在於slowQueue隊列當中，它會被移動到fastQueue隊列中，從而避免重複請求。

一直非同步

等等，getImageForURL:不是一個非同步方法呼叫嗎？如果你明知道圖片已經在緩衝中，但是卻不想在主線程上立即使用它嗎？直覺告訴你那是錯誤的。
從磁碟上載入圖片太費資源，同樣解壓圖片也會費很多資源。可以在滑動的過程當中進行配置和添加表格，這最後一件你想在滑動表格時做的事是很危險地，因為它會阻塞主線程，會有卡頓的現象出現。
使用getImageForURL:可以讓磁碟載入的動作脫離主線程，於是當thenDo:這個用於收尾工作的代碼塊執行的時候它已經有了一個UIImage執行個體，從而不會有滑動卡頓的危險。如果圖片已經存在於本機快取當中，用於收尾工作的代碼塊會在下一次運行周期執行，並且使用者不會注意到兩者之間的差別。他們會注意到的是滑動不會卡頓了。

現在，不需要你快速執行

如果使用者很快的滑動表格到底部，幾十或幾百個表格單元會出現在螢幕上，並向fastQueue請求圖片資料，然後很快地從螢幕上消失。突然間這個並行地隊列會將大量實際上不再需要的圖片請求充斥進網路。當使用者最終停止滑動時，那些當前螢幕上相應的表格單元視圖會將它們的圖片請求至於那些並不急需的請求後面，因此網路阻塞了。
這就是 wheremoveTaskToSlowQueueForURL:這個方法的產生的原因.

複製代碼 代碼如下:

// a table cell is going off screen-
(void)tableView:(UITableView *)table       
didEndDisplayingCell:(UITableViewCell *)cell       
forRowAtIndexPath:(NSIndexPath*)indexPath {   
     // we don't need it right now, so move it to the slow queue            
     [SGImageCache moveTaskToSlowQueueForURL:[[(id)cell event] imageURL]];
}

這確保在fastQueue中的只會有真正需要被快速執行的任務。任何以前認為需要快速執行但現在不需要的任務會被移至slowQueue中。

重點和選擇

已經有相當多的iOS圖片緩衝庫。它們中一些庫只針對某些應用情境，一些庫提供了不同情境一定的可擴充性。我們的庫即沒有專門針對某些應用情境，也沒有太多大而全的特性。針對我們的使用者我們有三類基本的重點：
重點 1: 最好的幀率
很多的庫都非常專註在這一點上，使用一些高度定製和複雜的方法，儘管基準沒有決定性地顯示這樣有效。我們發現最好的幀率由這些決定：
將對磁碟的訪問（並且幾乎其它的所有）脫離主線程。
使用UIImage的記憶體緩衝來避免不必要的磁碟訪問和圖片解壓。

重點 2: 讓最最重要的圖片優先顯示
大多數的庫都考慮讓隊列管理成為別人關心的事。對於我們的應用，這幾乎是最重要的點。
讓正確的圖片在正確的時間顯示在螢幕上可以歸結為一個簡單的問題：“我們現在就需要它顯示還是過一會兒？”。那些需要立即顯示的圖片是並行載入地，而其它所有東西都被添加到串列隊列中。所有之前急迫的事但現在不急迫的話就會從fastQueue分到slowQueue中。並且當fastQueue在工作時，slowQueue是處於掛起狀態的。
這讓那些急需顯示的圖片可以單獨訪問網路，同時也確保了一張非急需顯示的圖片可以在過一會成為一張急需顯示的圖片，因為它已經存到了緩衝當中，隨時準備用於顯示。

重點 3: 儘可能簡單的API
大多數庫都做到了這一點。許多庫為了隱藏細節內容而提供了UIImageView的分類，並且許多庫讓抓取一張圖片的流程變得儘可能的便利。針對我們經常做的三件事，我們的庫選定了三個主要的方法：
快速抓到一張圖

複製代碼 代碼如下:

__weak SGEventCell *me = self;[SGImageCache getImageForURL:event.imageURL thenDo:^(UIImage *image) {    me.imageView.image = image;}];

排隊等待一張我們一會才需要的圖片

複製代碼 代碼如下:

[SGImageCache slowGetImageForURL:event.imageURL thenDo:nil];

通知緩衝一張急需顯示的圖已經不需要立刻顯示

複製代碼 代碼如下:

[SGImageCache moveTaskToSlowQueueForURL:event.imageURL];

結論

通過專註於預取，隊列管理，從主線程移除耗時的任務，並且依賴於UIImage內建的記憶體緩衝，我們努力從一個簡單的軟體包中得到好的結果。