介紹

如今有多個可用的AOP庫，這些元件需要回答一系列的問題：

• 是否與我現有的應用相容？
• 我在哪實現AOP？
• 整合到我的應用是否很快？
• 效能開銷是多少？

本文中，我們將會著重回答這些問題，並介紹兩款Java最流行的AOP框架：Spring AOP 和 AspectJ。

AOP概念

在我們開始之前，讓我們對術語和核心概念做一個快速，高水平的回顧：

• Aspect切面：一個分佈在應用程式中多個位置的標準程式碼/功能，通常與實際的業務邏輯（例如事務管理）不同。 每個切面都側重於一個特定的橫切功能。
• Joinpoint連線點：這是程式執行中的特定點，如方法執行，構呼叫造函式或欄位賦值等。
• Advice通知：在一個連線點中，切面採取的行動
• Pointcut切點：一個匹配連線點的正則表示式。 每當任何連線點匹配一個切入點時，就執行與該切入點相關聯的指定通知。
• Weaving織入：連結切面和目標物件來建立一個通知物件的過程。

Spring AOP and AspectJ

現在，一起來討論Spring AOP and AspectJ，跨越多指標，如能力和目標、織入方式、內部結構、連線點和簡單性。

Capabilities and Goals

簡而言之，Spring AOP和AspectJ有不同的目標。
Spring AOP旨在通過Spring IoC提供一個簡單的AOP實現，以解決編碼人員面臨的最常出現的問題。這並不是完整的AOP解決方案，它只能用於Spring容器管理的beans。

另一方面，AspectJ是最原始的AOP實現技術，提供了玩這個的AOP解決方案。AspectJ更為健壯，相對於Spring AOP也顯得更為複雜。值得注意的是，AspectJ能夠被應用於所有的領域物件。

Weaving

AspectJ and Spring AOP使用了不同的織入方式，這影響了他們在效能和易用性方面的行為。
AspectJ使用了三種不同型別的織入：

1. 編譯時織入：AspectJ編譯器同時載入我們切面的原始碼和我們的應用程式，並生成一個織入後的類檔案作為輸出。
2. 編譯後織入：這就是所熟悉的二進位制織入。它被用來編織現有的類檔案和JAR檔案與我們的切面。
3. 載入時織入：這和之前的二進位制編織完全一樣，所不同的是織入會被延後，直到類載入器將類載入到JVM。

AspectJ使用的是編譯期和類載入時進行織入，Spring AOP利用的是執行時織入。

執行時織入，在使用目標物件的代理執行應用程式時，編譯這些切面（使用JDK動態代理或者CGLIB代理）。

springaop-process

Internal Structure and Application

Spring AOP 是一個基於代理的AOP框架。這意味著，要實現目標物件的切面，將會建立目標物件的代理類。這可以通過下面兩種方式實現：

• JDK動態代理：Spring AOP的首選方法。 每當目標物件實現一個介面時，就會使用JDK動態代理。
• CGLIB代理：如果目標物件沒有實現介面，則可以使用CGLIB代理。

關於Spring AOP可以通過官網瞭解更多。
另一方面，AspectJ在執行時不做任何事情，類和切面是直接編譯的。因此，不同於Spring AOP，他不需要任何設計模式。織入切面到程式碼中，它引入了自己的編譯期，稱為AspectJ compiler (ajc)。通過它，我們編譯應用程式，然後通過提供一個小的（<100K）執行時庫執行它。

Joinpoints

在上一小節，我們介紹了Spring AOP基於代理模式。因此，它需要目標類的子類，並相應的應用橫切關注點。但是也伴隨著侷限性，我們不能跨越“final”的類來應用橫切關注點（或切面），因為它們不能被覆蓋，從而導致執行時異常。

同樣地，也不能應用於靜態和final的方法。由於不能覆寫，Spring的切面不能應用於他們。因此，Spring AOP由於這些限制，只支援執行方法的連線點。
然而，AspectJ在執行前將橫切關注點直接織入實際的程式碼中。 與Spring AOP不同，它不需要繼承目標物件，因此也支援其他許多連線點。AspectJ支援如下的連線點：

連線點支援

同樣值得注意的是，在Spring AOP中，切面不適用於同一個類中呼叫的方法。這很顯然，當我們在同一個類中呼叫一個方法時，我們並沒有呼叫Spring AOP提供的代理的方法。如果我們需要這個功能，可以在不同的beans中定義一個獨立的方法，或者使用AspectJ。

Simplicity

Spring AOP顯然更加簡單，因為它沒有引入任何額外的編譯期或在編譯期織入。它使用了執行期織入的方式，因此是無縫整合我們通常的構建過程。儘管看起來很簡單，Spring AOP只作用於Spring管理的beans 。

然而，使用AspectJ，我們需要引入AJC編譯器，重新打包所有庫（除非我們切換到編譯後或載入時織入）。這種方式相對於前一種，更加複雜，因為它引入了我們需要與IDE或構建工具整合的AspectJ Java工具（包括編譯器（ajc），偵錯程式（ajdb），文件生成器（ajdoc），程式結構瀏覽器（ajbrowser））。

Performance

考慮到效能問題，編譯時織入比執行時織入快很多。Spring AOP是基於代理的框架，因此應用執行時會有目標類的代理物件生成。另外，每個切面還有一些方法呼叫，這會對效能造成影響。

AspectJ不同於Spring AOP，是在應用執行前織入切面到程式碼中，沒有額外的執行時開銷。

由於以上原因，AspectJ經過測試大概8到35倍快於Spring AOP。benchmarks

對比

這個快速表總結了Spring AOP和AspectJ之間的主要區別：

對比

選擇合適的框架

如果我們分析本節所有的論點，我們就會開始明白，沒有絕對的一個框架比另一個框架更好。
簡而言之，選擇很大程度上取決我們的需求：

• 框架：如果應用程式不使用Spring框架，那麼我們別無選擇，只能放棄使用Spring AOP的想法，因為它無法管理任何超出spring容器範圍的東西。 但是，如果我們的應用程式完全是使用Spring框架建立的，那麼我們可以使用Spring AOP，因為它很直接便於學習和應用。
• 靈活性：鑑於有限的連線點支援，Spring AOP並不是一個完整的AOP解決方案，但它解決了程式設計師面臨的最常見的問題。 如果我們想要深入挖掘並利用AOP達到其最大能力，並希望獲得來自各種可用連線點的支援，那麼AspectJ是最佳選擇。
• 效能：如果我們使用有限的切面，那麼效能差異很小。 但是，有時候應用程式有數萬個切面的情況。 在這種情況下，我們不希望使用執行時織入，所以最好選擇AspectJ。 已知AspectJ比Spring AOP快8到35倍。
• 共同優點：這兩個框架是完全相容的。 我們可以隨時利用Spring AOP，並且仍然使用AspectJ來獲得前者不支援的連線點。

總結

在這篇文章中，我們分析了Spring AOP和AspectJ比較關鍵的幾個方面。我們比較了AOP和AOP兩種方法的靈活性，以及它們與我們的應用程式的匹配程度。