三、Ac…

中Activator.CreateInstance方法是开发人员通过反射创建实例的最常用方法之一。

它允许在运行时创建类的新实例即使事先不知道它们的具体类型。

此方法属于类System.Activator通常用于需要动态实例化的场景。

的主要目的Activator.CreateInstance是动态创建类的实例

因此如果您在编译时可以访问该类型那么您可能没有充分的理由使用它Activator.CreateInstance在要创建的对象类型直到运行时才知道的情况下例如在加载插件或使用动态加载的程序集时它特别有用。

它消除了对硬编码显式构造函数的需求并提供了对象创建的灵活性。

1、使用

Activator.CreateInstance与普通对象实例相比使用有几个优点

允许后期绑定对象创建这在对象类型在运行时可能发生变化的情况下很有用。

switch

但是使用时也需要考虑一些缺点Activator.CreateInstance

由于运行时解析类型涉及额外的步骤因此与直接实例化相比使用反射的性能开销可能更高。

通常依赖于公共无参数构造函数的存在。

否则您需要始终知道要传入哪些参数

由于没有编译时检查签名兼容性因此在修改目标类型时容易出现错误。

2、使用

以下代码示例演示了如何使用Activator.CreateInstance动态创建实例

Example

Activator.CreateInstance(objectType);在示例

中我们使用typeof获取Type代表已知类的对象MyClass。

然后我们使用Activator.CreateInstance创建

Example

Activator.CreateInstance(unknownType);在示例

中我们有一个由字符串表示的未知类型typeName。

我们使用根据提供的类型名称Type.GetType获取对象。

最后用于创建动态确定类型的新实例。

TypeActivator.CreateInstance

我们再看一个例子其中我们可以为构造函数传递参数——同样假设我们知道签名因为我们无法在编译时通过这种方法证明它

Example

Activator.CreateInstance(unknownType,new[]{Hello

World!,

提供的一种可用方法允许我们动态创建类型的实例。

它提供了一种灵活的方法可以通过利用手头类型的信息在运行时实例化对象。

出于这些原因它在如何利用它来创建对象实例方面非常相似。

1、使用

Type.InvokeMember与普通对象实例相比使用以下方法具有一些普遍的优点

允许后期绑定对象创建这在对象类型在运行时可能发生变化的情况下很有用。

switch

等一下……这不就是我们上面看到的那个列表吗Activator.CreateInstance没错。

所以我们就简短地介绍一下这部分。

除非我们开始研究性能否则我们不会看到任何大的差异——也许在某些非常特殊的边缘情况下。

但总的来说两者都提供了非常全面的方法来动态实例化对象而

InvokeMember

下面是一个示例代码片段演示了如何Type.InvokeMember动态创建类型实例

Example

.InvokeMember(null,BindingFlags.CreateInstance,null,null,null);在上面的例子中我们首先获取代表类“MyClass”的

Type

创建该类的实例并将其分配给“instance”变量。

这使我们能够动态创建“MyClass”的对象而无需明确指定类名。

而在编译时不知道类的情况下执行此操作与以前非常相似。

但这部分与

InvokeMember

objectType.InvokeMember(null,BindingFlags.CreateInstance,null,null,null);最后如果我们需要传递一些构造函数参数那么我们也可以这样做

Example

objectType.InvokeMember(null,BindingFlags.CreateInstance,null,null,new[]{Hello

World!,});三、Activator.CreateInstance

Type.InvokeMember

我想加入主构造函数因为我知道这个特性会招致很多人的反对——最好还是获取一些数据吧以下是我们将要实例化的类供参考

public

ClassicStringParameterClass(string

value){_value

PrimaryConstructorStringParameterClass(string

_value)

}至于基准测试让我们看看我们将要运行的以下类。

请记住我使用它Activator.CreateInstance作为基线是因为我想比较Activator.CreateInstancevs

Type.InvokeMember—

typeof(ParameterlessClass);}[Benchmark]public

void

ParameterlessClass();}[Benchmark(Baseline

true)]public

Activator_Create_Instance(){var

instance

Activator.CreateInstance(_type!);}[Benchmark]public

void

_type!.InvokeMember(null,BindingFlags.CreateInstance,null,null,null);}

}[ShortRunJob]

ClassicStringParameterClassBenchmarks

{private

typeof(ClassicStringParameterClass);}[Benchmark]public

void

ClassicStringParameterClass(Hello

true)]public

Activator_Create_Instance(){var

instance

Activator.CreateInstance(_type!,new[]{Hello

void

_type!.InvokeMember(null,BindingFlags.CreateInstance,null,null,new[]{Hello

World!,});}

PrimaryConstructorStringParameterClassBenchmarks

{private

typeof(PrimaryConstructorStringParameterClass);}[Benchmark]public

void

PrimaryConstructorStringParameterClass(Hello

true)]public

Activator_Create_Instance(){var

instance

Activator.CreateInstance(_type!,new[]{Hello

void

_type!.InvokeMember(null,BindingFlags.CreateInstance,null,null,new[]{Hello

World!,});}

当我们将这两种反射方法进行对比时获胜者是…视情况而定。

在最常见的一种情况下我会说有一个非常明显的赢家但对于其他情况它们非常接近。

但请务必阅读结论因为这不是故事的结局。

Type.InvokeMember

这里明显胜出Activator.CreateInstance几乎高出一个数量级。

如果你的构造函数没有任何参数那么最好的选择就是这个。

接下来让我们检查Activator.CreateInstance一下Type.InvokeMember接受单个字符串参数的构造函数

Type.InvokeMember

这两款车基本上势均力敌尽管Activator.CreateInstance略胜一筹但差距几乎可以忽略不计。

要查看的最后一个场景是主构造函数在本例中主构造函数接受一个字符串参数

Type.InvokeMember

获胜者Type.InvokeMember但只领先一点点。

非常有趣的是这与我们在之前的基准测试中看到的结果相反

Type.InvokeMember

当谈到Activator.CreateInstancevs的性能结果时Type.InvokeMember无参数构造函数的情况明显胜出Activator.CreateInstance。

但是当我们开始需要参数或使用带参数的主构造函数时它开始均衡甚至有利于Type.InvokeMember。