我们的 iOS 应用都包含了大量的图像。创建富有吸引力的视图，主要依赖于大量的装饰图片，所有这些首先必须从远程服务器获取。如果每次打开应用都要从服务器一次又一次的获取每个图像，那么用户体验肯定达不到好的效果，所以本地缓存远程图像是非常有必要的。
两种方式加载本地图片
1.通过imageNamed:方法加载图片
用过这种方式加载图片，一旦图片加载到内存中，那么就不会销毁，一直到程序退出。（也就是说imageNamed:会有图片缓存的功能，当下次访问图片的时候速度会更快。）
用这种方式加载图片，图片的内存管理并不受程序员控制。
因为没有缓存，所以如果相同的图片多次加载，那么也会有多个图片对象来占用内存，而不是用缓存的图片。
使用这个方法，需要file的全路径（之前用NSString, NSArray之类的加载文件也是一样的，比如stringWithContentsOfFile:，看到file就知道是需要传入全路径。）
快速队列和慢速队列
我们设置了两个队列，一个串行，一个并行。在屏幕上被迫切要求的图片进入并行队列（fastQueue），可能晚点才需要的图片进入串行队列（slowQueue）。
就UITableView的实现而言，这意味着在屏幕上的表格单元从fastQueue获取图片， 每个关闭的屏幕行的图片从slowQueue预加载。
现在不需要处理图片
假设我们要从服务器上请求包含30条事件的一页资讯回来，一旦这些内容请求回来时我们就可以排队等待预取其中的每一张图。
现在就要处理图片
显示在屏幕上的表格希望立即显示它们的图片，所以在table cell子类当中实现：
一直异步
等等，getImageForURL:不是一个异步方法吗？如果你明知道图片已经在缓存中，但是却不想在主线程上立即使用它吗？直觉告诉你那是错误的。
从磁盘上加载图片太费资源，同样解压图片也会费很多资源。可以在滑动的过程当中进行配置和添加表格，这最后一件你想在滑动表格时做的事是很危险地，因为它会阻塞主线程，会有卡顿的现象出现。
使用getImageForURL:可以让磁盘加载的动作脱离主线程，于是当thenDo:这个用于收尾工作的代码块执行的时候它已经有了一个UIImage实例，从而不会有滑动卡顿的危险。如果图片已经存在于本地缓存当中，用于收尾工作的代码块会在下一次运行周期执行，并且用户不会注意到两者之间的差别。他们会注意到的是滑动不会卡顿了。
现在，不需要你快速执行
如果用户很快的滑动表格到底部，几十或几百个表格单元会出现在屏幕上，并向fastQueue请求图片数据，然后很快地从屏幕上消失。突然间这个并行地队列会将大量实际上不再需要的图片请求充斥进网络。当用户最终停止滑动时，那些当前屏幕上相应的表格单元视图会将它们的图片请求至于那些并不急需的请求后面，因此网络阻塞了。
这就是 wheremoveTaskToSlowQueueForURL:这个方法的产生的原因.
重点和选择
已经有相当多的iOS图片缓存库。它们中一些库只针对某些应用场景，一些库提供了不同场景一定的可扩展性。我们的库即没有专门针对某些应用场景，也没有太多大而全的特性。针对我们的用户我们有三类基本的重点：
重点 1: 最好的帧率
很多的库都非常专注在这一点上，使用一些高度定制和复杂的方法，尽管基准没有决定性地显示这样有效。我们发现最好的帧率由这些决定：
将对磁盘的访问（并且几乎其它的所有）脱离主线程。
使用UIImage的内存缓存来避免不必要的磁盘访问和图片解压。
重点 2: 让最最重要的图片优先显示
大多数的库都考虑让队列管理成为别人关心的事。对于我们的应用，这几乎是最重要的点。
让正确的图片在正确的时间显示在屏幕上可以归结为一个简单的问题：“我们现在就需要它显示还是过一会儿？”。那些需要立即显示的图片是并行加载地，而其它所有东西都被添加到串行队列中。所有之前急迫的事但现在不急迫的话就会从fastQueue分到slowQueue中。并且当fastQueue在工作时，slowQueue是处于挂起状态的。
这让那些急需显示的图片可以单独访问网络，同时也确保了一张非急需显示的图片可以在过一会成为一张急需显示的图片，因为它已经存到了缓存当中，随时准备用于显示。
重点 3: 尽可能简单的API
大多数库都做到了这一点。许多库为了隐藏细节内容而提供了UIImageView的分类，并且许多库让抓取一张图片的流程变得尽可能的便利。针对我们经常做的三件事，我们的库选定了三个主要的方法：
快速抓到一张图
结论
通过专注于预取，队列管理，从主线程移除耗时的任务，并且依赖于UIImage内置的内存缓存，我们努力从一个简单的软件包中得到好的结果。
新闻热点
疑难解答
