YYCache 设计思路

标签: iOS 技术 | 发表时间:2015-10-25 16:06 | 作者:ibireme
出处:http://blog.ibireme.com

cache_all_the_things

iOS 开发中总会用到各种缓存,最初我是用的一些开源的缓存库,但到总觉得缺少某些功能,或某些 API 设计的不够好用。YYCache ( https://github.com/ibireme/YYCache) 是我新造的一个轮子,下面说一下这个轮子的设计思路。

内存缓存

通常一个缓存是由内存缓存和磁盘缓存组成,内存缓存提供容量小但高速的存取功能,磁盘缓存提供大容量但低速的持久化存储。相对于磁盘缓存来说,内存缓存的设计要更简单些,下面是我调查的一些常见的内存缓存。

NSCache 是苹果提供的一个简单的内存缓存,它有着和 NSDictionary 类似的 API,不同点是它是线程安全的,并且不会 retain key。我在测试时发现了它的几个特点:NSCache 底层并没有用 NSDictionary 等已有的类,而是直接调用了 libcache.dylib,其中线程安全是由 pthread_mutex 完成的。另外,它的性能和 key 的相似度有关,如果有大量相似的 key (比如 "1", "2", "3", ...),NSCache 的存取性能会下降得非常厉害,大量的时间被消耗在 CFStringEqual() 上,不知这是不是 NSCache 本身设计的缺陷。

TMMemoryCacheTMCache 的内存缓存实现,最初由 Tumblr 开发,但现在已经不再维护了。TMMemoryCache 实现有很多 NSCache 并没有提供的功能,比如数量限制、总容量限制、存活时间限制、内存警告或应用退到后台时清空缓存等。TMMemoryCache 在设计时,主要目标是线程安全,它把所有读写操作都放到了同一个 serial queue 中,然后用 dispatch_semaphore 来保证最多只有一个线程访问 queue。它错误的用了大量异步 block 回调来实现存取功能,以至于产生了很大的性能和死锁问题。

PINMemoryCache 是 Tumblr 宣布不在维护 TMCache 后,由 Pinterest 维护和改进的一个内存缓存。它的功能和接口基本和 TMMemoryCache 一样,但修复了性能和死锁的问题。它同样也用 dispatch_semaphore 来保证线程安全,但去掉了 serial queue,避免了线程切换带来的巨大开销,也避免了可能的死锁。

YYMemoryCache 是我开发的一个内存缓存,相对于 PINMemoryCache 来说,我去掉了异步访问的接口,尽量优化了同步访问的性能,用 OSSpinLock 来保证性能安全。另外,缓存内部用双向链表和 NSDictionary 实现了 LRU 淘汰算法,相对于上面几个算是一点进步吧。

下面的单线程的 Memory Cache 性能基准测试:

memory_cache_bench_result

可以看到 YYMemoryCache 的性能不错,仅次于 NSDictionary + OSSpinLock;
NSCache 的写入性能稍差,读取性能不错;
PINMemoryCache 的读写性能也还可以,但读取速度差于 NSCache;
TMMemoryCache 性能太差以至于图上都看不出来了。

磁盘缓存

为了设计一个比较好的磁盘缓存,我调查了大量的开源库,包括 TMDiskCache、PINDiskCache、SDWebImage、FastImageCache 等,也调查了一些闭源的实现,包括 NSURLCache、Facebook 的 FBDiskCache 等。他们的实现技术大致分为三类:基于文件读写、基于 mmap 文件内存映射、基于数据库。

TMDiskCache, PINDiskCache, SDWebImage 等缓存,都是基于文件系统的,即一个 Value 对应一个文件,通过文件读写来缓存数据。他们的实现都比较简单,性能也都相近,缺点也是同样的:不方便扩展、没有元数据、难以实现较好的淘汰算法、数据统计缓慢。

FastImageCache 采用的是 mmap 将文件映射到内存。用过 MongoDB 的人应该很熟悉 mmap 的缺陷:热数据的文件不要超过物理内存大小,不然 mmap 会导致内存交换严重降低性能;另外内存中的数据是定时 flush 到文件的,如果数据还未同步时程序挂掉,就会导致数据错误。抛开这些缺陷来说,mmap 性能非常高。

NSURLCache、FBDiskCache 都是基于 SQLite 数据库的。基于数据库的缓存可以很好的支持元数据、扩展方便、数据统计速度快,也很容易实现 LRU 或其他淘汰算法,唯一不确定的就是数据库读写的性能,为此我评测了一下 SQLite 在真机上的表现。iPhone 6 64G 下,SQLite 写入性能比直接写文件要高,但读取性能取决于数据大小:当单条数据小于 20K 时,数据越小 SQLite 读取性能越高;单条数据大于 20K 时,直接写为文件速度会更快一些。这和 SQLite 官网的描述基本一致。另外,直接从官网下载最新的 SQLite 源码编译,会比 iOS 系统自带的 sqlite3.dylib 性能要高很多。基于 SQLite 的这种表现,磁盘缓存最好是把 SQLite 和文件存储结合起来:key-value 元数据保存在 SQLite 中,而 value 数据则根据大小不同选择 SQLite 或文件存储。NSURLCache 选定的数据大小的阈值是 16K;FBDiskCache 则把所有 value 数据都保存成了文件。

我的 YYDiskCache 也是采用的 SQLite 配合文件的存储方式,在 iPhone 6 64G 上的性能基准测试结果见下图。在存取小数据 (NSNumber) 时,YYDiskCache 的性能远远高出基于文件存储的库;而较大数据的存取性能则比较接近了。但得益于 SQLite 存储的元数据,YYDiskCache 实现了 LRU 淘汰算法、更快的数据统计,更多的容量控制选项。

disk_cache_bench_result

备注:

关于锁:

OSSpinLock 自旋锁,性能最高的锁。原理很简单,就是一直 do while 忙等。它的缺点是当等待时会消耗大量 CPU 资源,所以它不适用于较长时间的任务。对于内存缓存的存取来说,它非常合适。

dispatch_semaphore 是信号量,但当信号总量设为 1 时也可以当作锁来。在没有等待情况出现时,它的性能比 pthread_mutex 还要高,但一旦有等待情况出现时,性能就会下降许多。相对于 OSSpinLock 来说,它的优势在于等待时不会消耗 CPU 资源。对磁盘缓存来说,它比较合适。

关于 Realm:

Realm 是一个比较新的数据库,号称是针对移动应用所设计。我在测试 SQLite 性能时,也尝试对它做了些简单的评测。我从 Realm 官网下载了它提供的 benchmark 项目,更新 SQLite 到官网最新的版本,并启用了 SQLite 的 sqlite3_stmt 缓存。评测结果显示 Realm 在写入性能上差 SQLite 很多,读取小数据时也差 SQLite 不少,只有读取较大数据时 Realm 才有很大的优势。我想看看它的实现原理,但发现 Realm 的核心 realm-core 是闭源的(还有迹象未来要收费),能知道的是 Realm 应该用 了 mmap 把文件映射到内存,所以才在较大数据读取时获得很高的性能。另外我注意到添加了 Realm 的 App 会在启动时向某几个 IP 发送数据,所以我强烈建议大家不要用 Realm。

相关 [yycache 设计] 推荐:

YYCache 设计思路

- - Garan no dou
iOS 开发中总会用到各种缓存,最初我是用的一些开源的缓存库,但到总觉得缺少某些功能,或某些 API 设计的不够好用. YYCache ( https://github.com/ibireme/YYCache) 是我新造的一个轮子,下面说一下这个轮子的设计思路. 通常一个缓存是由内存缓存和磁盘缓存组成,内存缓存提供容量小但高速的存取功能,磁盘缓存提供大容量但低速的持久化存储.

为了设计而设计

- - 幻风阁|kent.zhu'sBlog
我有个习惯,每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实,强调功能的实用性,后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎,各类App纷纷上演换装游戏,一个比一个做的精美,即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊,我说目前的移动产品设计可以分为2类,一类是做给用户用的,一类是做给设计师们欣赏与收藏的.

杯盖设计

- Yu - 创意设计-有趣、时尚、另类的创意
微向上的设计,在倒水完毕的时候可以让水滴顺着杯盖回流到杯子中,而不会随意的滴下来. 虽然是细小的设计,但是考虑的却是生活的便利.

再设计Redesign

- Mark - 腾讯CDC
  一个网站的核心是它的功能和内容,而设计则决定了这些功能、内容如何被组织和展现出来.   对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上,尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路,一是对现有问题挖掘然后改进,二是提出完全创新的想法.

简约设计

- - 淘宝网通用产品团队博客
写下这个标题,那么首先得要明确什么叫简约. 简约就是让用户操作简单,让用户更快的达到自己的目的. 一个产品在于解决一个需求,如何让用户最好的完成需求就成为一个产品经理首先得要解决的问题. 那么在日常工作中,我们又有什么可以做的呢. 在《简约至上》里面有四种策略,但是有的东西太高级了,在平时的工作未必能够用得上,所以我自己来提炼一下,看看日常工作中能够遇到并且可以解决问题的方法.

再设计Redesign

- 小趴 八足趴 八足 ramener - 互联网的那点事...
一个网站的核心是它的功能和内容,而设计则决定了这些功能、内容如何被组织和展现出来. 对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上,尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路,一是对现有问题挖掘然后改进,二是提出完全创新的想法.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

ODS设计

- - 开源软件 - ITeye博客
在一般的数据仓库应用系统中,根据系统体系结构的不同,数据仓库设计的内容和范围不尽相同,并且设计方法也不尽相同,下面的两幅图示分别表示带有ODS的 数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构. 本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同,并且重点介绍带有 ODS的体系结构中数据仓库的设计方法.

移动产品设计之设计

- crystal - 互联网的那点事
移动产品设计最大的差异点在于用户使用场景的变化,场景的变化引发了交互方式巨大的变化,从而也使得信息呈现方式有所不同,再加上硬件设备的差异,最终使得2者千差万别了. 所以,移动产品设计之设计应该首先从用户的使用场景出发,同时考虑用户的硬件设备差异,综合以上2点去帮助用户完成某个任务. 按照我的理解,场景、任务、用户可以称之为设计的三要素,每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的.