iOS开发基础 | 被忽视和误解的NSCache

问题一:App重启后,NSCache中的东西还存在吗?


一听到缓存数据,我们脑海里立马浮现了《印象笔记》这样“理所当然”的功能:在WIFI环境中保存过的网络文章,在没有网络时(比如出门在外,关闭4G),看过的文章可以继续阅读,并不受网络关闭的影响。
NSCache可以帮助我们实现这样的功能吗?
并不能!!!

NSCache中的数据在APP重启(或重新init)后,都消失了,并不会保存下来。

也就是说,NSCache的正确名字应该叫做NSMemoryCache,只是将数据保存在内存中。

问题二:可以统计出NSCache中已经缓存的数据大小吗?


答案依然是

我们可以使用 countLimit 指定缓存中保存的对象数量
或用 totalCostLimit属性 +
- (void)setObject:(id)obj forKey:(id)key cost:(NSUInteger)num方法,勉强实现占用内存的控制。

注意:cost并没有说明必须等于对象占用的字节数。

这意味NSCache到底占用了多少内存,是使用者(就是苦逼的我们)自己计算的!

NSCache奇葩之处三:释放内存时,并不确定释放的对象的顺序。


这是什么意思呢?假设我们基于NSCache实现一个无限上拉的列表,当上拉到某一页,我们存入了当前页的数据对象,结果触发了内存警告,NSCache会自动释放,结果可能是刚存入的数据对象被清理了,而不是我们希望的“先进先出”顺序。

相信读到这里,有些童鞋已经出离愤怒了:这个奇葩缓存有什么用?

NSCache 是线程安全的


很多童鞋第一次实现TableView时,都会使用NSMutableArray当数据源,当实现下拉刷新时,何时清理这个数组就很重要了,如果TableView正在刷新,而数组又被清掉时,就会导致数组越界访问而崩溃,而使用NSCache就不会有此问题。

结合NSDiscardableContent协议使用


实现了这个协议的类需要在被引用之前,必须调用beginContentAccess来标记为可使用的,如果在使用之前没有调用beiginContentAccess,那么就会抛出异常。在使用结束之后,调用endContentAccess,来标记它为可以被释放的。如果实现了NSDiscardableContent协议的对象放入了NSCache中,那么,在清除它的时候,会调用discardContentIfPossible方法来判断引用状况,没有引用,则销毁。

这样,我们就可以很“精确”地控制对象的释放,配合NSCache的内存自动释放,达到既释放过期数据的目的,又不用担心对象过早被释放,如果另外实现这样的效果,需要做数据有效性判断,当然是费时费力。

另外,NSCache的KEY是不需要遵循NSCopying协议的,也就是说,作为KEY的对象并不会被拷贝,利用这点,可以做出一些NSDictionary无法实现的效果,请关注溪石iOS,了解更多开发技巧。

推荐阅读更多精彩内容