你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發綜合 >> IOS Cache設計詳細介紹及簡單示例

IOS Cache設計詳細介紹及簡單示例

編輯:IOS開發綜合

IOS Cache設計

Cache的設計是個基礎計算機理論,也是程序員的重要基本功之一。Cache幾乎無處不在,CPU的L1 L2 Cache,iOS系統的clean page和dirty page機制,HTTP的tag機制等,這些背後都是Cache設計思想的應用。

為什麼需要Cache

Cache的目的是為了追求更高的速度體驗,Cache的源頭是兩種數據讀取方式在成本和性能上的差異。

在開始著手設計Cache之前,需要先理清數據存儲的媒介。作為客戶端開發人員來說,我們所關注的數據存儲方式也有不少種:

  • 數據最開始是存儲在Server上,這些數據需要通過網絡請求獲取。
  • 從Server獲取數據時,會經過各種中間網絡節點(比如代理),這些節點有時會緩存我們的數據。
  • 把數據下載到本地之後,我們會在本地disk緩存一份,這樣或許不用每次都重新去服務器請求。
  • 存到disk之後,數據的存儲方式會影響到讀取的速度,以B+ Tree存儲的sqlite就比直接序列化NSArray到文件之中要快不少。
  • App啟動時,系統會將從Server下載到的數據,從disk加載到memory,memory的讀寫性能比disk要快很多。
  • 到了Memory中,不同的數據結構存儲方式也會存在速度上的差異。用NSDictionary(hash表)形式存儲讀數據,寫性能都比Array好,但space開銷更大。雖說memory的讀寫性能比disk都高了很多,但在大集合類數據操作的時候有時也會遇到瓶頸。
  • 比Memory更快的還有Register,L1,L2,只不過對於iOS App開發來說,很少深入到這一層面的優化。

上面所說的每一個環節,都存在性能和成本上的差別,Server的數據自然是最及時最准確的,但一個App要以NSArray的形式獲取到Server的數據,中間要經過「漫長」的過程,可以說每一步中都存在cache的設計思想。

對於Cache的理解和實踐,前提是我們對於存儲媒介,和不同數據結構差異,有比較深入的掌握。

我們大部分App的性能優化,如果涉及到Cache,一般都是在Memory這一媒介上做處理。將需要從Disk中,或者通過CPU復雜計算才能獲取的數據,通過合理的數據結構存儲在Memory中,就能解決我們App開發裡,絕大部分的Cache需求了。這一層面的Cache設計也有著不同的姿勢,先來看看簡單可用型。

簡單可用型Cache

得益於Foundation中NSDictionary的封裝,我們可以用hash表這種數據結構來實現一個簡單可用的cache機制,先來看一個實例:

- (NSString*)getFormmatedPhoneNumber:(NSNumber*)phone
{
 if(phone == nil)
 {
  return nil;  
 }
 
 return [PhoneFormatLib formatPhoneNumber:phone]; //CPU費時操作
}

這是個簡單的格式化手機號碼的函數,其中 formatPhoneNumber 函數是個CPU Intensive的調用,而且在業務場景中針對同一個手機號碼,需要經常性的獲取格式化之後的NSString,如果每次都重復計算顯然是對CPU資源的浪費,而且性能也不好。我們可以加個簡單的Cache來優化:

static NSMutableDictionary* gPhoneCache = nil;
- (NSString*)getFormmatedPhoneNumber:(NSNumber*)phone
{
  if(phone == nil)
  {
    return nil;
  }
  
  NSString* phoneNumberStr = nil;
  
  [_phoneLock lock];
  if(gPhoneCache == nil)
  {
    gPhoneCache = @{}.mutableCopy;
  }
  
  phoneNumberStr = [gPhoneCache objectForKey:phone];
  if (phoneNumberStr == nil) {
    phoneNumberStr = [PhoneFormatLib formatPhoneNumber:phone];
    [gPhoneCache setObject:phoneNumberStr forKey:phone];
  }
  [_phoneLock unlock];
  
  return phoneNumberStr; 
}

通過引入NSMutableDictionary,就避免了每次都需要重復調用 formatPhoneNumber 的問題,so easy就完成了一個快速的cache設計,馬上就可以提交給測試,把優化成果甩產品經理臉上,這歸功於hash表O(1)的時間復雜度。內存空間會多消耗一些,不過對於小量的數據影響比較小,現代的hash表不會一開始就分配大量的空間,而是隨著數據的增加而逐漸擴容。

這種簡單可用型的Cache設計,最大的問題在於,代碼過於零散且不可控。小量且分散的cache設計幾乎等同於挖坑,在你設計cache的時候可能數據量還小,但後面維護的時候,業務改變的時候,誰也不能保證這塊內存的開銷依然可以忽略不計。而且這種內存方面的損耗很難察覺,巧妙的隱蔽在某個.m文件中,到後期想控制整個App的內存開銷時,會感覺到處都有坑,無從下手。你可能也發現了,上面這段Cache代碼沒有釋放Cache的地方。

所有對我們整個App有副作用的代碼都需要被集中管理,要能從架構的層面去理解和定位。怎麼去定義副作用呢?可以抽象成一種「寫操作」,往Cache中添加新的記錄就是寫操作,這種寫操作的副作用是額外的內存開銷,Cache的本質是以空間換時間,這空間損耗就是我們的副作用,一個副作用會引發其他更多的副作用,理清這些副作用往往需要反復查閱大量的代碼。更好的辦法是,一開始就把有副作用的代碼集中管理。

優雅可控型Cache

避免Cache代碼散亂放置的做法是,設計一個優雅可控的Cache模塊。一個App中,可能會有各種各樣的數據需要Cache,phoneNumberCache,avatarCache,spaceshipCache等等,我們需要有個源頭來追蹤這些cache,直觀的做法是通過工廠類來生成和持有這些各式各樣的cache:

//CacheFactory.h
@interface CacheFactory : NSObject
+ (instancetype)sharedInstance;
- (id<MyCacheProtocol>)getPhoneNumberCache;
- (void)clearPhoneNumberCache;
- (id<MyCacheProtocol>)getAvatarCache;
- (void)clearAvatarCache;
@end

這樣當我們需要評估各種Cache對整個App內存開銷的影響之時,只需要從CacheFactory代碼著手即可,調試起來也有跡可循,其他工程師接手你的代碼也會感激涕零的。

通過protocol的方式,將cache的聲明和實現想分離,這也是個好習慣。cache的另一個重要知識點是cache的淘汰策略,不同的策略表現也不一樣,FIFO,LRU,2Queues等等,現在有不少成熟的第三方cache框架可以使用,系統也提供了淘汰策略不明確的NSCache,如果沒有動手寫過任何cache淘汰策略,我還是建議大家自己動手試著做一個,至少要讀一下相關的實現源碼,了解這些淘汰策略很有必要,在做一些深度優化的時候需要因地制宜來做決定。

cache的使用要有收有放,不能只創建不釋放,事實上,所有涉及到data的操作都要考慮data的生命周期。我們做業務的時候,多是以Controller為基礎單位,有些場景下,一個Controller在退出之後被再次進入的可能性就非常之低了,適時的清理cache會讓我們App的整體表現更好。

Immutable Cache

Cache中存放的是啥?是Data。說到Data,就不得不提peak君最愛啰嗦的”Immutability(不可變性)”了,Immutability和我們代碼的穩定性有著極大的關系,大到就像「房間裡的大象」,很重要也容易被忽視。

在實踐Immutability的時候,需要先將Data做分類,再去區分每一種類型Data如何去實施不可變性。做Data分類最重要的是分清楚值類型和引用類型的差別。傳值的時候傳遞的是新的內存拷貝,所以值類型大多是安全的,傳指針的時候傳遞的是同一塊共享內存空間,這也是指針之所以危險的一大原因。bool,Int,long等等這些primitive type都是值類型,可以放心的傳遞,而對象類型往往是以指針的形式在傳遞,需要特別的注意,我們一般通過copy的方式(生成新的內存拷貝)來傳遞。這也是為什麼Swift中將很多原先在Objective C中基礎類變為值類型的原因,強化Immutability,讓我們的代碼更加安全。

我們看下不同類型的數據在Cache中的讀寫操作。

值類型-讀

值類型可以安心返回:

- (int)spaceshipCount
{
  //...
  return _shipCount;
}

值類型-寫

值類型也可以安全的寫:

- (void)setSpaceshipCount:(int)count
{
  _shipCount = count;
}

對象類型-讀

指針類型需要生成新拷貝:

- (User*)luckyUser
{
  //...
 return [_luckyUser copy];  
}

對象類的copy方法需要我們手動實現NSCopying protocol,開發的初期雖然顯得繁瑣了些,但後期的回報很大。而且這裡的copy必須是deep copy,User中的每一個被持有的property都需要遞歸copy。

對象類型-寫

對象類型寫操作的危險之處在於函數的入參,入參也是對象類型的話,傳入的是一個共享的引用:

- (void)setLuckyUser:(User*)user
{
  //...
  _luckyUser = [user copy]; 
}

集合類型-讀

集合類也需要copy,是bug和crash的重災區:

- (NSArray*)hotDishes
{
 //...
  return [_hotDishes copy];
}

集合類型-寫

- (void)setHotDishes:(NSArray*)dishes
{
 //...
 _hotDishes = [dished copy];
}

看到這裡,大家可能也發現了,其實原則也比較簡單,只要保證業務模塊從Cache中獲取的數據都是獨立的copy,就能避免數據共享帶來的各種隱患。Cache模塊有點類似函數式編程中的純函數,既不依賴於外部的狀態,也不會修改外部的狀態,重點處理每一個函數調用的input(入參)和output(返回值)即可。

多線程安全

Cache多線程安全的重點在於對集合類的處理,Cache本身多數時候都是在管理數據的集合。需要特別注意的是NSString其實也應該歸到集合類,從數據讀寫和多線程安全方面看,NSString和NSArray在很多方面表現都是一致的。一些成熟的第三方Cache庫已經替我們處理好了多線程安全的問題,如果是自己造的輪子,尤其要注意保證讀寫都是原子操作,至於如何使用鎖,相關的文章分享已經很多了,此處不做贅述了。

總結

了解Cache關鍵在於明白其背後的設計思想,進而能對我們App的行為有更全面的掌握,能明白每一個業務流程背後對數據處理的瓶頸在哪。隨著代碼越寫越多,業務越來越復雜,今天或明天,我們總要遇到需要應用Cache設計的時候。

 感謝閱讀,希望能幫助到大家,謝謝大家對本站的支持!

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved