上回书说animated隐式动画的血与泪, 今天要说的可能和崩溃无关, 但是又是很多诡异的崩溃的根源: 内存泄露.
内存泄露的原因
1 循环引用了, 这个很多初学者是懵逼的, 但是有一定开发经验的人都不陌生.
2 超大图片霸占内存.
3 局部变量造成的无法释放.
关于解决办法
1 循环引用的问题已经有太多的人去写博客了, 简书上随便一搜也是一大堆的, 无非是几个关键字, weak, block, target, 本文就不详细解读了.
2 对于长期不使用但是却很大的图片, 不应该使用imageNamed去初始化UIImage, 严格上来说这也不算什么内存泄露, 因为你可能觉得imageNamed分配的内存苹果会帮我们管理好的, 如果真是这样那也就好了. 所以还是要使用得当, 不浪费一点内存.
3 本文要讨论的重点话题, 当UIAlertView使用不当的时候会造成内存泄露.
场景复现
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
UIAlertView* alertView = [[UIAlertView alloc] initWithTitle:@""
message:@"您的号在另一终端登录"
delegate:self
cancelButtonTitle:@"确定"
otherButtonTitles:@"取消", nil];
[alertView show];
[self.navigationController popViewControllerAnimated:YES];
}
这段代码看起来好像并没什么问题, 而且许多有开发经验的程序员也可能一直都是这样写的.
问题
当当前页面被pop的时候, alertView仍然显示, 这时候如果系统是iOS9以下的就会造成内存泄露了.
内存泄露
但是同样的代码在, 在iOS9及以上的系统上是没有内存泄露的, 可能是系统的问题吧, 那么我们来从以下几个方面探究下, 到底问题出现在哪里了.
1 UIAlertView的dealloc有没有调到?
2 是不是delegate持有了UIAlertView造成没释放.
3 到底应该如何避免内存泄露.
解决方案
对于一些有经验的开发者估计直接跳到这里了吧, 好吧, 呵呵, 下面来一一解答上面的问题.
1 UIAlertView的dealloc执行了, 而且是Controller的dealloc执行完才执行的, 这个可以通过hook UIAlertView的dealloc来实现, 如果hook dealloc可以参考楼主之前的一篇文章传送门. 这里就不详细说如何hook了, 黑魔法大家都懂的.
2 delegate没有持有UIAlertView造成没有释放, 其实1里并不能完全说明问题, 因为即使VC dealloc了并不代表delegate一定被置空了, unsafe_unretain大家懂的, 那如果delegate没置空就会在VC dealloc后继续调用delegate里的方法, 这样就可能会崩溃, 但是我们实现了UIAlertViewDelegate的- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
但是VC dealloc后这里并没有来到. 也就是说, delegate并没有持有UIAlertView.
3 那问题到底出现在哪里了? 为什么iOS9 以上就没内存泄露呢, 好吧, 说下自己的猜想吧, 可能iOS8系统上, UIAlertView的清理工作是在- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex中进行的, 如果这里没机会走到, 就可能会造成内存泄露 , 那iOS9以上的呢, 我猜想应该是系统hook了alertView这个实例的类似didMoveToSuperview这样的方法, 所以在alertView真实被关闭的时候会进行清理工作.
但是我们尝试hook willMoveToSuperview willMoveToWindow实际并没有效果, 那为什么呢? 这就应该猜想, alertView这个实例没被添加到任何的window上面
通过打印下面的日志
NSLog(@"alertview window:%@", [alertView window]);
NSLog(@"keywindow:%@", [UIApplication sharedApplication].keyWindow);
会得到下面的结果
同一个window
我们发现, 原来alertView所在的window是keywindow, 但是遍历keywindow上面的subview并没发现我们的alertView
NSLog(@"alertView:%p", alertView);
for (UIView *subView in [UIApplication sharedApplication].keyWindow.subviews) {
NSLog(@"subView of keyWindow:%p:%@", subView, NSStringFromClass([subView class]));
}
并不是一个view
到了这里估计很多读者已经懵逼了, WTF, 既然alertView的window是keywindow那就应该是keywindow的subview啊! 分析到这里楼主也是懵逼了, 但是, 寡人不甘心啊, 继续分析!
在[alertView show]前后同样打印
UIWindow *keyWindow = [UIApplication sharedApplication].keyWindow;
NSLog(@"keywindow:%@", keyWindow);
结果!
keywindow变化了
这里发现可以window发生了变化, _UIAlertControllerShimPresenterWindow就是要显示alertView的window, 但是在没显示的时候, 这个window不是keywindow, keywindow还是你在appdelegate里创建的那个self.window. 所以这里在show的时候应该是发生了一次
makeKeyAndVisible类似的操作, 这样_UIAlertControllerShimPresenterWindow就变成keywindow了, 那可想而知关闭的时候必然是执行了相反的操作, 把原来的keywindow又还原回去了. 那我想_UIAlertControllerShimPresenterWindow的清理工作必然是在alertView消失的时候调用的, 但并不一定是在代理执行的时候. 好吧, 跑题了, 回到正文, 如果防止内存泄露!
两种解决方案
1 在VC dealloc的时候手动调用dismissWithClickedButtonIndex, 当然, 这个时候要把alertView变成全局的.
2 另外开一个常驻的service, 任何时候都可以控制alertView
对于方案1, 有时候可能不能满足需求, 因为, 当VC disappear的时候可能产品并不希望alertView消失, 而是等用户手动点击的时候才消失, 但是这个时候代理方法已经失效了, 点击也无法进行处理了. 而且可能会引起崩溃! 至于具体的崩溃下回再说.
对于方案2, 是比较好的解决方案, 但是, 要全局可能会有很多地方都弹alertView, 如果统一全局管理会有很多, 不是很好!
总结:
综上, 全局管理UIAlertView是一种比较靠谱的方式, 但是, 成本比较高, 所以, 除非必要的时候(产品极力要求的情况下), 当在VC中创建的UIAlertView在VC被dealloc的时候直接关掉. 如果非要显示的那种, 就做成全局的, 确保这个UIAlertView完全在自己的控制下.
网友评论