基于TInterfacedClass的Delphi插件框架的内存管理

Question

对于服务器端插件框架，我想实现公开一个返回类引用（TInterfacedClass）的 RegisterPlugin 方法的 DLL。

然后，主机应用程序创建此类的实例，并且实例将在主机线程的上下文中运行。 （这与 Jedi VCL 插件框架不同，后者在 DLL 或 BPL 中实例化插件并将实例返回到主机。）

到目前为止，第一次测试没有显示任何问题。但是，内存管理是否存在我应该注意的隐藏问题？由于我在这个项目中使用 Delphi 2009，FastMM4 是默认的内存管理器。

这是插件 DLL 项目的草图：

library ExamplePlugin;
uses
  ...
type
  TPluginOne = class(TInterfacedObject, ...)
  ...
  end;

function RegisterPlugin: TInterfacedClass; stdcall;
begin
  Result := TPluginOne;
end;

exports
  RegisterPlugin;

{ TPluginOne }
// ... plugin class implementation

begin  
end.

Answer 1

内存管理器没有问题，因为 FastMM 作为 EXE 和 DLL 之间的共享内存管理器工作。但我真的对在 DLL 和 EXE 之间传递纯对象或（最糟糕的）元类的概念感到不舒服。问题是，EXE 中的 TInterfacedObject 与 DLL 中的 TInterfacedObject 不一样！当然，它们可能看起来完全相同，但事实并非如此！如果您升级了 EXE 或任何 DLL 的 Delphi 版本，您将需要重建所有内容（从而失去从实现插件框架中获得的任何优势）。

一个更便携的解决方案是返回一个“工厂接口”，类似于：

IFactoryInterface = interface
[GUId-goes-here]
  function MakeWhateverInterfaceYouNeed: IUnknownDerivate
end;

然后导出具有此签名的函数：

function RegisterPlugin: IFactoryInterface;

Answer 2

您的代码不完整，但从您所包含的内容来看，存在一个明显的缺陷。

您似乎正在从 DLL 导出一个类 (TInterfacedClass)。当客户尝试使用不同版本的 Delphi 来使用您的类时，这会导致问题。更重要的是，如果他们想用不同的语言编写插件，这会让他们束手无策。

就我个人而言，我会选择基于 COM 的接口，它允许插件作者用任何语言创建插件。事实上，COM 的发明正是为了解决这个问题。

如果您愿意为插件和主机应用程序使用相同的编译器，并且您更喜欢将类公开给 COM 接口，那么您需要确保所有释放都是使用与分配内存相同的内存管理器执行的。最简单的方法是使用 ShareMem，这样你就安全了。

更新

Cosmin 在评论中指出了跨模块边界导出类的另一个缺陷。这基本上是你不应该做的事情。 COM 就是为此目的而设计的，它仍然应该是您的首选。 Delphi 接口与 COM 兼容，因此您可以获得二进制互操作性的相同好处，而无需创建服务器、注册 CLSID 等。

我认为您的插件应该如下所示：

library ExamplePlugin;

type
  TPluginOne = class(TInterfacedObject, IPlugin)
  [GUID]
  public
    constructor Create(const Host: THostApp);
  end;

function RegisterPlugin(const Host: IHostApp): IPlugin; stdcall;
begin
  Result := TPluginOne.Create(Host);
end;

exports
  RegisterPlugin;

begin  
end.