iOS SDWebImage源碼研究（二）

1.上一篇說到SDImageCache使用完整的URL來做爲磁盤緩存的key。可是有時候爲了訪問控制的目的，URL的部份內容會是動態的，這樣磁盤緩存就起不了做用。

對於這個問題，SDWebImageManager給出了一個解決辦法（也就是說單獨使用SDImageCache是沒有的，須要本身修改源碼）：設置一個cacheKeyFilter，以NSURL做爲輸入，輸出一個NSString做爲緩存key。

下面是SDWebImage GitHub主頁的示例代碼：

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    SDWebImageManager.sharedManager.cacheKeyFilter = ^(NSURL *url) {
        url = [[NSURL alloc] initWithScheme:url.scheme host:url.host path:url.path];
        return [url absoluteString];
    };

    // Your app init code...
    return YES;
}

2.今天去面試的時候被問到，關於cleanDiskWithCompletionBlock:中使用NSdirectoryEnumerator的性能問題。使用NSdirectoryEnumerator遍歷全部的緩存文件到底會不會形成性能問題，需不須要改進。

通過查詢stackoverflow，知道使用NSdirectoryEnumerator遍歷全部的緩存文件，獲取文件屬性，如咱們須要的文件大小信息，是不會有性能問題的。NSdirectoryEnumerator獲取文件屬性是經過查看文件的inode數據，並不須要想象中的fileopen和fileclose。

inode中所包含的、UNIX用戶常常使用的一些重要信息：

• inode編號
• 用來識別文件類型，以及用語stat C函數的模式信息
• 文件的連接樹木
• 屬主的UID
• 屬主的組ID（GID）
• 文件的大小
• 文件所使用的磁盤塊的實際數目
• 最近一次修改的時間
• 最近一次訪問的時間
• 最近一次更改的時間

3.關於爲什麼不在SDWebImage直接使用NSCache，而須要自定義它的子類AutoPurgeCache。

說明這個問題以前，先看看咱們使用NSCache的優勢。

NSCache的優勢：

• 自動刪減功能
• 線程安全
• 不會拷貝健

這就是爲什麼咱們選用相似於集合的NSCache，而不用NSDictionary本身實現緩存的考慮了。

可是，根據這個stackoverflow問題，NSCache在iOS7系統中不會響應內存告警，因此在SDWebImage中就子類化了NSCache，本身監聽內存告警，並removeAllObjects.