iOS 各種快取機制的簡單介紹
AppCache類把判斷資料是否過期的邏輯從檢視控制器中抽象出來了,還把快取儲存的位置也抽象出來了。稍後在本章中我們還會修改AppCache,再引入一層快取,內容會儲存在記憶體中。
因為AppCache抽象出了快取的儲存位置,我們就不需要為複製貼上程式碼來獲得應用的快取目錄而操心了。如果應用類似於iHotelApp,開發者可通過為每個使用者建立子目錄即可輕鬆增強快取資料的安全性。然後我們就可以修改AppCache中的輔助方法,現在它返回的是快取目錄,我們可以讓它返回當前登入使用者的子目錄。這樣,一個使用者快取的資料就不會被隨後登入的使用者看到了。
完整的程式碼可以從本書網站上本章的原始碼下載中獲取。
快取版本控制:
我們在上一節中寫的AppCache類從檢視控制器中抽象出了按需快取。當檢視出現和消失時,快取就在幕後工作。然而,當你更新應用時,模型類可能會發生變化,這意味著之前歸檔的任何資料將不能恢復到新的模型上。正如之前所講,對按需快取來說,資料並沒有那麼重要,開發者可以刪除資料並更新應用。我會展示可以用來在版本升級時刪除快取目錄的程式碼片段。
第二個是驗證模型,伺服器通常會發送一個校驗和(Etag)。後續所有從快取獲得資源的請求都應該用這個校驗和向伺服器**重新驗證**資源是否有變化。如果校驗和匹配,伺服器就返回一個HTTP 304 Not Modified的狀態碼。
IOS記憶體快取:
目前為止,所有iOS裝置都帶有快閃記憶體,而快閃記憶體有點小問題:它的讀寫壽命是有限的。儘管這個壽命跟裝置的使用壽命比起來很長,但是仍然需要避免過於頻繁地讀寫快閃記憶體。在上一個例子中,檢視隱藏時是直接快取到磁碟的,而檢視顯示時又是直接從磁碟讀取的。這種行為會使使用者裝置的快取負擔很重。為避免這個問題,我們可以再引入一層快取,利用裝置的RAM而不是快閃記憶體(用NSMutableDictionary)。在24.2.1節的“實現資料模型快取”中,我們介紹了建立歸檔的兩種方法:一個是儲存到檔案,另一個是儲存為NSData物件。這次會用到第二個方法,我們會得到一個NSData指標,將該指標儲存到NSMutableDictionary中,而不是檔案系統裡的平面檔案。引入記憶體快取的另一個好處是,在歸檔和反歸檔內容時效能會略有提升。聽起來很複雜,實際上並不複雜。本節將介紹如何給AppCache類新增一層透明的、位於記憶體中的快取。(“透明”是指呼叫程式碼,即檢視控制器,甚至不知道這層快取的存在,而且也不需要改動任何程式碼。)我們還會設計一個LRU(Least Recently Used,最近最少使用)演算法來把快取的資料儲存到磁碟。
以下簡單列出了要建立記憶體快取需要的步驟。這些步驟將會在下面幾節中詳細解釋。
- 新增變數來存放記憶體快取資料。
- 限制記憶體快取大小,並且把最近最少使用的項寫入檔案,然後從記憶體快取中刪除。RAM是有限的,達到使用極限就會觸發記憶體警告。收到警告時不釋放記憶體會使應用崩潰。我們當然不希望發生這種事,所以要為記憶體快取設定一個最大閾值。當快取滿了以後再新增任何東西時,最近最少使用的物件應該被儲存到檔案(快閃記憶體中)。
- 處理記憶體警告,並把記憶體快取以檔案形式寫入快閃記憶體。
- 當應用關閉、退出,或進入後臺時,把記憶體快取全部以檔案形式寫入快閃記憶體。