上回书说AFN多线程崩溃实难重现, 这回的崩溃是不定概率重现的, 今天来说下animated隐式动画的血与泪.
不定概率重现的BUG或者CRASH往往可以从以下几个角度分析.
1 时序问题没处理好. 本来觉得可能先来的通知却后到了, 而你的例如初始化操作可能因此错过, 这就导致了异常.
2 超时没处理. 发送网络请求都有可能没有回调, 无论是通知(Notification)、块(block)还是代理(delegate)方式, 都需要对网络超时有处理, 否则写出的代码是不鲁棒的.
3 网络返回的数据有异常. 比如, 你发一个HTTP请求希望得到一个数组的结果, 可服务端却返回一个字典, 但你代码里面对数据的解析都是针对字典的, 这里如果不加保护就一定会崩溃. (不要鄙视我说这点, 就是工作了近10年的老程序员也可能会忽略这个保护).
4 用户手太快. 我们在开发的过程中, 通常是按照常理, 按部就班的点击按钮进行操作, 但APP在用户手中是如果点击的谁也说不准, 这样, 我们在开发中就应该重视方法的触发会造成什么后果, 一个方法多次调用(可能是不存在的, 可能是存在的, 但是你想不到)会不会影响程序的运行, 都是我们应该重视的(这点我深信, 初学开发的人是绝对不会去考虑的).
今天我们要重现的就是应对用户手快这种崩溃, 顺便说下animated隐式动画的血泪史.
有一定开发经验的人通常都不会使用系统自带的UINavigationController, 因为这个Controller的BUG实在太多, 如果线上版本使用此Controller估计你会哭的很有节奏. 网上会有很多对UINavigationController的封装, 有带block的, 有排队的, 你会写一个类似isViewInTransition的flag, 来标志是否有vc正在做动画呢, 但都不见得能避免我们今天说的问题.
[self.navigationController popViewControllerAnimated:YES];
[self.navigationController pushViewController:vc animated:YES];
你可能会在项目中写过类似这种代码吧, 先pop一个, 然后立马push, 在加了排队处理逻辑后, 这样写是没问题的, 当animated == YES的时候, 把后续的操作放入一个队列, 等didShowViewController后再去执行队列里面的操作. 当然有了队列, 你写下面的代码也是没问题的.
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController pushViewController:vc animated:YES];
WTF, 一个vc怎么push N次? 用户手太快了, 没办法, 如果用户点了下没反应, 比较狂躁的用户可能会一直点, 或许不止3次呢, 有了操作队列这样的狂躁我们也不怕, 那么问题又来了.
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController popViewControllerAnimated:YES];
[self.navigationController pushViewController:vc animated:YES];
用户再点了2次没反应后, 决定先返回一下, 但还是没反映, 于是又点了下, 你可能会说, 这样还是不会有问题, 而且我们点击按钮的时候通常都是新new一个vc再push, 即使有问题, 最多就是一个页面会被push好几次, 但是不会崩溃, 但是不一定所有人都会new一个, 可能那个vc早就new好了在那等着push了, 你写一个框架, 就是要满足各种脑残开发和狂躁用户, 任他们怎么搞我都不死. 好了, 下面问题来了
[self.navigationController popViewControllerAnimated:NO];
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController pushViewController:vc animated:YES];
这样写会不会崩溃, 答案是:不一定, 我去怎么还不一定, 上面的代码是伪代码, 通常不会有哪个开发会在一个方法里写这样的代码, 实际的情况可能是这样的:
- (void)funA {
[self.navigationController pushViewController:vc animated:YES];
}
- (void)funB {
[self.navigationController popViewControllerAnimated:NO];
[self.navigationController pushViewController:vc animated:YES];
}
- (void)funC {
dispatch_async(dispatch_get_main_queue(), ^{
[self funB];
});
dispatch_async(dispatch_get_main_queue(), ^{
[self funA];
});
}
这里就要说到我们使用animated的一个误区(至少是我的误区), 你觉得你使用了animated:NO, 系统就会等这次操作结束后再去执行下面的代码吗? 实际上是不会的, 即使animated为NO也还是要进行一个比较复杂的处理的, 系统不会傻傻的等在那里, 等popViewControllerAnimated对应的didShowViewController执行完才会处理下面的代码, 绝对不会, 这里有个runloop的问题, 因为funB中连续2行代码, CPU一定是要把这个方法执行完才会结束本次runloop的, 所以在[self.navigationController pushViewController:vc animated:YES];执行完之前, popViewControllerAnimated对应的didShowViewController绝对不会来到, 以为runloop这时候正忙着执行funB呢, 不会去到didShowViewController的调用者那里, 但是一旦funB执行完, 那后面的事情就无法预知了, 所以后面到底是执行didShowViewController还是执行funA是不一定的, 所以答案就是不一定.
回到正题, 那这样怎么就崩溃了呢?
执行funB 会调用你重写的- (UIViewController *)popViewControllerAnimated:(BOOL)animated;和- (void)pushViewController:(UIViewController *)viewController animated:(BOOL)animated; 但是如果你一激动, 把animated为NO的操作没加入队列就可能造成后面的崩溃了, 因为pop的didShowViewController回调后, 你可能会无脑的重置isViewInTransition的flag, 然后你会取出队列中正在排队的操作去执行, 如果CPU选择先执行funA, 就会造成实际上我们间接的写了这样的代码
[self.navigationController popViewControllerAnimated:NO];
[self.navigationController pushViewController:vc animated:YES];
[self.navigationController pushViewController:vc animated:YES];
有些同学可能已经凌乱了, 给大家整理下,
连续调用上面的代码, 会连续执行3次重写的push
1 看到NO, isViewInTransition 不变, 还是NO, 后面不用排队
2 看到YES, 检查下isViewInTransition为NO, 直接push, 并把 isViewInTransition 置为YES, 后续的操作要排队
3 看到YES, 并且isViewInTransition, 不能push, 需要排队.
这样队列里面就有一个待执行的push, 当第一个pop在主线程终于有空执行自己对应的didShowViewController时候把isViewInTransition置为YES, 并取出队列进行操作, 这样vc就被第二次执行了重写的push了, 而且此时的self.viewControllers还是pop之后的状态, 因为第一次push的didShowViewController还没有来到, self.viewControllers还没改变, 所以当就崩溃了, 原因是同一个vc被push了2次.
总结:
造成崩溃的主要原因是animated为NO的操作没有设置isViewInTransition, 修改的变法也很简单, 不管animated是否为YES, 一律置isViewInTransition, 保证同一时间只能执行一个操作, 让push或者pop操作变成串行的, 这样就不用发愁狂躁用户和脑残开发用法不当导致崩溃了.
有关animated引发的血案还有很多, 感兴趣的读者可以点击下面的链接
UIScrollView导致的崩溃
