iOS容易造成循引用的場景

timer就是乙個能在從現在開始的未來的某乙個時刻又或者週期性的執行我們指定的方法的物件

nstimer執行的必要條件：對應執行緒的runloop要開啟，mode要對應

下面看timer的迴圈引用：

-(void)setblock:(testblock)block
- (id)init
return
self;
}- (void)handletimer:(id)sender 
- (void)cleartimer 
- (void)dealloc

如圖，我們寫這樣的乙個類，當我們初始化這個類就會有乙個timer開啟，然後當我們去釋放當前類的時候，是不會走dealloc函式的，因為timer會對當前類count +1，然後timer持有self，self持有timer就造成了死迴圈，造成記憶體洩露，而打破迴圈引用的方法就是invalidate。

當方法還沒有執行的時候，要返回父檢視釋放當前檢視的時候，self的計數沒有減少到0，而導致無法呼叫dealloc方法，出現了記憶體洩露

解決方案：

1.[nsobject cancelpreviousperformrequestswithtarget:self]

2.[nsobjectcancelpreviousperformrequestswithtarget:self selector:@selector(method1:)object:nil]

q&a：

1.向nsnotificationcenter中addobserver後，有沒有對這個物件進行引用計數加1操作？

2.在乙個已經釋放的nsobject類以及乙個viewcontroller類發通知結果會怎樣？

3. [[nsnotificationcenter defaultcenter] removeobserver: name: object:nil];

和. [[nsnotificationcenter defaultcenter] removeobserver：] 如何選取

我們首先解決第2個問題，在乙個已經釋放的nsobject類以及乙個viewcontroller類發通知 nsobject會crash，會提示乙個位址錯誤，說明通知只是記住了他的位址指標，技術並沒有加1，而對viewcontroller類發通知不會發生crash，為什麼會這樣？

那就是：viewcontroller在dealloc的時候會呼叫 [[nsnotificationcenter defaultcenter] removeobserver：self] ；

而我們怎麼去驗證呢，那就是給nsnotificationcenter加乙個類別，重寫removeobserver：self方法，就會很容易的發現，你還會發現在dealloc的時候會移除系統的通知，實際上蘋果就是這麼做的。

最後乙個問題：那麼如何讓抉擇？就是在除了dealloc以外的地方都不要呼叫removeobserver：self 而是使用單個移除的方法[[nsnotificationcenter defaultcenter] removeobserver: name: object:nil];

@try
@catch(n***ception *exception) 
@finally

然後我們就可以發揮了：

@try 
@catch (n***ception *exception) 
@finally

上述**會不會有異常？？？

會，當然會！， [object dosmmaythrowexception];//異常函式直接就會跳過 [object release]; ，產生記憶體洩露

iOS容易造成循引用的場景

iOS容易造成迴圈引用的三種場景

容易造成core的原因

引用容易犯的錯誤。

iOS容易造成循引用的場景

iOS容易造成迴圈引用的三種場景

容易造成core的原因

引用容易犯的錯誤。

相關推薦