What to do in a separate thread?

Question

So I've read some stuff about multithreading and NSOperation and wondering how I can use that to improve my app. Using Instruments I have isolated a few places where my app could definitely use a speed improvement. My question is, are these kinds of things suitable for another thread using NSOperation?

Drawing a view: I have a rather complex view that is taking a little time to draw. When it's drawn I experience some lag.

Allocating and playing audio: I'm using AVAudioPlayer to play some background music. When I allocate it, again some lag.

Calculations: I'm also performing some calculations and doing some comparisons with lots of integers.

I strive for the best possible performance for my app, so what would you do?

Answer 1

UI updates are not suitable on the Background thread. All UI updates always need to be done on the main thread. If your view is taking too much time to render, consider refactoring, pre-redering and caching or some other means of optimization.

Audio code can be background based, but shouldn't be that expensive

Calculations can definitely be backgrounded without worry.

Answer 2

I concur that background threads are not the thing to do for UI updates. Since the user is "blocked" on waiting for the UI to show them what is going on - it doesn't make sense from a logical point-of-view - and it can cause other coding issues.

The biggest thing I have found good for background threads often has to do with asynchronous operations. (Think of an AJAX web page). If you want your user to be able to interact with the UI while something is going on. A good example would be retreiving, updating, fetching any kind of data from the web.

Even if you are doing any kind of web operations which you would think should be synchronous - (like loading a message from a web site) - you would probibly want to handle it asynchronously because you don't know what kind of network conditions would cause it to take a long time - and perhaps eventually timeout or fail. (Something like recording audio would work like this too).

Even if you were to want to block your application when reading such a synchronous piece of data from the web, you may still want to do this asynchronously - so you could load the data in a background thread - while you give a progress bar, spinner (progress) control, or allowed the user to hit a "Cancel" button in the foreground UI thread.

Think of "asynchronous" requests as ones that will take a longer period of time - or in which you can't determine how much time it will take.

Answer 3

Some UI drawing methods were made thread safe with iOS 4.0:

source: Apple dev: What's new in iOS: iOS 4.0

Drawing to a graphics context in UIKit is now thread-safe. Specifically:

• The routines used to access and manipulate the graphics context can now correctly handle contexts residing on different threads.
• String and image drawing is now thread-safe.
• Using color and font objects in multiple threads is now safe to do.

I've found that my apps generally benefit the most from background threading:

• Downloading things from the web
• Expensive queries (reading/writing) to the database
• Long running algorithms

If you do decide to background some tasks, I would recommend using NSOperation and NSOperationQueue, as they simplify things a lot. A bit of a learning curve, but definitely worth it!

Best of luck!