What's the difference between performSelectorOnMainThread: and dispatch_async() on main queue?

Objective CIosMultithreadingUikitGrand Central-Dispatch

Objective C Problem Overview


I was having problems modifying a view inside a thread. I tried to add a subview but it took around 6 or more seconds to display. I finally got it working, but I don't know how exactly. So I was wondering why it worked and what's the difference between the following methods:

  1. This worked -added the view instantly:
dispatch_async(dispatch_get_main_queue(), ^{
    //some UI methods ej
    [view addSubview: otherView];
}
  1. This took around 6 or more seconds to display:
[viewController performSelectorOnMainThread:@selector(methodThatAddsSubview:) withObject:otherView
    waitUntilDone:NO];
  1. NSNotification methods - took also around 6 seconds to display the observer was in the viewController I wanted to modify paired to a method to add a subview.
[[NSNotificationCenter defaultCenter] postNotificationName:
 @"notification-identifier" object:object];

For reference these were called inside this CompletionHandler of the class ACAccountStore.

accountStore requestAccessToAccountsWithType:accountType withCompletionHandler:^(BOOL granted, NSError *error) {
    if(granted) {
        // my methods were here
    }
}

Objective C Solutions


Solution 1 - Objective C

By default, -performSelectorOnMainThread:withObject:waitUntilDone: only schedules the selector to run in the default run loop mode. If the run loop is in another mode (e.g. the tracking mode), it won't run until the run loop switches back to the default mode. You can get around this with the variant -performSelectorOnMainThread:withObject:waitUntilDone:modes: (by passing all the modes you want it to run in).

On the other hand, dispatch_async(dispatch_get_main_queue(), ^{ ... }) will run the block as soon as the main run loop returns control flow back to the event loop. It doesn't care about modes. So if you don't want to care about modes either, dispatch_async() may be the better way to go.

Solution 2 - Objective C

It's likely because performSelectorOnMainThread:withObject:waitUntilDone: queues the message with common run loop modes. According to Apple's Concurrency Programming Guide, the main queue will interleave queued tasks with other events from the app's run loop. Thus, if there are other events to be processed in the event queue, the queued blocks in the dispatch queue may be run first, even though they were submitted later.

This article is a superb explanation to performSelectorOnMainThread vs. dispatch_async, which also answers the above question.

Solution 3 - Objective C

Did you try thePerformSelectorOnMainThread with waitUntilDone=YES

Eg:

Code:

[viewController performSelectorOnMainThread:@selector(methodThatAddsSubview:) withObject:otherView waitUntilDone:YES];

I think that might solve the issue as of why the PerformSelectorOnMainThread takes so long to respond.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionMiguel LomelíView Question on Stackoverflow
Solution 1 - Objective CLily BallardView Answer on Stackoverflow
Solution 2 - Objective CSay2ManujView Answer on Stackoverflow
Solution 3 - Objective CRuchira RandanaView Answer on Stackoverflow