之前經常有人說：簡單的應用不需要內存優化，就幾個模塊能占用多大內存？對這種說法我并不認同，雖然我也沒開發過什么大型的應用，但我覺得內存優化是開發一個APP必不可少的流程，甚至說非常重要的一個環節，不論你的應用簡單還是復雜。這篇文章說一下我對ScrollView內存優化的方案。

在開發APP的過程中，很多時候都會用到ScrollView，我要說的是ScrollView優化類似于網易新聞首頁那種ScrollView。很顯然，這種ScrollView橫向的ContentSize非常龐大，假如不去優化這些加在ScrollView上的View，那么你每次加載視圖的時候內存都會不停地往上升，且無法降低。那么我們如何去優化或者說我們基于什么思想去優化這種情況呢？

<中間有一點需要說明：創建一個VC在內存中，如果不加載它的view它所占的內存遠遠小于加載view占用的內存>

我們可以這樣想：一個ScrollView的ContentSize再大，展示給用戶的始終只是一個屏幕的大小，其它位置的用戶根本看不到，那么，這些看不到的就造成了內存的浪費。說到這里，你可能就有感覺了，我們只需要給用戶展示當前屏幕區域的視圖，而其他位置的視圖根本不需要加載。但是這樣還不完美，我們要做的是一個完善的ScrollView滑動體驗，我覺得要做成下面三步：

1.只展示當前屏幕顯示的區域，盡可能地優化內存；

2.滑動時即將呈現的頁面如果加載過了，在滑動的過程中就要加載出來；

3.滑動時即將呈現的頁面如果還沒加載過，在滑動結束后（整頁滑動）加載出來；<注：這里選擇了滑動結束后再加載，沒有和2合為一起是考慮到如果剛滑動就加載龐大的數據會造成頁面卡頓>

找到了關鍵點，我們就可以進行下一步操作。如何進行操作呢？自然是從ScrollView的代理入手。

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView;

這個方法配合PageEnd，在ScrollView整頁滑動結束后觸發，正好解決了第三步。假設我們還沒加載頁面，這個時候通過這個方法就可以加載這個頁面，并且可以把當前沒有在顯示區域的頁面的VC從父VC中remove掉，并把它的view也remove掉。remove掉之前我們要做一件事情，就是把它當做緩存放入到我們的容器中，以便于我們下次取得時候可以直接取出，不用再次加載。

這個容器如何選擇呢？我一開始選擇了NSCache，系統自帶的緩存類，有一些屬性和內部已經實現好的緩存機制，不需要開發者自己動手清理，覺得挺好用。但是這里有個很大的坑。。。NSCahce內的緩存在你點Home鍵應用進入后臺后會自動清理掉！！！我對這點非常不爽。。。然后自己按照NSCache的方式利用NSDictionary模仿了一個緩存，不讓它自動清除。

當然。。。對這點不在意的同學可以用NSCache，還是非常好用的一個類。

- (void)scrollViewDidScroll:(UIScrollView *)scrollView;

這個方法在API中有這么一段注釋：any offset changes

說明offset的改變立即會觸發這個方法。這對于第2步來說非常好。我們可以在這一步從我們的緩存中添加視圖。如果緩存中有這個視圖，那么我們可以拿出來加載到視圖上，如果沒有，那么回到了第3步，讓它去加載。

做完這兩步就剩下第1步：只加載當前屏幕區域的視圖的視圖了，對于如何判斷加載的這個view在當前屏幕的可視區域，我用的方法是可以在一開始就創建個數組，把這些frame記錄下來，代理方法觸發的時候進行一次比對。這個比對非常簡單，對于頁面的流暢性可以忽略不計。

至此，主要的部分就說完了，還有一些細節比如刷新時更新緩存中對應的VC之類的。。。有心的同學可以自己想想思路實現下這里就不提了。

如果有更好的優化方案歡迎提及，共同學習。

個人原創，轉載請注明出處，謝謝