iOS APP內(nèi)存泄露問題解決(二)

一、問題描述

ViewController不釋放,會導(dǎo)致很多問題,我舉幾個我遇到的例子。

  1. 我做的是一個企業(yè)即時通訊APP,我做了一個群公告功能,發(fā)布群公告時會發(fā)送@all消息。某天,我做完了群公告,發(fā)了一個群公告試試,結(jié)果,消息群發(fā)了,發(fā)到了好幾個聊天會話中去了。因為chattingViewController沒有釋放掉,發(fā)送@all消息的通知,那些沒有被釋放掉的chattingViewController都收到了,都執(zhí)行了發(fā)送@all消息的動作,所以導(dǎo)致很多會話都發(fā)送了@all消息。
  2. 我做一個踢出登錄的功能,退到登錄頁面的時候,之前的主界面都沒有被釋放,踢出登錄會發(fā)一個通知,顯示一個alert:你被踢出登錄。多次被踢出,就會創(chuàng)建多個主界面,多個主界面都會收到這個通知,于是就顯示了多個alertView。
  3. NSTimer,NSTimer會對它的target持有強引用,如果NSTimer不釋放掉,就會一直持有它的target的強引用,會一直都釋放不掉,造成內(nèi)存泄露。

二、解決方法

怎么知道ViewController有沒有被釋放,有一個方法就是可以通過看ViewController有沒有執(zhí)行dealloc方法。
大概有幾個地方,比較容易引起內(nèi)存泄露

  1. 循環(huán)引用;最多的就是block引起的循環(huán)引用。
    (1)某個類將block作為自己的屬性變量,然后該類在block的方法體里面又使用了該類本身;相互持有,導(dǎo)致都釋放不了。

     代碼例子:
     [self.tableView mas_makeConstraints:^(MASConstraintMaker *make) {
     make.left.right.equalTo(self.view);
     make.top.equalTo(self.navigationBar.mas_bottom);
     make.bottom.equalTo(self.view);
     }];
     修改為:
     __weak typeof(self) weakSelf = self;
     塊內(nèi)的self,換成weakSelf就行了。
     block不是self的屬性或者變量時,在block內(nèi)使用self不會循環(huán)引用;
     
     (2)如果塊是一個單例持有的,塊內(nèi)又使用了ViewController這個類,會引起循環(huán)引用。     
     例子:
     [[OutsidePacketsSchedule shareInstance] sendParameters:dict requestCmd:@"addCustomEmoReq" responseCmd:@"addCustomEmoRsp" complete:^(id response, NSError *error) {
     if(!error){
         [weakSelf.view setToast:@"添加自定義表情成功"];
     }
     }];
     上例中的單例持有的代碼塊中要用弱引用,原因是:單例不會被釋放掉,它會一直持有block,導(dǎo)致該block所在的ViewController釋放不掉。
     (3)如果是方法中的參數(shù)是block,不會造成循環(huán)引用,因為方法中的block是位于棧內(nèi)存的,方法返回后,block將會無效。
    
  2. NSTimer和CADisplayLink這種;
    + (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti
    target:(id)aTarget
    selector:(SEL)aSelector
    userInfo:(nullable id)userInfo
    repeats:(BOOL)yesOrN{

    }
    從文檔中方法的定義上可以看到,NSTimer是會強引用它的target的,像其他的delegate一般都是weak的,所以這里比較特殊。
    NSTimer Class Reference是這樣對target描述的:
    The object to which to send the message specified by aSelector when the timer fires. The timer maintains a strong reference to target until it (the timer) is invalidated.
    NSTimer Class Reference還指出: Runloop會強引用timer,因為如果一個timer是循環(huán)的,如果沒被強引用,那么在函數(shù)返回后,則會被銷毀,就不能循環(huán)地通知持有的target。所以NSTimer是被放到Runloop中執(zhí)行的。
    如果我們不調(diào)用invalidate timer,runloop就會一直持有timer,而timer也一直持有ViewController,這樣就會造成內(nèi)存泄露。
    
    解決這類問題的方法就是:在不需要NSTimer的時候,及時調(diào)用[self.timer invalidate]。千萬不要在dealloc方法中調(diào)用,因為NSTimer強引用self,所以不會執(zhí)行dealloc方法。
    
  3. delegate一般是weak的情況分析;
    這里我遇到的情況,在我的第一篇博客里面有寫到,感興趣的可以去看一下。

  4. 對象之間的循環(huán)引用:例子:兩個ViewController都需要使用對方,這個時候可以用@class

  5. 是我解決ViewController不釋放的時候遇到的一個個例問題,當(dāng)時把ViewController里的每行代碼都分析了,強引用的地方都解決了,還是不執(zhí)行dealloc方法,查了好久,請教了好幾個同事,最后,發(fā)現(xiàn),竟然是這個ViewController沒有開啟ARC,不知道是被那個隊友給關(guān)閉了,哭瞎=。=

三、最后的建議

上文中我主要是根據(jù)自己在項目中遇到的問題,及如何解決的,來描述的。不是很詳細深入,這里建議多看一下官方文檔,一般的問題都可以通過閱讀官方文檔來解決的。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容