上回書(shū)說(shuō)animated隱式動(dòng)畫(huà)的血與淚, 今天要說(shuō)的可能和崩潰無(wú)關(guān), 但是又是很多詭異的崩潰的根源: 內(nèi)存泄露.
內(nèi)存泄露的原因
1 循環(huán)引用了, 這個(gè)很多初學(xué)者是懵逼的, 但是有一定開(kāi)發(fā)經(jīng)驗(yàn)的人都不陌生.
2 超大圖片霸占內(nèi)存.
3 局部變量造成的無(wú)法釋放.
關(guān)于解決辦法
1 循環(huán)引用的問(wèn)題已經(jīng)有太多的人去寫(xiě)博客了, 簡(jiǎn)書(shū)上隨便一搜也是一大堆的, 無(wú)非是幾個(gè)關(guān)鍵字, weak, block, target, 本文就不詳細(xì)解讀了.
2 對(duì)于長(zhǎng)期不使用但是卻很大的圖片, 不應(yīng)該使用imageNamed去初始化UIImage, 嚴(yán)格上來(lái)說(shuō)這也不算什么內(nèi)存泄露, 因?yàn)槟憧赡苡X(jué)得imageNamed分配的內(nèi)存蘋(píng)果會(huì)幫我們管理好的, 如果真是這樣那也就好了. 所以還是要使用得當(dāng), 不浪費(fèi)一點(diǎn)內(nèi)存.
3 本文要討論的重點(diǎn)話題, 當(dāng)UIAlertView使用不當(dāng)?shù)臅r(shí)候會(huì)造成內(nèi)存泄露.
場(chǎng)景復(fù)現(xiàn)
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
UIAlertView* alertView = [[UIAlertView alloc] initWithTitle:@""
message:@"您的號(hào)在另一終端登錄"
delegate:self
cancelButtonTitle:@"確定"
otherButtonTitles:@"取消", nil];
[alertView show];
[self.navigationController popViewControllerAnimated:YES];
}
這段代碼看起來(lái)好像并沒(méi)什么問(wèn)題, 而且許多有開(kāi)發(fā)經(jīng)驗(yàn)的程序員也可能一直都是這樣寫(xiě)的.
問(wèn)題
當(dāng)當(dāng)前頁(yè)面被pop的時(shí)候, alertView仍然顯示, 這時(shí)候如果系統(tǒng)是iOS9以下的就會(huì)造成內(nèi)存泄露了.
但是同樣的代碼在, 在iOS9及以上的系統(tǒng)上是沒(méi)有內(nèi)存泄露的, 可能是系統(tǒng)的問(wèn)題吧, 那么我們來(lái)從以下幾個(gè)方面探究下, 到底問(wèn)題出現(xiàn)在哪里了.
1 UIAlertView的dealloc有沒(méi)有調(diào)到?
2 是不是delegate持有了UIAlertView造成沒(méi)釋放.
3 到底應(yīng)該如何避免內(nèi)存泄露.
解決方案
對(duì)于一些有經(jīng)驗(yàn)的開(kāi)發(fā)者估計(jì)直接跳到這里了吧, 好吧, 呵呵, 下面來(lái)一一解答上面的問(wèn)題.
1 UIAlertView的dealloc執(zhí)行了, 而且是Controller的dealloc執(zhí)行完才執(zhí)行的, 這個(gè)可以通過(guò)hook UIAlertView的dealloc來(lái)實(shí)現(xiàn), 如果hook dealloc可以參考樓主之前的一篇文章傳送門(mén). 這里就不詳細(xì)說(shuō)如何hook了, 黑魔法大家都懂的.
2 delegate沒(méi)有持有UIAlertView造成沒(méi)有釋放, 其實(shí)1里并不能完全說(shuō)明問(wèn)題, 因?yàn)榧词筕C dealloc了并不代表delegate一定被置空了, unsafe_unretain大家懂的, 那如果delegate沒(méi)置空就會(huì)在VC dealloc后繼續(xù)調(diào)用delegate里的方法, 這樣就可能會(huì)崩潰, 但是我們實(shí)現(xiàn)了UIAlertViewDelegate的- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
但是VC dealloc后這里并沒(méi)有來(lái)到. 也就是說(shuō), delegate并沒(méi)有持有UIAlertView.
3 那問(wèn)題到底出現(xiàn)在哪里了? 為什么iOS9 以上就沒(méi)內(nèi)存泄露呢, 好吧, 說(shuō)下自己的猜想吧, 可能iOS8系統(tǒng)上, UIAlertView的清理工作是在- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex中進(jìn)行的, 如果這里沒(méi)機(jī)會(huì)走到, 就可能會(huì)造成內(nèi)存泄露 , 那iOS9以上的呢, 我猜想應(yīng)該是系統(tǒng)hook了alertView這個(gè)實(shí)例的類(lèi)似didMoveToSuperview這樣的方法, 所以在alertView真實(shí)被關(guān)閉的時(shí)候會(huì)進(jìn)行清理工作.
但是我們嘗試hook willMoveToSuperview willMoveToWindow實(shí)際并沒(méi)有效果, 那為什么呢? 這就應(yīng)該猜想, alertView這個(gè)實(shí)例沒(méi)被添加到任何的window上面
通過(guò)打印下面的日志
NSLog(@"alertview window:%@", [alertView window]);
NSLog(@"keywindow:%@", [UIApplication sharedApplication].keyWindow);
會(huì)得到下面的結(jié)果
我們發(fā)現(xiàn), 原來(lái)alertView所在的window是keywindow, 但是遍歷keywindow上面的subview并沒(méi)發(fā)現(xiàn)我們的alertView
NSLog(@"alertView:%p", alertView);
for (UIView *subView in [UIApplication sharedApplication].keyWindow.subviews) {
NSLog(@"subView of keyWindow:%p:%@", subView, NSStringFromClass([subView class]));
}
到了這里估計(jì)很多讀者已經(jīng)懵逼了, WTF, 既然alertView的window是keywindow那就應(yīng)該是keywindow的subview啊! 分析到這里樓主也是懵逼了, 但是, 寡人不甘心啊, 繼續(xù)分析!
在[alertView show]前后同樣打印
UIWindow *keyWindow = [UIApplication sharedApplication].keyWindow;
NSLog(@"keywindow:%@", keyWindow);
結(jié)果!
這里發(fā)現(xiàn)可以window發(fā)生了變化, _UIAlertControllerShimPresenterWindow就是要顯示alertView的window, 但是在沒(méi)顯示的時(shí)候, 這個(gè)window不是keywindow, keywindow還是你在appdelegate里創(chuàng)建的那個(gè)self.window. 所以這里在show的時(shí)候應(yīng)該是發(fā)生了一次
makeKeyAndVisible類(lèi)似的操作, 這樣_UIAlertControllerShimPresenterWindow就變成keywindow了, 那可想而知關(guān)閉的時(shí)候必然是執(zhí)行了相反的操作, 把原來(lái)的keywindow又還原回去了. 那我想_UIAlertControllerShimPresenterWindow的清理工作必然是在alertView消失的時(shí)候調(diào)用的, 但并不一定是在代理執(zhí)行的時(shí)候. 好吧, 跑題了, 回到正文, 如果防止內(nèi)存泄露!
兩種解決方案
1 在VC dealloc的時(shí)候手動(dòng)調(diào)用dismissWithClickedButtonIndex, 當(dāng)然, 這個(gè)時(shí)候要把a(bǔ)lertView變成全局的.
2 另外開(kāi)一個(gè)常駐的service, 任何時(shí)候都可以控制alertView
對(duì)于方案1, 有時(shí)候可能不能滿足需求, 因?yàn)? 當(dāng)VC disappear的時(shí)候可能產(chǎn)品并不希望alertView消失, 而是等用戶手動(dòng)點(diǎn)擊的時(shí)候才消失, 但是這個(gè)時(shí)候代理方法已經(jīng)失效了, 點(diǎn)擊也無(wú)法進(jìn)行處理了. 而且可能會(huì)引起崩潰! 至于具體的崩潰下回再說(shuō).
對(duì)于方案2, 是比較好的解決方案, 但是, 要全局可能會(huì)有很多地方都彈alertView, 如果統(tǒng)一全局管理會(huì)有很多, 不是很好!
總結(jié):
綜上, 全局管理UIAlertView是一種比較靠譜的方式, 但是, 成本比較高, 所以, 除非必要的時(shí)候(產(chǎn)品極力要求的情況下), 當(dāng)在VC中創(chuàng)建的UIAlertView在VC被dealloc的時(shí)候直接關(guān)掉. 如果非要顯示的那種, 就做成全局的, 確保這個(gè)UIAlertView完全在自己的控制下.
