介紹
如今有多個可用的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使用了三種不同類型的織入：
- 編譯時織入：AspectJ編譯器同時加載我們切面的源代碼和我們的應用程序，並生成一個織入後的類文件作爲輸出。
- 編譯後織入：這就是所熟悉的二進制織入。它被用來編織現有的類文件和JAR文件與我們的切面。
- 加載時織入：這和之前的二進制編織完全一樣，所不同的是織入會被延後，直到類加載器將類加載到JVM。
更多關於AspectJ的信息，請見head on over to this article。
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來獲得前者不支持的連接點。
總結