Cache 的发音是 [kæʃ]，但我还是觉得读成“卡车”比较有爱。
这次的主角是 NSCache。
缓存导致的问题
使用内存缓存的好处不言而喻，但无尽地消耗内存肯定有问题的。占用过多的内存以至于没有更多空闲内存供其他应用使用，页面置换频频发生对性能的影响是不小的。
NSCache 作为内存缓存
NSCache 和 NSMutableDictionary 非常相似，同样是存储键值对但 NSCache 不需要拷贝 key。文档说 NSCache是 “reactive cache”，当内存充裕时能缓存数据，内存不足时又能自动地丢弃一些数据，但就是没提到丢弃的规则是什么。
不过 NSCache 的提供两个方法去限制缓存：一个是 -setCountLimit:，设置缓存对象的最大数量，根据我的观察（存疑），在对象数量到达极限后加入新对象，需要被丢弃的对象按照 LRU（Least Recently Used）规则被丢弃掉。
另一个 -setTotalCostLimit: 设置缓存最大的开销。cache 在 -setObject:forKey:cost: 的时候，可以为每个缓存对象设置开销。当 cache 中所有对象的开销之和达到阈值时，cache 会丢弃数据让开销的总量回落阈值。开始我以为引入 cost 这个概念是为了在丢弃缓存的时候，优先把开销大的数据扔掉，在 cache 中尽量留着尽量多的数据，结果还是 LRU。
简言之，项目中用 NSMutableDictionary 对象做缓存的都换为 NSCache 会比较好好，毕竟能自动丢弃。
使用 Purgeable 内存
当应用申请一块内存时，倘若系统发现没用更多的空闲内存，那么需要将已用内存中的数据置换到磁盘上，这样就有了内存可供使用。但如果该内存被标记为 purgeable（可清除的），那么内存中的数据就会直接被丢弃。而这个机制是对于那些 “创建开销” 小于 "页面置换开销" 的对象是有益的。
类似于线程中的同步机制，purgeable 的内存访问也需要一套 locking mechanism，在这样的一个机制中有 counter 这样的概念，指示着对象的生命周期：
- 当 counter >= 1， 对象可以被使用；
- 当 counter == 0，对象的就可以丢弃。
NSPurgebleData 是一个遵循 NSDiscardabelContent 协议的类，作为使用 Purgeable 内存的实现，通过 begin/endContentAccess 控制 counter，需要注意以下几点：
-
-beginContentAccess让 counter++； -
-endContentAccess让 counter--； - 当 counter >= 1 时才能访问对象占用的内存；
- 只有在对象的 counter == 0 时，发送
-discardContentIfPossible消息才释放内存，否则啥也不做。
下面的代码表示了 NSPurgeableData 的简单使用，抄自 WWDC 2013, Session 704。
// 初始化完成 counter == 1
NSPurgeableData * purgeabelData = [[NSPurgeableData alloc] initWithBytes:fileBytes length:fileLen];
// 不需要使用数据时发送 endContentAccess 消息，counter == 0
[purgeabelData endContentAccess];
// 一段时间之后
// 发送 beginContentAccess 以获取数据，
// 如果返回 NO，则说明在内存紧张时，
// 这个对象指向的内存释放，需要重新生成。
// counter == 1
if ([purgeabelData beginContentAccess] == NO) {
purgeabelData = [[NSPurgeableData alloc] initWithBytes:fileBytes length:fileLen];
}
// 结束对对象的存取, counter == 0
[purgeabelData endContentAccess];
混合使用
NSPurgeableData 不是必须和 NSCache 搭配使用，不过前面的 WWDC 的 session 和文档中都有提到这一用法。NSCache 缓存可丢弃对象，如 NSPurgeableData，会形成 NSCache --> NSPurgeableData --> Purgeable Memory Region 这样的关系链，当 NSPurgeableData 指向的内存中数据被丢弃时候，cache 中的 NSPurgeableData 也会被移除。
