运行时 AOP 与编译时 AOP

Question

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

Answer 1

我不是 .NET 人，但我了解 Java 生态系统中的 AOP 世界，尤其是 AspectJ 和 Spring AOP。基本上有4种方面编织：

• 源代码编织：方面代码作为源代码语句注入到您的应用程序源代码中。这是某种预处理器方法。现在 Java 世界中没有任何 AOP 框架使用这种方法，但在 AOP 的早期曾经有一些。
  • 如果操作正确，优势将是在运行期间完全独立于任何运行时库或特殊 AOP 编译器。
  • 缺点是源代码臃肿，编译前有预处理/代码生成步骤。您总是需要生成的源代码进行调试。
• 编译时编织：方面代码由特殊的编译器编织到您的应用程序中。
  • 优点是方面编织没有运行时开销。您唯一需要的是类路径上的小型运行时库。
  • 缺点是，如果您想将方面编织到应用程序中，则不能将决定推迟到运行时。但这只是在处理并非一直需要的调试或跟踪方面时才会出现的问题。另一个缺点是这种方法仅适用于您控制的代码，即您需要拥有源代码。它不适用于 3rd 方库。
• 二进制编织： 方面代码在编译后而不是在编译期间被编织到现有的类文件中。
  • 优点是它也适用于您没有源代码的第 3 方代码。这种方法也可以与编译时编织混合使用。您还可以避免加载时编织的开销（见下文）。
  • 缺点类似于编译时编织：一旦将切面编织到代码中，就无法取消应用切面，只能通过诸如if() 之类的切入点停用其执行。但这可能非常有效。
• 加载时织入 (LTW)： 织入代理/库会在您的 VM/容器启动时提前加载。它获取一个配置文件，其中包含描述哪些方面应该被编织到哪些类中的规则。
  • 优点是您可以动态决定是否编织/编织什么。如果通过字节码转换而不是通过动态代理或反射（见下文）完成，则生成的字节码与通过编译时或二进制编织创建的字节码同样有效。另一个优点是，就像二进制编织一样，它适用于您自己的代码以及第 3 方代码，只要编织代理可以“看到”它，即它发生在子类加载器中。
  • 缺点是应用程序启动期间的一次性编织开销，因为编织是在类加载发生时完成的。
• 基于代理的 LTW： 这种特殊的 LTW 形式由 Spring AOP 使用，而 AspectJ 使用上面列出的前 3 种形式。它通过为方面目标创建动态代理（即子类或接口实现）来工作。
  • 除了您选择的框架（例如 Spring）恰好支持它之外，我想不出任何特殊优势。
  • 由于基于代理的方法，缺点是对公共、非静态方法和运行时开销的限制。它也不捕获内部方法调用，即当代理类调用它自己的方法之一时，因为这些调用未被代理捕获。不支持特殊类型的切入点，例如构造函数拦截、成员变量读/写访问等等，这使得这更像是一种“AOP lite”方法。但这足以满足您的目的。

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

可能我已经写太多了，但我可以写更多。这就是我现在停下来的原因。此外，这类问题不太适合 StackOverflow，因为它可能导致哲学讨论和基于意见的辩论。我希望我能做到相当客观/公正。