LEO原創13498714
FMX加入了ARC技術,物件建立後不用釋放,FMX會幫你釋放,是不是這樣就不用關心物件的釋放了呢,非也!
寫簡單的程式碼,這個功能也許很好用,但如果你寫的是一個專案,那隱藏的坑無形中大大的增加開發難度,
開發人員需要更加小心注意物件的釋放問題:你原來正常運作的程式碼,在FMX下,極有可能運作不正確,靈異現象熊出落。
原因很簡單:物件的釋放和你想象的不一樣。怎麼個不一樣,(關於ARC)仔細看他Object類,就能竅的一二,這一二容我細細道來:
之前我們寫程式碼,關係物件引用的清除以及釋放一般都是在Detory事件中處理,所以程式碼是
obj:TObject.Create; obj.Free; Free中呼叫了Destory
如果使用介面Interface, 由於引用計數關係,引用計數FRefCount值為0時,編譯器幫我們釋放了物件(最終呼叫了Desotry)
某個Firemonkey設計者,在設計ARC時,大膽簡單的使用了介面相同的技術(引用計數),所以釋放的原理和原來的介面一樣。但原來的Free程式碼和引用計數的這個設計是矛盾的,所以高明的設計者在FMX中,直接加上了一個補丁:如果使用了ARC,Free函式啥都不作。
LEO原創13498714
這是一個簡單的設計,同時這也是一個噁心的設計,這設計最大的危害:以前的程式碼直接就有了介面的原罪與缺點:物件相互引用時(你中有我,我中有心),一不小心物件的Desotry就得不到呼叫(因為二者的引用計數都無法順序歸0)。原來寫的無害程式碼,極有可能會出現物件得不到釋放。得不到釋放會引來很多問題,因為不嚴謹,物件還可以接收處理,如果是窗體得不到釋放,可能還在後面做著啥(這也是FMXApp容易閃退的一個常見原因)
這個時候,我大膽猜測,這個偉大的設計人員見招拆招,想出增加一個DisposeOf方法出來,你不是無法正常釋放嗎,好吧,把這個事分成二部分來看,一個物件的銷燬Desotry,一個是物件記憶體的釋放(FreeInstance),完美!打個補丁,就可以解決你原來的問題,你原來寫的程式碼,寫成obj:TObject.Create; obj.DisposeOf;就可以和原來效果基本一樣了,為什麼說是基本一樣呢,至少你的Desotry函式能被順利呼叫,不一樣的地方就是,有可能這塊記憶體得不到釋放而已(Destory後,物件引用計數還是很容易不為0的)
好了,分析完ARC的前因後果之後,我們在寫FMX程式碼的時候,就容易多了,至少知道坑在那裡,下一章,我將總結出開發細節規範,只供參考. 如果有問題可以找13498714討論。
---------------------
作者:Im_Leo
來源:CSDN
原文:https://blog.csdn.net/wingleo/article/details/88842590
版權宣告:本文為博主原創文章,轉載請附上博文連結!