Currently I'm using NSThread
to cache images in another thread.
[NSThread detachNewThreadSelector:@selector(cacheImage:) toTarget:self withObject:image];
Alternately:
[self performSelectorInBackground:@selector(cacheImage:) withObject:image];
Alternately, I can use an NSOperationQueue
NSInvocationOperation *invOperation = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(cacheImage:) object:image]; NSOperationQueue *opQueue = [[NSOperationQueue alloc] init]; [opQueue addOperation:invOperation];
Is there any reason to switch away from NSThread
? GCD is a 4th option when it's released for the iPhone, but unless there's a significant performance gain, I'd rather stick with methods that work in most platforms.
Based on @Jon-Eric's advice, I went with an NSOperationQueue
/NSOperation
subclass solution. It works very well. The NSOperation
class is flexible enough that you can use it with invocations, blocks or custom subclasses, depending on your needs. No matter how you create your NSOperation
you can just throw it into an operation queue when you are ready to run it. The operations are designed to work as either objects you put into a queue or you can run them as standalone asynchronous methods, if you want. Since you can easily run your custom operation methods synchronously, testing is trivially easy.
I've used this same technique in a handful of projects since I asked this question and I couldn't be happier with the way it keeps my code and my tests clean, organized and happily asynchronous.
A++++++++++ Would subclass again
There is no generic "best" out of the three.
GCD is a low-level C-based API that enables very simple use of a task-based concurrency model. NSOperation and NSOperationQueue are Objective-C classes that do a similar thing. NSOperation was introduced first, but as of 10.5 and iOS 2, NSOperationQueue and friends are internally implemented using GCD .
Overview. An operation queue invokes its queued NSOperation objects based on their priority and readiness. After you add an operation to a queue, it remains in the queue until the operation finishes its task. You can't directly remove an operation from a queue after you add it. Note.
In general you'll get better mileage with NSOperationQueue
.
Three specific reasons:
NSOperationQueue
is smart enough to only create about as many threads as there are cores, queuing the remaining operations. With NSThread
, creating 100 threads to cache 100 images is probably overkill and somewhat inefficient.cacheImage
operation. Implementing cancellation is easier with NSOperationQueue
; most the work is already done for you.NSOperationQueue
is free to switch to a smarter implementation (like Grand Central Dispatch) now or in the future. NSThread
is more likely to always be just an operating system thread.Bonus:
NSOperationQueue
has some other nice constructs built-in, such as a sophisticated way of honoring operation priorities and dependencies.I would use NSOperationQueue
. Under OS 3.2, NSOperationQueue
uses threads under the hood, so the two methods should perform similarly. However, under Mac OS 10.6, NSOperationQueue
uses GCD under the hood and so has the advantage of not having the overhead of separate threads. I haven't looked at the docs for OS 4, but I'd suspect it does something similar--in any case, NSOperationQueue
could swap implementations if/when the performance advantages of GCD become available for the iPhone.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With