android - 如何在Android/iOS中释放组件

我在Android中的表单上动态创建TEdit：

edit := TEdit.Create(Self);

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

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

不仅对于TEdit，而且对于使用Android或iOS的任何组件，似乎都发生了同样的情况。

最佳答案

更新10.4
Delphi 10.4 Sydney跨所有平台统一了内存管理，并删除了ARC编译器。换句话说，所有平台现在都遵循与Windows平台相同的内存管理规则。
经典（非ARC）编译器中的DisposeOf与Free

经典编译器调用DisposeOf上的Free并在功能上相同
留下DisposeOf仅用于向后兼容，在使用Free的新代码（不必保持与ARC编译器的兼容性）中，首选
在现有代码中，没有将DisposeOf更改为Free


原始答案，对ARC编译器有效：
简短答案
在Delphi ARC编译器（当前为Android和iOS）下释放任何TComponent后代对象时，应遵循两个规则：

无论对象是否拥有所有者，都必须使用DisposeOf
在析构函数中或在调用DisposeOf之后不久引用未超出范围的情况下，对象引用也应设置为nil（在陷阱中有详细说明）

使用DisposeOfAndNil方法可能很吸引人，但是ARC使它比以前的FreeAndNil方法复杂得多，我建议使用普通的DisposeOf - nil序列来避免其他问题：

Component.DisposeOf;
Component := nil;

尽管在许多情况下，即使不遵守上述规则，代码也可以正常运行，但此类代码非常脆弱，很容易被看似无关的地方引入的其他代码破坏。
ARC内存管理中的DisposeOf
DisposeOf中断ARC。它违反了ARC的黄金法则。任何对象引用都可以是有效的对象引用，也可以是nil，并引入了第三种状态-放置了“僵尸”对象引用。
任何试图了解ARC内存管理的人都应该将DisposeOf看作是仅解决Delphi特定框架问题的附件，而不是真正属于ARC本身的概念。
为什么DisposeOf在Delphi ARC编译器中存在？
TComponent类（及其所有后代）在设计时考虑了手动内存管理。它使用与ARC内存管理不兼容的通知机制，因为它依赖于破坏析构函数中的强引用周期。由于TComponent是Delphi框架所依赖的基本类之一，因此它必须能够在ARC内存管理下正常运行。
除了Free Notification机制之外，Delphi框架中还有其他类似的设计适用于手动内存管理，因为它们依赖于破坏析构函数中的强引用周期，但是这些设计不适合ARC。
DisposeOf方法允许直接调用对象析构函数，并使这些旧代码可与ARC一起播放。
这里必须注意一件事。在当前的ARC管理下，即使您今天编写，使用或继承自TComponent的任何代码也会自动成为旧代码。
引用Allen Bauer的博客Give in to the ARC side

那么DisoseOf还可以解决什么呢？这是很普遍的
Delphi框架（包括VCL和FireMonkey），用于激活
构造函数中的通知或列表管理代码，以及
类的析构函数。 TComponent的所有者/拥有模型是关键
这种设计的例子。在这种情况下，现有组件
框架设计依赖于许多活动，而不是简单的“资源”
管理”发生在析构函数中。
TComponent.Notification（）是此类事情的一个关键示例。在这
在这种情况下，“处置”组件的正确方法是使用DisposeOf。一个
TComponent导数通常不是瞬态实例，而是
寿命更长的物体，也被整个系统包围
组成表单，框架之类的其他组件实例
和数据模块。在这种情况下，使用DisposeOf是合适的。

DisposeOf如何工作
为了更好地理解调用DisposeOf时会发生什么，有必要知道Delphi对象销毁过程是如何工作的。
在ARC和非ARC Delphi编译器中释放对象涉及三个不同的阶段

调用destructor Destroy方法链
清理对象管理的字段-字符串，接口，动态数组（也在包含普通对象引用的ARC编译器下）
从堆释放对象内存

使用非ARC编译器发布对象
Component.Free->立即执行阶段1 -> 2 -> 3
使用ARC编译器发布对象

Component.Free或Component := nil->减少对象引用计数，后跟a）或b）

a）如果对象引用计数为0->立即执行阶段1 -> 2 -> 3
b）如果对象引用计数大于0，则什么也没有发生


Component.DisposeOf->阶段1的立即执行，对象引用计数达到0时，稍后将执行阶段2和3。DisposeOf不会减少调用引用的引用计数。


TComponent通知系统
TComponent Free Notification机制通知注册的组件特定的组件实例正在释放。被通知的组件可以在虚拟Notification方法中处理该通知，并确保清除了它们可能在销毁的组件上保留的所有引用。
在非ARC编译器下，该机制可确保您不会导致指向无效对象的悬空指针的释放-在ARC编译器下，清除销毁组件的引用将减少其引用计数并破坏强引用周期。
Free Notification机制是在TComponent析构函数中触发的，没有DisposeOf且没有析构函数的直接执行，两个组件可以相互保持强引用，从而在整个应用程序生存期内保持生命。
包含对通知感兴趣的组件列表的FFreeNotifies列表被声明为FFreeNotifies: TList<TComponent>，它将存储对任何已注册组件的强引用。
因此，例如，如果您在表单上具有TEdit和TPopupMenu并将该弹出菜单分配给Edit的PopupMenu属性，则edit将在其FEditPopupMenu字段中保留对弹出菜单的强引用，而弹出菜单将保留强引用在其FFreeNotifies列表中进行编辑。如果要释放这两个组件中的任何一个，则必须在它们上调用DisposeOf，否则它们将继续存在。
尽管您可以尝试手动跟踪那些连接并打破强大的参考周期，然后再释放在实践中可能不那么容易的那些对象。
后面的代码基本上会泄漏ARC下的两个组件，因为它们相互之间拥有强引用，并且在过程完成之后，您将不再具有指向这些组件中任何一个的外部引用。但是，如果将Menu.Free替换为Menu.DisposeOf，则会触发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之外，它本身也是不好的，因为当破坏ARC时，它并没有太多用处，开发人员应意识到DisposeOf的实现方式还有两个主要问题。
1. DisposeOf不会减少调用引用QP report 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不会清除实例内部托管类型引用QP report 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;

上述问题的综合影响可能以不同的方式体现出来。从保留不必要的分配内存到难以捕获由所包含的非拥有对象和接口引用的错误，意外引用计数引起的错误。
由于DisposeOf不会减少调用引用的引用计数，因此重要的是，在析构函数中使用nil这样的引用非常重要，否则整个对象层次结构的存活时间可能比所需的更长，甚至在整个应用程序生命周期中也是如此。
3. DisposeOf不能用于解析所有循环引用
最后但并非最不重要的问题是DisposeOf的问题是，只有在析构函数中有代码可以解析循环引用时，它才会中断循环引用-就像TComponent通知系统所做的那样。
此类未由析构函数处理的循环应使用其中一个引用中的[weak]和/或[unsafe]属性来中断。这也是ARC的首选做法。
DisposeOf不应用作打破所有参考周期（从未设计过的参考周期）的快速解决方案，因为它无法工作，滥用它可能导致难以跟踪的内存泄漏。
不会被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不能清除内部托管类型（包括字符串）的事实，这些泄漏可能会很大，具体取决于您存储在内部的数据类型。打破该周期的唯一（正确）方法是更改​​TChild类声明：

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