现在，不需要你快速执行
如果用户很快的滑动表格到底部，几十或几百个表格单元会出现在屏幕上，并向fastQueue请求图片数据，然后很快地从屏幕上消失。突然间这个并行地队列会将大量实际上不再需要的图片请求充斥进网络。当用户最终停止滑动时，那些当前屏幕上相应的表格单元视图会将它们的图片请求至于那些并不急需的请求后面，因此网络阻塞了。
这就是 wheremoveTaskToSlowQueueForURL:这个方法的产生的原因.
// a table cell is going off screen-
(void)tableView:(UITableView *)table
didEndDisplayingCell:(UITableViewCell *)cell
forRowAtIndexPath:(NSIndexPath*)indexPath {
// we don't need it right now, so move it to the slow queue
[SGImageCache moveTaskToSlowQueueForURL:[[(id)cell event] imageURL]];
}
这确保在fastQueue中的只会有真正需要被快速执行的任务。任何以前认为需要快速执行但现在不需要的任务会被移至slowQueue中。
重点和选择
已经有相当多的iOS图片缓存库。它们中一些库只针对某些应用场景，一些库提供了不同场景一定的可扩展性。我们的库即没有专门针对某些应用场景，也没有太多大而全的特性。针对我们的用户我们有三类基本的重点：
重点 1: 最好的帧率
很多的库都非常专注在这一点上，使用一些高度定制和复杂的方法，尽管基准没有决定性地显示这样有效。我们发现最好的帧率由这些决定：
将对磁盘的访问（并且几乎其它的所有）脱离主线程。
使用UIImage的内存缓存来避免不必要的磁盘访问和图片解压。
重点 2: 让最最重要的图片优先显示
大多数的库都考虑让队列管理成为别人关心的事。对于我们的应用，这几乎是最重要的点。
让正确的图片在正确的时间显示在屏幕上可以归结为一个简单的问题：“我们现在就需要它显示还是过一会儿？”。那些需要立即显示的图片是并行加载地，而其它所有东西都被添加到串行队列中。所有之前急迫的事但现在不急迫的话就会从fastQueue分到slowQueue中。并且当fastQueue在工作时，slowQueue是处于挂起状态的。
这让那些急需显示的图片可以单独访问网络，同时也确保了一张非急需显示的图片可以在过一会成为一张急需显示的图片，因为它已经存到了缓存当中，随时准备用于显示。
