CODEWITHSUNDEEP
iosmultithreadingavfoundation
Cbas
Cbas

Reputation: 6213

iOS interface freeze caused by background thread

I have an app that needs to preload a bunch of streamed videos as soon as possible so that they play instantly when the user clicks on them.

I am able to achieve this with a collection of AVPlayer objects, initialized right when the app is launched:

-(void)preloadVideos {
    for (Video* video in arrayOfVideos){
        NSString *streamingURL = [NSString stringWithFormat:@"https://mywebsite.com/%@.m3u8", video.fileName];
        AVURLAsset *asset = [AVURLAsset URLAssetWithURL:[NSURL URLWithString:streamingURL] options:nil];
        AVPlayerItem *playerItem = [AVPlayerItem playerItemWithAsset:asset];
        AVPlayer *player = [AVPlayer playerWithPlayerItem:playerItem];
        pthread_mutex_lock(&mutex_videoPlayers);
          [_videoPlayers setObject:player forKey:videoKey];
        pthread_mutex_unlock(&mutex_videoPlayers);
    }
}

The lock is defined in init as:

pthread_mutex_init(&mutex_videoPlayers, NULL);

My problem is that when I invoke this function, the app freezes for about 1 minute, then continues on with no problem. This is obviously because there is a lot of processing going on - according to the debug dashboard in xcode, CPU usage spikes to about 67% during the freeze.

So I thought I could solve this by putting the operation into a background thread:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
    [self preloadVideos];
});

but the app still froze briefly in exactly the same way, and CPU usage had the same pattern. I thought maybe its because the task is too intensive and needed to be broken up into smaller tasks, so I tried serializing the loop as distinct tasks:

preloadQueue = dispatch_queue_create("preloadQueue", NULL);
... 
-(void)preloadVideos {
    for (Video* video in arrayOfVideos){
        dispatch_async(preloadQueue, ^(void){
            [self preloadVideo:video]; // a new function with the logic above
        });
    }

but that seemed to make the freeze period longer, even though max CPU usage went down to 48%.

Am I missing something with these GCD functions? Why does the AVPlayer creation block the main thread when put into background tasks?

I know its not that there are too many AVPlayers created, because there are only 6 of them, and the app runs fine after they are created.

After adding log messages I notice that (in all implementations), the setObject call is called for every single video player before the interface's viewDidAppear method is called. Also, 5 videos load instantly, and the last - a longer one - takes a while but the freeze ends right when it completes.

Why is the app waiting for background tasks to finish before updating the views?

Update:

The app accesses videoPlayers while these tasks are running, but since I use a lock while writing, I don't lock while reading. Here is the definition:

@property (atomic, retain) NSMutableDictionary *videoPlayers;

Update: updated preloadVideos with mutex locks, still seeing the freezing

Upvotes: 1

Views: 1816

Answers (2)

Cbas
Cbas

Reputation: 6213

Turns out the background thread was locking a resource that the main thread was accessing elsewhere. The main thread needed to wait for the resource to become freed, which caused the interface to freeze.

Upvotes: 3

Duncan C
Duncan C

Reputation: 131426

Your dispatch_async code should not be freezing the main thread. That should be creating the asset objects in the background. It will take time before the assets become available, but that should be ok.

What do you mean "...the app still froze briefly..." Froze how? And for how long?

How are you using the _videoPlayers array once you've loaded it? What are you doing to handle the fact that the array may only be partially loaded? (If you are looping through the _videoPlayers array when it gets saved to from the background you may crash.) At the very least you should make videoPlayers an atomic property of you class and always reference it (read and write) using property notation (self.videoPlayers or [self videoPlayers], never _videoPlayers.) You will probably need better protection than that, like using @synchronized for the code that accesses the array.

Upvotes: 0

Related Questions