运行时AOP与编译时AOP

Question

这两种类型的AOP框架的优缺点是什么？我使用联合作为我的aop框架，但我想编译时aop框架(如postsharp )可能比运行时aop框架具有更好的性能？看起来，运行时aop框架使用反射来实现注入。

Answer 1

我不是.NET的人，但我知道AspectJ生态系统中的AOP世界，尤其是AspectJ和Spring。基本上有四种类型的方面编织：

• 源代码编织:将方面代码作为源代码注入应用程序源代码。这是某种预处理方法。目前Java世界中没有AOP框架使用这种方法，但是在AOP的早期有一些使用过这种方法。
  • 这样做的好处是在运行时完全独立于任何运行时libaries或特殊的AOP编译器，如果操作正确的话。
  • 缺点是源代码臃肿和编译前的预处理/代码生成步骤。调试时总是需要生成源代码。

​

• 编译时编织：方面代码由一个特殊的编译器编织到您的应用程序中。
  • 其优点是不需要方面编织的运行时开销。您唯一需要的是类路径上的一个小型运行时库。
  • 缺点是，如果要将方面组织到应用程序中，则不能将此决定推迟到运行时。但是，在处理调试或跟踪方面时，这只是一个问题，而这些方面并不总是需要的。另一个缺点是，这种方法只适用于您控制的代码，即您需要有源代码。它不适用于第三方的小伙伴。

​

• 二进制编织：方面代码在编译后而不是编译期间被编织到现有的类文件中。
  • 优点是，它也适用于第三方代码，您没有源代码。这种方法也可以与编译时编织混合使用。您还可以避免负载时编织的开销(请参见下面)。
  • 缺点类似于编译时编织:一旦一个方面被编织到代码中，就不能取消它的应用，而只是通过切入点(如if() )来停用它的执行。但这是相当有效率的。

​

• 加载时编织(LTW)：在VM/容器启动时尽早加载编织代理/库。它获得一个配置文件，其中包含描述应该将哪些方面编织到哪个类中的规则。
  • 优点是您可以动态地决定是否/什么编织。如果通过字节代码转换而不是通过动态代理或反射(见下文)完成，则生成的字节码与通过编译时或二进制编织创建的字节码同样有效。另一个优点是，就像二进制编织一样，它适用于您自己的代码以及第三方代码，只要编织代理能够“看到”它，即它发生在子类加载器中。
  • 缺点是在应用程序启动期间一次编织开销，因为编织是在类加载发生时完成的。

​

• 基于代理的LTW:这种特殊的LTW形式由Spring使用，而AspectJ执行前面列出的3种表单。它通过为方面目标创建动态代理(即子类或接口实现)来工作。
  • 除了您选择的框架(如Spring)碰巧支持它之外，我想不出有什么特别的优势。
  • 缺点是由于基于代理的方法限制了公共、非静态方法和运行时开销。它也不捕获内部方法调用，即当代理类调用其自己的方法之一时，因为代理没有捕获这些调用。不支持特殊类型的切入点，例如构造函数拦截、成员变量读/写访问以及更多的切入点，这使得这更像是一种"AOP lite“方法。但这对你的目的来说已经足够了。

​

通常，好的方面编译器(如AspectJ )会创建非常高效的字节码，并且在运行时不会严重依赖反射。如果您选择的方面框架确实依赖于反射，那么它可能不是很快。但是，它可能足够快，取决于您使用方面的程度。

也许我已经写得太多了，但我可以写得更多。这就是我现在停止的原因。此外，这种问题不太适合StackOverflow，因为它会引发哲学讨论和基于观点的辩论。我希望即使这样，我也能做到相当客观/公正。