NSThread与NSOperationQueue对比??? 在iPhone上
目前我正在使用NSThread缓存另一个线程中的图像。
[NSThread detachNewThreadSelector:@selector(cacheImage:) toTarget:self withObject:image];
交替：
[self performSelectorInBackground:@selector(cacheImage:) withObject:image];
或者，我可以使用NSOperationQueue
NSInvocationOperation *invOperation = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(cacheImage:) object:image];
NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];
[opQueue addOperation:invOperation];
是否有任何理由从NSThread切换？ GCD在iPhone上发布时是第四种选择，但除非有显着的性能提升，否则我宁愿坚持适用于大多数平台的方法。
基于@ Jon-Eric的建议，我使用了NSOperationQueue / NSOperation子类解决方案。 它工作得很好。 NSOperation类非常灵活，您可以根据需要将它与调用，块或自定义子类一起使用。 无论您如何创建NSOperation ，只要您准备好运行，就可以将其放入操作队列中。 如果需要，这些操作可以用作放入队列中的对象，也可以作为独立的异步方法运行。 由于您可以轻松地同步运行自定义操作方法，因此测试非常简单。
自从我问这个问题以来，我已经在一些项目中使用了相同的技术，并且我不能保持我的代码和测试的清洁，组织和愉快异步。
A ++++++++++会再次子类化
一般来说，你会用NSOperationQueue获得更好的里程NSOperationQueue 。
三个具体原因：
NSOperationQueue足够聪明，只能创建与核心数量相同的线程，排队其余的操作。 使用NSThread ，创建100个线程来缓存100个图像可能是矫枉过正并且效率不高。 cacheImage操作。 使用NSOperationQueue实现取消更容易; 大部分工作已经完成了。 NSOperationQueue现在或未来可以自由切换到更智能的实施（如Grand Central Dispatch）。 NSThread更可能永远只是一个操作系统线程。 奖金：
NSOperationQueue还有其他一些很好的内置构造，例如NSOperationQueue操作优先级和依赖关系的复杂方法。 我会使用NSOperationQueue 。 在OS 3.2下， NSOperationQueue在引擎下使用线程，所以这两种方法应该类似地执行。 但是，在Mac OS 10.6中， NSOperationQueue在NSOperationQueue使用GCD，因此具有不NSOperationQueue单独线程开销的优势。 我没有看OS 4的文档，但我怀疑它做了类似的事情 - 在任何情况下，如果/当GCD的性能优势可用于iPhone时， NSOperationQueue可以交换实现。