Difference between NSThreads, NSOperations and performSelector

Question

I want to ask some simple but important questions regarding iPhone development. If we have to perform tasks in the background and when the background tasks are completed we will update the UI, for this we can use NSThreads, NSOperations or (performSelector)performSelectorInBackgroundThread. What is the difference between all these and how they will effect my apps performance.

One more thing, what is the difference between these two statements written bellow:-

[self getData];

[self performSelector:@selector(getData)];

Please explain as i dont know the difference between all these things. 

Neoplasticism

When you use [self getData]; then its move to next line after complete this function call, in [self performselector:] its move to function and next line continuously – Waynant

What GhostRider commented is wrong. Those two are equivalent. – Ranchman

Thanks guys for your valuable responses, They helped me to understand the different ways of calling the methods and also explained Threads , Operations and performSelector. Thanks a lot. :) – Neoplasticism

Answer 1

There is actual not a big difference between

[self getData];

AND

[self performSelector:@selector(getData)];

The only difference is when you call [self getData] the compiler can determine that you want to send getData message to the object of class [self class] . And if it can't find any method prototypes, that were declared earlier there would be a warning.

The first and the second lines would be translated to

objc_msgsend(self, _cmd)

performSelector: is really cool thing when you want to do something at runtime (for example you determine at runtime what exact message you want to send to the object). Or here is an example from the "real life": UIButton has method

- (void)addTarget:(id)target action:(SEL)action forControlEvents:(UIControlEvents)controlEvents

So it stores the action somewhere in it's internals and when there is appropriate control event it calls:

[target performSelector: action];

NSOperation is just a nice way to wrap your work with threads. And NSThread is just wrapper to pthreads.

So your app performance doesn't really depend on the way you're using threads, however it's much easier to do that using NSOperation rather than pthreads.

Asthmatic

Answer 2

NSThread is wrapper for pthreads (POSIX threads). pthreads is implemented atop of Mach thread. You can set stack size, priority when you are using NSThread. (By the way, as far as my experience, stack size doesn't affect at all.)

NSOperation/NSOperationQueue is wrapper for Grand Central Dispatch (libdispatch) aka GCD. GCD is implemented atop of pthreads. These are more easily to use than NSThread for many tasks. It reduces boilerplate code for task queueing, thread pool managing and so forth.

performSelectorInBackground: invokes NSThread and treats terminated NSThread. It is the easiest to use in these for only one method invoking.

Fanti

Answer 3

To make a long story short, you need not work with NSThread yourself most of time, especially if you are working with Objective-C only, and the timing issue is not THAT critical. Implement the behavior using an operation queue or a dispatch queue.

NSOperation is a wrapper or an encapsulation of a certain task. The task could be defined as a method(NSInvocationOperation), or a block(NSBlockOperation), or anything you'd like (by subclassing NSOperation). So the first thing you need to do is to wrap your job in an appropriate way (in a method or a block typically).

Then you will put the operation into an operation queue. Then the operation queue will fire the task in a detached thread as soon as possible.

In iOS 4.0 and later, you can directly feed a block to the queue without building an operation object. Also you can use a different types of job queues, named dispatch queues.

performSelectorinBackgroundThread is similar to the queues as it also creates a thread for you and (effectively) run a method in that thread. It might be handy sometimes, but you still need to be very clear about the unit of tasks that will run on a detached thread. Many Cocoa methods are not thread-safe, and most UIKit operations need to run on the main thread.

That leads to the final concern. You may let detached threads work on the tasks, but updating UI according to their results should run on the main thread. For example, you can do like

[aUIObject performSelectorOnMainThread:@selector(setMessage:) withData:...

Ranchman