如何在Android / iOS中释放组件

我在Android的表单上dynamic创build一个TEdit ：

 edit := TEdit.Create(Self); 

我想使用edit.Free释放它，但它仍然在表单上。

此代码在win32上正常工作，但在Android上失败。

不仅对于TEdit，而且对于使用Android或iOS的任何组件，似乎也是如此。

Answer 1

简答

在Delphi ARC编译器（当前为Android和iOS）下释放任何TComponent后代对象时，应遵循两条规则：

• 不pipe对象是否拥有者，使用DisposeOf都是强制的
• 在析构函数中，或者在调用DisposeOf后不久，引用不会超出范围的情况下，对象引用也应该设置nil （陷阱中的详细解释）

有DisposeOfAndNil方法可能会有吸引力，但ARC使得它比旧的FreeAndNil方法更复杂，我build议使用普通的DisposeOf - nil序列来避免其他问题：

 Component.DisposeOf; Component := nil; 

尽pipe在很多情况下，即使没有遵循上述规则，代码也会正常运行，但是这样的代码会非常脆弱，并且很容易被在看起来不相关的地方引入的其他代码所破坏。

DisposeOf在ARC内存pipe理的上下文中

DisposeOf打破ARC。 它违反了ARC的黄金法则。 任何对象引用都可以是有效的对象引用，也可以是零，并引入了第三种状态的“僵尸”对象引用。

任何试图理解ARC内存pipe理的人都应该看看DisposeOf ，就像解决Delphi特定的框架问题，而不是真正属于ARC本身的概念。

为什么在Delphi ARC编译器中存在DisposeOf？

TComponent类（及其所有后代）在devise时都考虑了手动内存pipe理。 它使用与ARC内存pipe理不兼容的通知机制，因为它依赖于在析构函数中打破强引用周期。 由于TComponent是Delphi框架所依赖的基类之一，它必须能够在ARC内存pipe理下正常运行。

除了Free Notification机制之外，Delphi框架中还有其他类似的devise，适合于手动内存pipe理，因为它们依赖于在析构函数中破坏强引用周期，但这些devise不适合ARC。

DisposeOf方法允许直接调用对象析构函数，并使这些遗留代码与ARC一起玩。

有一点必须注意这里。 任何使用或从TComponent inheritance的代码都会在正确的ARCpipe理环境中自动变成遗留代码 ，即使您今天编写代码 。

引用来自Allen Bauer的博客给予ARC一面

那么DisoseOf还能解决什么问题？ 在各种Delphi框架（包括VCL和FireMonkey）中，这是非常常见的，在一个类的构造函数和析构函数中放置活动的通知或列表pipe理代码。 TComponent的Owner / Owned模型就是这样一个devise的一个关键例子。 在这种情况下，现有的组件框架devise依赖于除了简单的“资源pipe理”在析构函数中发生的许多活动。

TComponent.Notification（）是这样一个关键的例子。 在这种情况下，“处理”组件的正确方法是使用DisposeOf。 TComponent衍生物通常不是一个暂时的实例，而是一个长寿命的对象，它也被其他组件实例的整个系统所包围，这些实例组成了诸如窗体，框架和数据模块之类的东西。 在这种情况下，使用DisposeOf是适当的。

DisposeOf如何工作

为了更好地理解在DisposeOf时究竟发生了什么，有必要知道Delphi对象销毁过程是如何工作的。

在ARC和非ARC的Delphi编译器中，涉及释放对象有三个不同的阶段

1. 调用destructor Destroy方法链
2. 清理对象pipe理的字段 – string，接口，dynamic数组（在ARC编译器下也包含普通的对象引用）
3. 释放堆中的对象内存

使用非ARC编译器释放对象

Component.Free – >立即执行阶段1 -> 2 -> 3

用ARC编译器释放对象

• Component.Free或Component := nil – >减less对象引用计数，然后是a）或b）

  • a）如果对象引用计数是0 – >立即执行阶段1 -> 2 -> 3
  • b）如果对象引用计数大于0，则不会发生任何其他事件

• 当对象引用计数达到0时， Component.DisposeOf – >阶段1阶段2和阶段3即时执行将稍后执行DisposeOf不会减less调用参考的引用计数。

TComponent通知系统

TComponent Free Notification机制通知已注册的组件正在释放特定的组件实例。 通知的组件可以在虚拟Notification方法中处理该通知，并确保它们清除所有可能被销毁的组件的引用。

在非ARC编译器的机制下，这种机制可以确保你最终没有悬挂着指向无效释放对象的指针，而且在ARC编译器中，清除对组件的引用将会减less引用计数并且破坏强引用周期。

Free Notification机制在DisposeOf析构函数中被触发，没有DisposeOf和直接执行析构函数，两个组件可以在整个应用程序生命周期中保持彼此的强引用。

FFreeNotifies包含对通知感兴趣的组件列表的列表被声明为FFreeNotifies: TList<TComponent> ，它将存储对任何注册组件的强引用。

因此，例如，如果您的TPopupMenu上有TEdit和TPopupMenu ，并指定该popup菜单来编辑PopupMenu属性，则编辑将在其FEditPopupMenu字段中对popup式菜单进行强引用，并且popup式菜单将在其FFreeNotifies列表中保留对编辑的强引用。 如果你想释放这两个组件中的任何一个，你必须调用DisposeOf ，否则它们将继续存在。

尽pipe您可以尝试手动跟踪这些连接，并在释放任何在实践中可能不那么容易的对象之前中断强引用周期。

下面的代码基本上泄露了ARC下的两个组件，因为它们将保持彼此的强引用，并且在过程完成之后，将不再有任何指向这两个组件之一的外部引用。 但是，如果将Menu.Freereplace为Menu.Free ，则将触发Free Notification机制并中断强参考周期。

 procedure ComponentLeak; var Edit: TEdit; Menu: TPopupMenu; begin Edit := TEdit.Create(nil); Menu := TPopupMenu.Create(nil); Edit.PopupMenu := Menu; // creating strong reference cycle Menu.Free; // Menu will not be released because Edit holds strong reference to it Edit.Free; // Edit will not be released because Menu holds strong reference to it end; 

DisposeOf的缺陷

除了打破ARC之外，这样做本身就是不好的，因为当你打破它的时候，你没有太多的用处，关于DisposeOf的实现方式，开发者应该注意的还有两个主要的问题。

1. DisposeOf不会减less调用参考 QP报告RSP-14681的 引用计数

 type TFoo = class(TObject) public a: TObject; end; var foo: TFoo; b: TObject; procedure DoDispose; var n: integer; begin b := TObject.Create; foo := TFoo.Create; foo.a := b; foo.DisposeOf; n := b.RefCount; // foo is still alive at this point, also keeping b.RefCount at 2 instead of 1 end; procedure DoFree; var n: integer; begin b := TObject.Create; foo := TFoo.Create; foo.a := b; foo.Free; n := b.RefCount; // b.RefCount is 1 here, as expected end; 

2. DisposeOf不清理实例内部pipe理的types引用 QP报告RSP-14682

 type TFoo = class(TObject) public s: string; d: array of byte; o: TObject; end; var foo1, foo2: TFoo; procedure DoSomething; var s: string; begin foo1 := TFoo.Create; foo1.s := 'test'; SetLength(foo1.d, 1); foo1.d[0] := 100; foo1.o := TObject.Create; foo2 := foo1; foo1.DisposeOf; foo1 := nil; s := IntToStr(foo2.o.RefCount) + ' ' + foo2.s + ' ' + IntToStr(foo2.d[0]); // output: 1 test 100 - all inner managed references are still alive here, // and will live until foo2 goes out of scope end; 

解决方法

 destructor TFoo.Destroy; begin s := ''; d := nil; o := nil; inherited; end; 

上述问题的综合影响可以以不同的方式performance出来。 从保留更多的分配内存不必要到难以捕捉错误，包含非拥有对象和接口引用的意外引用计数引起的错误。

由于DisposeOf不会减less调用引用的引用计数，所以在析构函数中DisposeOf这样的引用是非常重要的，否则整个对象层次结构可能会比需要的更长久地存活，甚至在整个应用程序生命周期中也会存在。

3. DisposeOf不能用来解决所有的循环引用

最后， DisposeOf问题是，只有当析构函数中有parsing它们的代码时，它才会中断循环引用 – 就像TComponent通知系统一样。

这些不被析构函数处理的周期应该在其中一个引用上使用[weak]和/或[unsafe]属性来打破。 这也是ARC的惯例。

DisposeOf不应该被用作快速修复所有引用循环（它从来没有被devise过的），因为它不会工作，滥用它会导致很难跟踪内存泄漏。

DisposeOf不会被破坏的简单循环示例是：

 type TChild = class; TParent = class(TObject) public var Child: TChild; end; TChild = class(TObject) public var Parent: TParent; constructor Create(AParent: TParent); end; constructor TChild.Create(AParent: TParent); begin inherited Create; Parent := AParent; end; var p: TParent; begin p := TParent.Create; p.Child := TChild.Create(p); p.DisposeOf; p := nil; end; 

上面的代码会泄漏子对象和父对象实例。 结合DisposeOf不清除内部托pipetypes（包括string）的事实，这些泄漏可能是巨大的，这取决于您在里面存储什么样的数据。 唯一的（适当的）打破这个循环的方法是改变TChild类的声明：

  TChild = class(TObject) public [weak] var Parent: TParent; constructor Create(AParent: TParent); end; 

Answer 2

在移动平台上，使用ARCpipe理生命周期。 对象只有在没有对象的引用时才被销毁。 你的对象有它的引用，特别是从它的父对象。

现在你可以使用DisposeOf强制对象被销毁。 更多细节在这里： http : //blogs.embarcadero.com/abauer/2013/06/14/38948

不过我怀疑，更好的解决scheme是删除对象的引用。 将其从容器中取出。 例如通过设置其父项为零。

Answer 3

我已经尝试了以上所有，并没有得到任何..我的最后一个select可能会导致一串仇恨评论，但唯一可能的解决scheme，为我工作到底..

我有一个滚动框，添加我自己制作的组件（从TPanel派生） – 大多数是50个。 我最好的解决办法是：

在创build第二层物品之前：

 Scrollbox1.align := TAlignLayout.none; Scrollbox1.width := 0; Scrollbox1.position.y := 5000; scrollbox1.visible := false; scrollbox1.name := 'Garbage' + inttostr(garbageitemscount); garbageitemscount := garbageitemscount + 1; scrollbox1 := TScrollbox.create(nil); scrollbox1.parent := ContainerPanel; Scrollbox1.align := TAlignLayout.client; 

当创build组件，他们的父母被设置为Scrollbox1再次..这给人的幻想，项目已经消失，实际上他们只是移动到屏幕上，直到应用程序closures，然后他们被Android释放..

我不能认为这种方法对大规模应用来说是完全可行的，但最终适合我的需求。对于那些也不知道该怎么做的人来说。 Component.DisposeOf – 崩溃的应用程序Component.Free – 无论如何

事实上，根据我的申请：

 Component := TComponent.create(ScrollBox1); Component.Parent := ScrollBox1; showmessage(inttostr(ScrollBox1.ChildrenCount)); //<-- This says 0, even tho 50 Components are present