---

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設計的時分。

 感激閱讀，希望能協助到大家，謝謝大家對本站的支持！

【IOS Cache設計詳細引見及復雜示例】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！