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討論。