ios android 基本组件,如何在Android / iOS中释放组件

简短答案

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

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)的博客引用进入ARC方面

那么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->立即执行stage 1，stages，2并且3将在对象引用计数达到0时稍后执行。DisposeOf不会减少调用引用的引用计数。

TComponent通知系统

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

在非ARC编译器下，该机制可确保您不会导致指向无效对象(已释放对象)的悬空指针结束；在ARC编译器下，清除对销毁组件的引用将减少其引用计数并破坏强引用周期。

Free Notification在TComponent析构函数中触发了机制，并且在没有DisposeOf直接执行析构函数的情况下，两个组件可以相互保持强引用，从而在整个应用程序生存期内保持自身的生命。

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

因此，例如，如果您在表单上有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报告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报告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;