Do not change UI from anything but the main thread. While it may appear to work on some OS or devices and not others, it is bound to make your application unstable, and crash unpredictably.
If you must respond to a notification, which can happen in the background, then ensure UIKit invocation takes place on the main thread.
You at least have these 2 options:
Asynchronous Dispatch
Use GCD (Grand Central Dispatch) if your observer can be notified on any thread. You can listen and do work from any thread, and encapsulate UI changes in a dispatch_async:
dispatch_async(dispatch_get_main_queue()) {
// Do UI stuff here
}
When to use GCD? When you do not control who sends the notification. It can be the OS, a Cocoapod, embedded libraries, etc. Using GCD will woke anytime, every time. Downside: You find yourself re-scheduling the work.
Listen on Main Thread
Conveniently, you can specify on which thread you want the observer to be notified, at the time you are registering for notifications, using the queue parameter:
addObserverForName:@"notification"
object:nil
queue:[NSOperationQueue mainQueue]
usingBlock:^(NSNotification *note){
// Do UI stuff here
}
When to observe on main thread? When you are both registering and registered. Bu the time you respond to the notification, you are already where you need to be.
Post Notification On Main Thread
[self performSelectorOnMainThread:@selector(postNotification:) withObject:notification waitUntilDone:NO];
Hybrid solution which does not guarantee that the observer is only invoked from said method. It allows for lighter observer, at the cost less robust design. Only mentioned here as a solution you should probably avoid.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
