Low frame rate during UINavigationController push transition

Question

I have a UINavigationController, and push from the root view controller to the next view controller. This second view controller is fairly "heavy", in that it has a great deal of initialization and subviews.

My issue is this: the transition animation performs terribly. Basically, the animation suffers from a very low frame rate (I get maybe 3-4 frames in total out of the "push" animation).

I've tried a variety of different techniques, including two different methods to manually animate the transition. In all cases, the first 0.4-0.7 seconds of the animation suffers from this poor framerate. If I set the transition to take 5 seconds, for example, the first half second or so performs poorly, but the remainder of the animation is nice and smooth.

This leads me to believe that "something" is happening at the beginning of the transition -- something which causes the device to animate at a very low framerate.

After injecting a lot of NSLog statements into my code, I saw two things happen. First, obviously the second view is being lazy-loaded during the push. I fixed this by accessing the getter on the view property before executing the push. I can confirm that this results in all the initialization happening before the push animation begins.

Second, my app most of the time receives a low memory warning during the transition. However, even in cases when I don't get the memory warning, the animation still performs just as poorly -- leading me to believe that neither of these things is the cause.

My question: Has anyone else experienced a low framerate on a UINavigationController push transition animation, but only for the first 0.4-0.7 seconds of the animation? Is there something else going on behind the scenes that causes it, and can anything be done?

For reference, here's my current code that loads and pushes to the next view. I'm purposefully accessing the view getter in order to force the view to load and initialize before the transition (mostly to rule out that as the issue). This code is executed on the main thread using performSelectorOnMainThread::: in response to a web service callback.

PlayingFieldViewController *v = [[PlayingFieldViewController alloc] initWithNibName:@"PlayingFieldView" bundle:[NSBundle mainBundle]];
UIView *lazy = v.view;
[appDelegate.navigationController pushViewController:v animated:YES];
[v release];

I've also tried a few other animation techniques, all with the same result:

CATransition *transition = [CATransition animation];
transition.duration = 1.0;
transition.type = kCATransitionPush;
transition.subtype = kCATransitionFromRight;
[appDelegate.navigationController.view.layer addAnimation:transition forKey:kCATransition];
[appDelegate.navigationController pushViewController:v animated:NO];

and:

[UIView 
  transitionWithView:appDelegate.navigationController.view
  duration:1.0
  options:UIViewAnimationOptionTransitionCurlUp
  animations:^{
   [appDelegate.navigationController pushViewController:v animated:NO];
  }
  completion:NULL];

Answer 1

After further testing, I was able to diagnose the problem. The second view involved includes many UIImageViews. Removing those views or hiding them fixes the problem.

What threw me off was the fact that only the first portion of the animation suffered from frame rate issues, while the remainder of the animation was perfectly smooth (in the case of longer animations). This shows me that the device is quite capable of animating the transition smoothly, even with all the subviews present.

I'm still not an expert on iOS compositing, but I'm guessing the various layers are being laid out and cached, leading to the slowdown. The workaround is to push to the view with most of the subviews hidden, then show them using another animation once the view is visible.

Answer 2

I have not stumbled upon this with the navigation controller but I got much the same result when updating a table view from another thread, the UI was really slow to update at first but after a short delay everything was showing again. As Justin points out in a comment, you should do UI work on the main thread. A simple way to accomplish this is wrap your call to the UI in a GCD block:

dispatch_sync(dispatch_get_main_queue(), ^{
// Do UI stuff here
});

or use

performSelectorOnMainThread:withObject:waitUntilDone: