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.

你可能感兴趣的:(SDWebImage源码解析(二))