iOS NSCache 緩存策略

1.概念：NSCache緩存策略中主要使用的是_GSCachedObject類，下圖是_GSCachedObject的源碼，定義中重點(diǎn)的分別是緩存的訪問次數(shù)，緩存當(dāng)前消耗的大小，是否能夠被清除的標(biāo)記

創(chuàng)新互聯(lián)公司從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元泰安做網(wǎng)站,已為上家服務(wù),為泰安各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

2.核心緩存策略源碼

- (void)_evictObjectsToMakeSpaceForObjectWithCost: (NSUInteger)cost

{

/** 計(jì)算需要清除的空間 */

NSUInteger spaceNeeded = 0;

/** 緩存數(shù)量 */

NSUInteger count = [_objects count];

if (_costLimit 0 _totalCost + cost _costLimit)

{

/** spaceNeeded：計(jì)算需要清除的空間 = _totalCost：總的消耗內(nèi)存大小+已有的 -_costLimit：限制消耗大小 */

? spaceNeeded = _totalCost + cost - _costLimit;

}

// Only evict if we need the space.

if (count 0 (spaceNeeded 0 || count = _countLimit))

{

? NSMutableArray *evictedKeys = nil;

? // Round up slightly.

? ? /**

? ? ? ? averageAccesses：平均訪問次數(shù)

? ? ? ? _totalAccesses：所有訪問次數(shù)的總和

? ? ? ? count：內(nèi)存中的緩存對象

? ? 幾乎淘汰一半的緩存，所以乘0.2

? ? (_totalAccesses / (double)count) * 0.2)可能為0，所以+1

? ? */

? NSUInteger averageAccesses = ((_totalAccesses / (double)count) * 0.2) + 1;

? NSEnumerator *e = [_accesses objectEnumerator];

? _GSCachedObject *obj;

if (_evictsObjectsWithDiscardedContent)

{

evictedKeys = [[NSMutableArray alloc] init];

}

? while (nil != (obj = [e nextObject]))

{

// Don't evict frequently accessed objects.

? ? /** 當(dāng)前的訪問次數(shù) 是否小于平均的訪問次數(shù) 且 當(dāng)前對象可移除 */

if (obj-accessCount averageAccesses obj-isEvictable)

{

? ? ? ? /** 發(fā)送通知，釋放內(nèi)存 */

? [obj-object discardContentIfPossible];

? if ([obj-object isContentDiscarded])

{

NSUInteger cost = obj-cost;

// Evicted objects have no cost.

obj-cost = 0;

// Don't try evicting this again in future; it's gone already.

obj-isEvictable = NO;

// Remove this object as well as its contents if required

if (_evictsObjectsWithDiscardedContent)

{

? [evictedKeys addObject: obj-key];

}

_totalCost -= cost;

// If we've freed enough space, give up

? ? ? ? /** 消耗的 需要清除的空間 */

if (cost spaceNeeded)

{

? break;

}

spaceNeeded -= cost;

}

}

}

? // Evict all of the objects whose content we have discarded if required

? if (_evictsObjectsWithDiscardedContent)

{

NSString *key;

e = [evictedKeys objectEnumerator];

while (nil != (key = [e nextObject]))

{

? [self removeObjectForKey: key];

}

}

[evictedKeys release];

}

}

2.淘汰策略：在while循環(huán)中通過比對cost spaceNeeded來進(jìn)行緩存對象obj的移除

open func setObject(_ obj: ObjectType, forKey key: KeyType, cost g: Int) {

? ? let g = max(g, 0)

? ? let keyRef = NSCacheKey(key)

? ? /** 加鎖 */

? ? _lock.lock()

? let costDiff: Int

? ? /** 查找緩存列表中是否有key對應(yīng)的緩存對象，有的話替換 */

? /**

? _entries：

? ? ? ? key：NSCacheKey

? ? ? ? value：NSCacheEntry

? ? */

? if let entry = _entries[keyRef] {

? ? ? ? costDiff = g - entry.cost

? ? ? ? entry.cost = g

? ? ? entry.value = obj

? ? ? if costDiff != 0 {

? ? ? ? ? ? /** 移除舊的緩存 */

? ? ? ? ? ? remove(entry)

? ? ? ? ? ? /** 添加新的緩存 */

? ? ? ? ? ? insert(entry)

? ? ? ? }

? ? } else {

? ? ? ? let entry = NSCacheEntry(key: key, value: obj, cost: g)

? ? ? ? _entries[keyRef] = entry

? ? ? ? insert(entry)

? ? ? costDiff = g

? ? }

? _totalCost += costDiff

? ? /** totalCostLimit:所有消耗大小限制 ，_totalCost：當(dāng)前消耗，*/

? ? var purgeAmount = (totalCostLimit 0) ? (_totalCost - totalCostLimit) : 0

? ? while purgeAmount 0 {

? ? ? ? /** head：鏈表頭結(jié)點(diǎn) */

? ? ? ? if let entry = _head {

? ? ? ? ? ? /** 回調(diào)函數(shù) */

? ? ? ? ? ? delegate?.cache(unsafeDowncast(self, to:NSCacheAnyObject, AnyObject.self), willEvictObject: entry.value)

? ? ? ? ? _totalCost -= entry.cost

? ? ? ? ? ? purgeAmount -= entry.cost

? ? ? ? ? ? /** 移除緩存對象 */

? ? ? ? ? ? remove(entry) // _head will be changed to next entry in remove(_:)

? ? ? ? ? ? /** 表中entry對應(yīng)的key也置為nil */

? ? ? ? ? ? _entries[NSCacheKey(entry.key)] = nil

? ? ? ? } else {

? ? ? ? ? ? break

? ? ? ? }

? ? }

? ? /** countLimit：緩存數(shù)量限制，_entries.count：當(dāng)前緩存對象的數(shù)量 */

? ? var purgeCount = (countLimit 0) ? (_entries.count - countLimit) : 0

? ? while purgeCount 0 {

? ? ? ? /** head：鏈表頭結(jié)點(diǎn) */

? ? ? ? if let entry = _head {

? ? ? ? ? ? /** 回調(diào)函數(shù) */

? ? ? ? ? ? delegate?.cache(unsafeDowncast(self, to:NSCacheAnyObject, AnyObject.self), willEvictObject: entry.value)

? ? ? ? ? _totalCost -= entry.cost

? ? ? ? ? ? /** 每移除一次，緩存數(shù)量 - 1 */

? ? ? ? ? ? purgeCount -= 1

? ? ? ? ? ? /** 移除緩存對象 */

? ? ? ? ? ? remove(entry) // _head will be changed to next entry in remove(_:)

? ? ? ? ? ? /** 表中entry對應(yīng)的key也置為nil */

? ? ? ? ? ? _entries[NSCacheKey(entry.key)] = nil

? ? ? ? } else {

? ? ? ? ? ? break

? ? ? ? }

? ? }

? ? /** 解鎖 */

? ? _lock.unlock()

}

通過insert函數(shù)可以看出，通過cost排序，在外部會優(yōu)先刪除占用內(nèi)存小的緩存對象

swift緩存策略：

1.通過totalCostLimit所有的消耗大小限制和當(dāng)前總消耗大小做比對，大于零進(jìn)行while循環(huán)移除entry緩存對象

2.通過countLimit緩存數(shù)量限制和當(dāng)前緩存對象的數(shù)量大小做差值，大于零進(jìn)行while循環(huán)移除entry緩存對象

iOS web緩存策略以及手動清除緩存

當(dāng)我們使用webview加載html資源時(shí)，本質(zhì)上就是向服務(wù)器索取資源的http請求過程，如果我們不注意資源的緩存策略的話，就可能會造成這樣那樣的問題，比如：實(shí)時(shí)性要求較高的功能卻老是走緩存不更新，有些基本不會變動的頁面卻又每次都重新去服務(wù)器拉請求。

iOS自帶的緩存策略，提供了一個(gè)內(nèi)存和磁盤混合的緩存，一共有7種緩存策略，使用較多的是其中的四種（ 下方編號1，2，5，6 ）

上面介紹了iOS自帶的緩存控制 NSURLRequestCachePolicy ，也說到當(dāng) NSURLRequestCachePolicy 設(shè)為默認(rèn)的 NSURLRequestUseProtocolCachePolicy 時(shí)，主要是根據(jù)http的緩存策略來決定是否使用緩存。

那么就簡單的介紹一下，http的緩存控制和緩存校驗(yàn)。

在http中，控制緩存開關(guān)的字段有兩個(gè)，Pragma和Cache-Control

Pragma有兩個(gè)字段no-cache和expires，當(dāng)pragma為no-cache時(shí)表示禁用緩存，expires的值是一個(gè)GMT時(shí)間，表示該緩存的有效時(shí)間。但是已經(jīng)被逐步拋棄了，有些網(wǎng)站為了向下兼容還保留了這兩個(gè)字段。

Cache-Control除了在響應(yīng)中使用，在請求中也可以使用。

在請求中使用，Cache-Control可選的值有：

在響應(yīng)中使用，Cache-Control可選的值有：

在緩存中，我們需要一個(gè)機(jī)制來驗(yàn)證緩存是否有效。比如服務(wù)器的資源更新了，客戶端需要及時(shí)刷新緩存；又或者客戶端的資源過了有效期，但服務(wù)器上的資源還是舊的，此時(shí)不需要重新發(fā)送。緩存校驗(yàn)就是用來解決這些問題的，在http1.1中，主要關(guān)注下 Last-Modified 和 etag 這兩個(gè)字段。

服務(wù)端在返回資源時(shí)，會將該資源的最后更改時(shí)間通過 Last-Modified 字段返回給客戶端。客戶端下次請求時(shí)通過 If-Modified-Since 或者 If-UnModified-Since 帶上 Last-Modified ，服務(wù)端檢查該時(shí)間是否與服務(wù)器的最后修改時(shí)間一致：如果一致，則返回304狀態(tài)碼，不反悔資源；如果不一致，則返回200和修改后的資源，并帶上新的時(shí)間。

單純的以修改時(shí)間來判斷還是有缺陷，比如文件的最后修改時(shí)間變了，但內(nèi)容沒變。對于這樣的情況，我們可以使用etag來處理。

etag的方式是這樣：服務(wù)器通過某個(gè)算法對資源進(jìn)行計(jì)算，取得一串值(類似于文件的md5值)，之后將該值通過etag返回給客戶端，客戶端下次請求時(shí)通過If-None-Match或If-Match帶上該值，服務(wù)器對該值進(jìn)行對比校驗(yàn)：如果一致則不要返回資源。

當(dāng)我們的webview緩存到一定的峰值的時(shí)候，需要手動的清除一下wenview的緩存，方法如下：

找出web緩存的路徑，清空該路徑

webKit除了清除緩存的API

覺得有用，請幫忙點(diǎn)亮紅心

Better Late Than Never!

努力是為了當(dāng)機(jī)會來臨時(shí)不會錯(cuò)失機(jī)會。

共勉！

ios中關(guān)于方法緩存cache策略

文章部分出于自己的理解，有不對的地方，希望大家指正。

實(shí)例對象我們可以看作是一個(gè)指針，實(shí)例對象通過isa指針指向類對象，類對象通過isa指針指向元類對象，類對象和元類對象本身其實(shí)都是objc_class結(jié)構(gòu)體，里面存放著我們需要的方法列表等。

那么當(dāng)我們方法調(diào)用的時(shí)候，方法是如何緩存的呢?

當(dāng)我們方法調(diào)用的時(shí)候，首先通過isa指針找到類對象，然后在類對象的方法列表里面查找相對應(yīng)的方法，找到以后會加入到我們方法緩存里面，等下次我們再調(diào)用的時(shí)候，首先會先從緩存里面去查找相關(guān)方法，更加的效率。

那如果我們調(diào)用的是父類里面的方法呢，其實(shí)父類對象里面的方法是不可以緩存到子類方法緩存列表里面的，所以，當(dāng)我們調(diào)用的是父類對象里面的方法的時(shí)候，其方法不會在子類對象方法緩存列表里面進(jìn)行緩存。

元類對象的相關(guān)緩存同類對象。

至于緩存擴(kuò)容和具體的緩存策略：

在arm64結(jié)構(gòu)，也就是真機(jī)環(huán)境下，剛開始初始化的緩存方法的容器的長度2，當(dāng)容器的長度小于8時(shí)，是滿容量了才擴(kuò)容。當(dāng)容器的長度大于8時(shí)，是7/8擴(kuò)容。也就是說當(dāng)容器的長度為8時(shí)，容器可以存儲8個(gè)方法。當(dāng)容器的長度為16時(shí)，當(dāng)?shù)?5個(gè)方法需要存儲進(jìn)來的時(shí)候，容器就要擴(kuò)容了。

在x86_64架構(gòu)下，剛開始初始化的容器的長度為4，是3/4擴(kuò)容。這里的3/4擴(kuò)容指的是：如果容器的長度為4，當(dāng)?shù)?個(gè)數(shù)據(jù)需要存儲的時(shí)候，就要擴(kuò)容了。如果容器的長度為8，當(dāng)?shù)?個(gè)數(shù)據(jù)需要存儲的時(shí)候，就要擴(kuò)容了。也就是說容器只能存儲容器長度的3/4減1個(gè)方法。

還有一點(diǎn)就是：當(dāng)容器擴(kuò)容之后，前面存儲的方法也會隨之清空。

參考鏈接：

iOS面試題：簡單的描述一下 SDWebImage的緩存策略？

首先， SDWebImage 的圖片緩存采用的是 Memory (內(nèi)存) 和 Disk (硬盤) 雙重 Cache 機(jī)制， SDImageCache 中有一個(gè)叫做 memCache 的屬性，它是一個(gè) NSCache 對象，用于實(shí)現(xiàn)我們對圖片的 Memory Cache ，其實(shí)就是接受系統(tǒng)的內(nèi)存警告通知，然后清除掉自身的圖片緩存。 Disk Cache ，也就是文件緩存， SDWebImage 會將圖片存放到 NSCachesDirectory 目錄中，然后為每一個(gè)緩存文件生成一個(gè) md5 文件名, 存放到文件中。 整體機(jī)制如下：

原文地址

標(biāo)題名稱：ios開發(fā)緩存策略,ios緩存機(jī)制
本文鏈接：http://chinadenli.net/article28/dsggojp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、網(wǎng)站建設(shè)、定制開發(fā)、小程序開發(fā)、網(wǎng)站維護(hù)、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)