iOS UIPageViewController缺陷

为什么弃用UIPageViewController?
问题1:
设置UIPageViewController为UIPageViewControllerTransitionStyleScroll且调用setViewControllers:direction:animated:completion:传递参数animated YES时,会引发一系列症状,例如:
    1.    缓存页面导航设置不正确,Page View Controller会导航到错误的页面。
    2.    删除上一页view controller(已经切换完成后)失败,仍然可以scroll回到一个空白页。
这是UIPageViewController的bug,当且仅当UIPageViewController为.Scroll时,调用setViewControllers:direction:animated:completion: 且方法参数animated YES才可能出现。
错误的原因是,当使用.Scroll风格时,UIPageViewController做了一些内部的缓存排序,当调用setViewControllers:direction:animated:completion:时,它没有清空其内部缓存。它认为它已经知道前一个页面的存在,当它调用前一个页面的时候,就不会去调用dataSource方法或者调用错误。
根据这个描述,其实可以对之前的错误代码做相应的处理,通过再次调用setViewControllers方法强制重新调用dataSource方法以更新缓存。例如:
@weakify(self)
 [self.pageViewController setViewControllers:@[targetViewController]
                                   direction:direction
                                    animated:animated
                                  completion:^(BOOL finished)
 {
     @strongify(self)
     if (finished) {
         [self.pageViewController setViewControllers:@[self.pages[index]] direction:direction animated:NO completion:NULL];               
         // bug fix for uipageview controller
     }
 }];
很不幸这种做法引发了崩溃(iOS7/8/9):
Assertion failure in
[_UIQueuingScrollView_replaceViews:updatingContents:adjustContentInsets:animated:], /SourceCache/UIKit_Sim/UIKit-3318.16.14/_UIQueuingScrollView.m:383**
分析后发现我们忽略的一个重点,setViewControllers这个方法是更新页面的操作应该在主线程中调用。修改代码如下:
 @weakify(self)
 [self.pageViewController setViewControllers:@[targetViewController]
                                   direction:direction
                                    animated:animated
                                  completion:^(BOOL finished)
 {
     @strongify(self)
     if (finished) {
         dispatch_async(dispatch_get_main_queue(), ^
                        {
                            if (self) {
                                [self.pageViewController setViewControllers:@[self.pages[index]] direction:direction animated:NO completion:NULL];               
                                // bug fix for uipageview controller
                            }
                        });
     }
 }];
代码看起来虽然不怎么优雅,但好在这样可以继续使用UIPageViewController。直到我们发现了Fabric上的崩溃和上段解决方案代码引发的新问题:
Fabric崩溃:

UIPageViewController_Fabric.jpg
这个崩溃在iOS7/8/9上都有出现。显然这和Apple Developer Forums中提到的问题现象是一样的:No view controller managing visible view:
但Apple Developer Forums中的问题,是因为没有在主线程中执行第二次setViewControllers方法导致的。我们的代码里已经做了相应处理,但仍然有小规模数量的崩溃。很不幸,暂时还没找到Fabric崩溃的具体复现方式。
上图说明,上段代码并没有完全解决page view controller页面缓存不正确的bug。只是不会那么频繁地出现。
引发新问题:
此外还发现:当通过上段代码导航切换index的时候,如果第一次导航(setViewControllers)动画没有结束时,马上开始第二次导航(setViewControllers)。很容易复现问题:页面没有停在最终的那个index上。这是因为第二次主动调用的带动画的setViewControllers执行在第一次调用的回调的无动画的setViewControllers之前导致的。
问题2:
切换childViewController引起的卡顿问题很严重。在iPhone4、4s、5、5c、甚至5s上都会有不同程度的卡顿问题:
一般情况下,page view controller切换页面的资源消耗至少相当于调用一次transitionFromViewController:toViewController:duration:options:animations:completion:。在硬件配置较低的iPhone4、4s等手机上就会有明显卡顿,如果child view controller的生命周期方法中再做一些消耗资源的操作,App甚至会因为切换导致资源占用过多、内存警告,最终引起Crash。这种情况给低配手机性能优化带来了很大障碍。
其性能问题主要体现在,切换childController时候的CPU占用升高、以及切换时的内存频繁波动。
静止状态下,其CPU占用率位置在很低的水品甚至不到1%,当child congroller切换时,其CPU占用率如图所示(iPhone6 Plus/iOS9.3):

UIPageViewController快速非交互切换_CPU.png

UIPageViewController快速交互切换_CPU.png
文章开头介绍UIPageViewController时提到过,UIPageViewController的设计更多的考虑了少占用内存,从下图中内存的波动曲线也可以看到。当频繁切换child controller时,UIPageViewController尽可能快的清理内存。快速切换时,其内存波动如下图所示(iPhone6 Plus/iOS9.3):
总结:
经过多个设备、系统版本的测试和网上资料的整理。问题1的处理方案是现在最主流的一种解决方案,但这样的方案仍然引发了Fabric崩溃和新的缺陷问题,从保证App质量的角度出发,这个解决方案是不可取的。问题2的性能问题虽然在高配手机上并不明显,但考虑的所有用户的体验这个缺陷也很值得去优化。
为了彻底解决这些缺陷问题,重新开发一个Page view controller控件来彻底解决UIPageViewController带来的缺陷问题。

 

posted on 2016-11-30 14:05  雨季的雾  阅读(744)  评论(0编辑  收藏  举报