您好,登錄后才能下訂單哦!
前言:
最近都在折騰Sagit架框的內存釋放的問題,所以對這一塊有些心得。
對于新手,學到的文章都在教你用:typeof(self) __weak weakSelf = self
。
對于老手,可能早習慣了到處了WeakSelf了。
這次,就來學學,如何不用WeakSelf。
這里先設計一個TableBlock類:
@interface BlockTable : NSObject typedef void (^AddCellBlock)(); @property (nonatomic,copy)AddCellBlock addCell;@end
先這么簡單,一個BlockTable只有一個block屬性,然后輸出一段釋放的日志。
@interface BlockTable : NSObject typedef void (^AddCellBlock)(); @property (nonatomic,copy)AddCellBlock addCell;@end
接著,隨意找一個地方寫寫代碼:來new了一個BlockTable,并打印一下信息:
這時候它的引用數是1,并且出了Table relase 。
接著給addCell屬性賦一個值,并運行:
一個空的事件,里面并沒有引用到table,所以引用數還是1。
在block引用table,讓它產生循環引用,并運行:
我們看到:引用數變成了3,沒有輸出對象釋放信息了,為啥不是2呢?大大的問號!!
一個屬性賦值,為什么增強兩個引用計數?
接下來,把屬性設置為nil,運行看看:
設置為nil,還有2?
也正常釋放了?
為了證實自己對這個看起來就很明顯的猜想:重寫addCell的setter方法,不進行任何保存:
@implementation BlockTable -(void)setAddCell:(AddCellBlock)addCell { }
同時去掉置為nil的代碼:再運行看看:
計數器仍為2,而且也釋放了。
經過思考,出來了以下的結論:
1:塊的定義本身,就會造成1次引用,不過這次引用,在塊離開所在的函數時,釋放時,抵消掉引用數。
2:存檔塊的時候,會造成1次引用,而這個引用,是內存無法釋放的原因。
只要block的代碼只執行1次的,都可以任性的self或其它強引用。
事實上,我們寫的代碼,很多block的確只執行一次,不管是傳的時候就執行,還是傳完之后過段時間回調再執行。
認定只要執行1次的,就不需要WeakSelf,除非第三方框架的設計者造孽留坑,忘了在存檔block執行后補上block=nil這一刀。
繼續發揮想象力,既然存的時候,會增加一次引用,辣么,讓它不增加引用不就好了:
@implementation BlockTable -(void)setAddCell:(AddCellBlock)addCell { __weak AddCellBlock addCellWeak=addCell; _addCell=addCellWeak; }
我們先給這個block定義一個弱引用,然后再賦值給_addCell,運行看看:
哇草,成功了!計數器為2,正常釋放了,看來自己的想象力,還是可以的!!
接下來,我們補充完善一下代碼,增加一個reloadData方法,方法里調用事件。
完整的代碼如下:
@interface BlockTable : NSObject typedef void (^AddCellBlock)(); @property (nonatomic,copy)AddCellBlock addCell; -(void)reloadData; @end @implementation BlockTable -(void)setAddCell:(AddCellBlock)addCell { __weak AddCellBlock addCellWeak=addCell; _addCell=addCellWeak; } -(void)reloadData { if(self.addCell) { self.addCell(); self.addCell();//沒事來兩次,模擬table多次循環清加cell } } -(void)dealloc { NSLog(@"Table relase"); } @end
修改一下增加日志輸出,現在再執行一下看看:
一切看起來都相當完美,不需要引入第三,需要多次使用的,只是在存的時候,存個弱引用,就搞定了。
塊的定義,和使用的場景,必須在同一個函數。
說白了就是塊離開函數體就會消亡,所以要用要趕緊,且用且珍惜。
正常一個Table寫完代碼reloadData后,數據出來了。
但如果后面還跟有一個刷新重新加載的功能?
而這個重新調用reloadData的地方,可能跟block不在同一個函數,比如代碼像這樣:
-(void)start { BlockTable *table=[BlockTable new]; self.table=table;//搞到全局變量中 table.addCell = ^{ __weak typeof(table) this=table; NSLog(@"addCell call"); }; [table reloadData]; NSLog(@"table retain = %ld",CFGetRetainCount((__bridge CFTypeRef)(table))); } -(void)reflesh { [self.table reloadData]; }
給外面的類定義了一個table屬性,然后調用完start后再調用reflesh,運行,會怎樣呢?
出現了IOS上最可怕的EXC_BAD_ACCESS 野指針錯誤。
對于block離開函數后,消亡了容易理解,只是這里:
這什么是直接拋異常?哥不是作了判斷了么?
讓我們換種代碼寫法:
另外從上圖看:_addCell還是有值的。
為什么if(self.addCell)
判斷就直接死,if(_addCell)
卻沒死呢?
正常self.addCell
正常不是也return _addCell么?
這個問題,留給讓你們思考了。
最可怕的,還是下面的這段話:
OK,繼續發揮想象力,看看怎么避開野指針,同時還是實現上述的效果:
1:把block屬性從copy改成weak
@property (nonatomic,weak)AddCellBlock addCell;
2:賦值代碼手工copy:
-(void)setAddCell:(AddCellBlock)addCell { addCell=[addCell copy]; _addCell=addCell; //_addCell=[addCell copy];這樣簡寫是不行的,不明白為蝦米呢 // 原來是這樣寫的: // __weak AddCellBlock addCellWeak=addCell; // _addCell=addCellWeak ; }
再次運行,神奇的事情發生了:
流程還是很順,不會有野批針異常,Table也釋放了。
唯一的遺憾,就是跳出函數后,block不能再復用了:
對于默認傳進來的block(有三種形態:全局、棧、堆)
全局 copy 還是全局
堆 copy 還是堆
棧 copy 變成堆
說白了,copy只對類型是棧是才有效。
這是因為:棧的block,在執行完后出括號后,直接是銷毀對象。
如果有弱引用過去,會造成野指針。
而其它兩種類型,銷毀時,會將指針指向一個空指針。
addCell=[addCell copy] 和默認copy的屬性 _addCell=addCell 也是執行了copy操作。
執行后,addCell的類型就變成堆形態,這樣銷毀的時候,是空指針。
空指針:指向一個:人為創造的一個指針,它的名字叫空,有座空房子,里面什么也沒有。
野指針:就是指向的都不知哪去了,連空房子都木有。
弱引用的壞處,就是block出了函數,就不再可用這個block了。
那還能怎么辦呢?沒事,我還有想象力!!!!!
如果block可以重建呢?
比如:
1:將block轉成字符串存檔,適當時機還原回來重新賦值
2:將block序列化保存,適當時機還原回來?
3:runtime讀取block的__FuncPtr,存檔再動態創建?
偽代碼大體如下:
-(void)setAddCell:(AddCellBlock)addCell { addCell=[addCell copy]; _addCell=addCell; //_addCell=[addCell copy];這樣簡寫是不行的,不明白為蝦米呢 // 原來是這樣寫的: // __weak AddCellBlock addCellWeak=addCell; // _addCell=addCellWeak ; //存檔block的字符串 } -(void)reloadData { if(!_addCell) { //從存檔的block字符串還原block //_addCell=還原block } if(_addCell) { _addCell(); _addCell(); } }
那么就剩下兩個問題?
1:怎么把block存檔?
2:怎么將存檔數據還原成block。
對搞C#的來說,這些都家常便飯,oc這塊還不熟,有路過的朋友可順路給支支招!!
不過這個引入第三者,只是一個時機切入點,在這個時機觸發的時候,將其中的一方的引用設置為nil。
像Sagit框架的布局方面的時機,就選在導航回退等事件中處理。
不過這里需要一個小技巧:
在存檔block時,不一定要存在當前對象,也可以用一個統一的全局block管理起來。
這樣在業務處理時,根據業務情況,從全局block里來移除某些block即可。
具體取決于業務,所以這個就不展開了。
相信,一路看下,看懂了,后續的情況,基本上已經用不上WeakSelf這東西了,因為像一個block,其生命周期必須和持有者保持一致的,還是挺少的。
而這種少的情況,如果第10步解決了,基本就全都解決了,解決不了,還有11。
相信讀完此文,如果能完全理解,你就再也看不到block前WeakSelf這種,WeakSelf也沒有存在必要了。
最后,歡迎大伙關注IT連創業,雖然最近我都在折騰IOS,哈哈。
不過IOS基礎還是要打勞,后續產品改進起來才有質的飛躍。
好了,以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。