FMX加入了ARC技术，对象创建后不用释放，FMX会帮你释放，是不是这样就不用关心对象的释放了呢，非也！
写简单的代码，这个功能也许很好用，但如果你写的是一个项目，那隐藏的坑无形中大大的增加开发难度，
开发人员需要更加小心注意对象的释放问题：你原来正常运作的代码，在FMX下，极有可能运作不正确，灵异现象熊出落。
原因很简单：对象的释放和你想象的不一样。怎么个不一样，（关于ARC）仔细看他Object类，就能窍的一二，这一二容我细细道来：
之前我们写代码，关系对象引用的清除以及释放一般都是在Detory方法中处理，所以代码是
obj:TObject.Create; obj.Free; Free中调用了Destory
如果使用接口Interface, 由于引用计数关系，引用计数FRefCount值为0时，编译器帮我们释放了对象（最终调用了Desotry)
某个Firemonkey设计者，在设计ARC时，大胆简单的使用了接口相同的技术（引用计数），所以释放的原理和原来的接口一样。但原来的Free代码和引用计数的这个设计是矛盾的，所以高明的设计者在FMX中，直接加上了一个补丁：如果使用了ARC,Free函数啥都不作。
这是一个简单的设计，同时这也是一个恶心的设计，这设计最大的危害：以前的代码直接就有了接口的原罪与缺点：对象相互引用时（你中有我，我中有心），一不小心对象的Desotry就得不到调用（因为二者的引用计数都无法顺序归0）。原来写的无害代码，极有可能会出现对象得不到释放。得不到释放会引来很多问题，因为不严谨，对象还可以接收处理，如果是窗体得不到释放，可能还在后面做着啥（这也是FMXApp容易闪退的一个常见原因）
这个时候，我大胆猜测，这个伟大的设计人员见招拆招，想出增加一个DisposeOf方法出来，你不是无法正常释放吗，好吧，把这个事分成二部分来看，一个对象的销毁Desotry，一个是对象内存的释放(FreeInstance)，完美！打个补丁，就可以解决你原来的问题:
你原来写的代码，写成obj:TObject.Create; obj.DisposeOf;就可以和原来效果基本一样了
为什么说是基本一样呢，至少你的Desotry函数能被顺利调用，不一样的地方就是，有可能这块内存得不到释放而已（Destory后，对象引用计数还是很容易不为0的）
好了，分析完ARC的前因后果之后，我们在写FMX代码的时候，就容易多了，至少知道坑在那里，下一章，我将总结出开发细节规范，只供参考. 如果有问题可以找13498714讨论