UINavigationController 推送转换期间帧速率低
我有一个 UINavigationController，并从根视图控制器推送到下一个视图控制器。第二个视图控制器相当“重”，因为它有大量的初始化和子视图。
我的问题是：过渡动画表现得很糟糕。基本上，动画的帧速率非常低（我从“推”动画中总共得到了 3-4 帧）。
我尝试了各种不同的技术，包括两种不同的方法来手动设置过渡动画。在所有情况下，动画的前 0.4-0.7 秒都会受到帧速率不佳的影响。例如，如果我将过渡设置为 5 秒，则前半秒左右的效果会很差，但动画的其余部分则非常流畅。
这让我相信在过渡开始时正在发生“某些事情”——导致设备以非常低的帧速率进行动画处理。
在我的代码中注入大量 NSLog 语句后，我看到发生了两件事。首先，显然第二个视图在推送期间被延迟加载。我通过在执行推送之前访问视图属性上的 getter 来修复此问题。我可以确认这会导致所有初始化发生在推送动画开始之前。
其次，我的应用程序在转换过程中大多数时候都会收到内存不足的警告。然而，即使在我没有收到内存警告的情况下，动画的表现仍然很差——这让我相信这些都不是原因。
我的问题：是否有其他人在 UINavigationController 推送过渡动画中遇到过低帧率，但仅在动画的前 0.4-0.7 秒？幕后是否还有其他原因导致了这种情况，可以采取什么措施吗？
作为参考，这是我当前加载并推送到下一个视图的代码。我有目的地访问视图获取器，以便强制视图在转换之前加载和初始化（主要是为了排除这个问题）。此代码使用 performSelectorOnMainThread::: 在主线程上执行，以响应 Web 服务回调。
PlayingFieldViewController *v = [[PlayingFieldViewController alloc] initWithNibName:@"PlayingFieldView" bundle:[NSBundle mainBundle]];
UIView *lazy = v.view;
[appDelegate.navigationController pushViewController:v animated:YES];
[v release];
我还尝试了一些其他动画技术，均具有相同的结果：
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];
并且：
[UIView
transitionWithView:appDelegate.navigationController.view
duration:1.0
options:UIViewAnimationOptionTransitionCurlUp
animations:^{
[appDelegate.navigationController pushViewController:v animated:NO];
}
completion:NULL];
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];
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
经过进一步测试，我能够诊断出问题。涉及的第二个视图包括许多
UIImageViews。删除这些视图或隐藏它们可以解决问题。让我失望的是，只有动画的第一部分遇到帧速率问题，而动画的其余部分则非常流畅（在较长动画的情况下）。这向我表明，即使存在所有子视图，该设备也能够顺利地实现过渡动画。
我仍然不是 iOS 合成方面的专家，但我猜测各个层正在被布局和缓存，导致速度变慢。解决方法是推送到隐藏了大部分子视图的视图，然后在视图可见时使用另一个动画显示它们。
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.
我没有在导航控制器中偶然发现这一点，但在从另一个线程更新表视图时，我得到了大致相同的结果，UI 一开始更新速度非常慢，但在短暂的延迟后，所有内容都再次显示。正如 Justin 在评论中指出的那样，您应该在主线程上进行 UI 工作。实现此目的的一个简单方法是将您对 UI 的调用包装在 GCD 块中：
或使用
performSelectorOnMainThread:withObject:waitUntilDone: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:
or use
performSelectorOnMainThread:withObject:waitUntilDone: