IOS缓存机制详解.doc

IOS缓存机制详解 为什么要有缓存 应用需要离线工作的主要原因就是改善应用所表现出的性能。将应用内容缓存起来就可以支持离线。我们可以用两种不同的缓存来使应用离线工作。第一种是**按需缓存**，这种情况下应用缓存起请求应答，就和Web浏览器的工作原理一样；第二种是**预缓存**，这种情况是缓存全部内容（或者最近n条记录）以便离线访问。 像第14章中开发的Web服务应用利用按需缓存技术来改善可感知的性能而不是提供离线访问。离线访问只是无心插柳的结果。Twitter和Foursquare就是很好的例子。这类应用得到的数据通常很快就会过时。对于一条几天前的推文或者朋友上周在哪里你能有多大兴趣？一般来说，一条推文或者一条签到的信息只在几个小时内有意义，而24小时之后就变得无关紧要。不过大部分Twitter客户端还是会缓存推文，而Foursquare的官方客户端在无网络连接的情况下打开，会显示上次的状态。 大家可以用自己喜欢的Twitter客户端来试一下，Twitter for iPhone、Tweetbot或其他应用：打开某个朋友的个人资料并浏览他的时间线。应用会获取时间线并填充页面。加载时间线时会看到一个表示正在加载的圆圈在旋转。现在进入另一个页面，然后再回来打开时间线。你会发现这次是瞬间加载的。应用还是在后台刷新内容（在上次打开的基础上），但是它会显示上次缓存的内容而不是无趣地转圈，这样看起来就快多了。如果没有缓存，用户每次打开一个页面都会看到圆圈在旋转。无论网络连接快还是慢，减小网络加载慢的影响，让它看起来很快，是iOS开发者的责任。这就能大大改善用户满意度，从而提高了应用在App Store中的评分。 另一种缓存更加重视被缓存数据，并且能快速编辑被缓存的记录而无需连接到服务器。代表应用包括Google Reader客户端，稍后阅读类的应用Instapaper等。 缓存的策略： 上一节中讨论到按需缓存和预缓存，它们在设计和实现上有很大的不同。按需缓存是指把从服务器获取的内容以某种格式存放在本地文件系统，之后对于每次请求，检查缓存中是否存在这块数据，只有当数据不存在（或者过期）的情况下才从服务器获取。这样的话，缓存层就和处理器的高速缓存差不多。获取数据的速度比数据本身重要。而预缓存是把内容放在本地以备将来访问。对预缓存来说，数据丢失或者缓存不命中是不可接受的，比方用户下载了文章准备在地铁上看，但却发现设备上不存在这些文章。 像Twitter、Facebook和Foursquare这样的应用属于按需缓存，而Instapaper和Google Reader等客户端则属于预缓存。 实现预缓存可能需要一个后台线程访问数据并以有意义的格式保存，以便本地缓存无需重新连接服务器即可被编辑。编辑可能是“标记记录为已读”或“加入收藏”，或其他类似的操作。这里**有意义的格式**是指可以用这种方式保存内容，不用和服务器通信就可以在本地作出上面提到的修改，并且一旦再次连上网就可以把变更发送回服务器。这种能力和Foursquare等应用不同，虽然使用后者你能在无网络连接的情况下看到自己是哪些地点的地主（Mayor），当然前提是进行了缓存，但无法成为某个地点的地主。Core Data（或者任何结构化存储）是实现这种缓存的一种方式。 按需缓存工作原理类似于浏览器缓存。它允许我们查看以前查看或者访问过的内容。按需缓存可以通过在打开一个视图控制器时按需地缓存数据模型（创建一个数据模型缓存）来实现，而不是在一个后台线程上做这件事。也可以在一个URL请求返回成功（200 OK）应答时实现按需缓存（创建一个URL缓存）。两种方法各有利弊，稍后我会在24.3节和24.6节中解释各个方法的优缺点。 选择使用按需缓存还是预缓存的一个简便方法是判断是否需要在下载数据之后处理数据。后期处理数据可能是以用户产生编辑的形式，也可能是更新下载的数据，比如重写HTML页面里的图片链接以指向本地缓存图片。如果一个应用需要做上面提到的任何后期处理，就必须实现预缓存。 存储缓存： 第三方应用只能把信息保存在应用程序的沙盒中。因为缓存数据不是用户产生的，所以它应该被保存在NSCachesDirectory，而不是NSDocumentsDirectory。为缓存数据创建独立目录是一项不错的实践。在下面的例子中，我们将在Library/caches文件夹下创建名为MyAppCache的目录。可以这样创建： NSArray *paths = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES); NSString *cachesDirectory = [paths ob