前前言
相信大家在入門 AOP 時，常常被繁多的術語、方法和框架繞暈。AOP 好像有點耳熟？Javaseopt 是個什么？Javassist 又是啥？Dexposed、APT 也是 AOP？本篇將輔助你快速理清概念，掌握 AOP 思想，找到最適合自己業務場景的 AOP 方法。
前言
上文 也談代碼 —— 重構兩年前的代碼 中，我們提到最佳的系統架構由模塊化的關注面領域組成，每個關注面均用純 Java 對象實現。不同的領域之間用最不具有侵害性的「方面」或「類方面」工具整合起來。
反思自己的項目，有很多模塊沒有做到恰當地切分關注面，往往在業務邏輯中耦合了業務埋點、權限申請、登陸狀態的判斷、對不可預知異常 try-catch 和一些持久化操作。
雖說保證代碼最簡單化和可運行化很有必要，但我們還是可以嘗試小范圍的重構。就如「代碼整潔之道」中所說：通過方面式的手段切分關注面的威力不可低估，假如你能用 POJO 編寫應用程序的領域邏輯，在代碼層面與架構關注面分離開，就有可能真正地用測試來驅動架構。
這里的切分關注面的思想就是 AOP。
一、AOP即面向切向編程
AOP 是 Aspect Oriented Programming 的縮寫，譯為面向切向編程。用我們最常用的 OOP 來對比理解：
縱向關系 OOP，橫向角度 AOP
舉個小例子：
設計一個日志打印模塊。按 OOP 思想，我們會設計一個打印日志 LogUtils 類，然后在需要打印的地方引用即可。
public class ClassA {
private void initView() {
LogUtils.d(TAG, "onInitView");
}
}
public class ClassB {
private void onDataComplete(Bean bean) {
LogUtils.d(TAG, bean.attribute);
}
}
public class ClassC {
private void onError() {
LogUtils.e(TAG, "onError");
}
}
看起來沒有任何問題是吧？
但是這個類是橫跨并嵌入眾多模塊里的，在各個模塊里分散得很厲害，到處都能見到。從對象組織角度來講，我們一般采用的分類方法都是使用類似生物學分類的方法，以「繼承」關系為主線，我們稱之為縱向，也就是 OOP。設計時只使用 OOP思想可能會帶來兩個問題：
對象設計的時候一般都是縱向思維，如果這個時候考慮這些不同類對象的共性，不僅會增加設計的難度和復雜性，還會造成類的接口過多而難以維護（共性越多，意味著接口契約越多）。
需要對現有的對象 動態增加 某種行為或責任時非常困難。
而AOP就可以很好地解決以上的問題，怎么做到的？除了這種縱向分類之外，我們從橫向的角度去觀察這些對象，無需再去到處調用 LogUtils 了，聲明哪些地方需要打印日志，這個地方就是一個切面，AOP 會在適當的時機為你把打印語句插進切面。
// 只需要聲明哪些方法需要打印 log，打印什么內容
public class ClassA {
@Log(msg = "onInitView")
private void initView() {
}
}
public class ClassB {
@Log(msg = "bean.attribute")
private void onDataComplete(Bean bean) {
}
}
public class ClassC {
@Log(msg = "onError")
private void onError() {
}
}
如果說 OOP 是把問題劃分到單個模塊的話，那么 AOP 就是把涉及到眾多模塊的某一類問題進行統一管理。AOP的目標是把這些功能集中起來，放到一個統一的地方來控制和管理。利用 AOP 思想，這樣對業務邏輯的各個部分進行了隔離，從而降低業務邏輯各部分之間的耦合，提高程序的可重用性，提高開發效率。
OOP 與 AOP 的區別
面向目標不同：簡單來說 OOP 是面向名詞領域，AOP 面向動詞領域。
思想結構不同：OOP 是縱向結構，AOP 是橫向結構。
注重方面不同：OOP 注重業務邏輯單元的劃分，AOP 偏重業務處理過程中的某個步驟或階段。
OOP 與 AOP 的聯系
兩者之間是一個相互補充和完善的關系。
二、應用場景
那AOP既然這么有用，除了上面提到的打印日志場景，還有沒有其他用處呢？
當然有！
只要系統的業務模塊都需要引用通用模塊，就可以使用AOP。以下是一些常用的業務場景：
1. 參數校驗和判空
系統之間在進行接口調用時，往往是有入參傳遞的，入參是接口業務邏輯實現的先決條件，有時入參的缺失或錯誤會導致業務邏輯的異常，大量的異常捕獲無疑增加了接口實現的復雜度，也讓代碼顯得雍腫冗長，因此提前對入參進行驗證是有必要的，可以提前處理入參數據的異常，并封裝好異常轉化成結果對象返回給調用方，也讓業務邏輯解耦變得獨立。
2. Android API23+的權限控制
避免到處都是申請權限和處理權限的代碼
3. 無痕埋點
4. 安全控制
比如全局的登錄狀態流程控制。
5. 日志記錄
6. 事件防抖
防止View被連續點擊觸發多次事件
7. 性能統計
檢測方法耗時其實已經有一些現成的工具，比如 trace view。痛點是這些工具使用起來都比較麻煩，效率低下，而且無法針對某一個塊代碼或者某個指定的sdk進行查看方法耗時。可以采用 AOP 思想對每個方法做一個切點，在執行之后打印方法耗時。
8. 事務處理
聲明方法，為特定方法加上事務，指定情況下（比如拋出異常）回滾事務
9. 異常處理
替代防御性的 try-Catch。
10. 緩存
緩存某方法的返回值，下次執行該方法時，直接從緩存里獲取。
11. 軟件破解
使用 Hook 修改軟件的驗證類的判斷邏輯。
12. 熱修復
AOP 可以讓我們在執行一個方法的前插入另一個方法，運用這個思路，我們可以把有 bug 的方法替換成我們下發的新方法。
三、AOP 方法
本篇為入門篇，重在理解 AOP 思想和應用，輔助你快速進行 AOP 方法選型，所以 AOP 方法這塊暫不會深入原理和術語。
Android AOP 常用的方法有 JNI HOOK 和 靜態織入。
動態織入 Hook 方式
在運行期，目標類加載后，為接口動態生成代理類，將切面植入到代理類中。相對于靜態AOP更加靈活。但切入的關注點需要實現接口。對系統有一點性能影響。
Dexposed
Xposed
epic
在 native 層修改 java method 對應的 native 指針
動態字節碼生成
- Cglib + Dexmaker
Cglib 是一個強大的,高性能的 Code 生成類庫， 原理是在運行期間目標字節碼加載后，通過字節碼技術為一個類創建子類，并在子類中采用方法攔截的技術攔截所有父類方法的調用，順勢織入橫切邏輯。由于是通過子類來代理父類，因此不能代理被 final 字段修飾的方法。
但是 Cglib 有一個很致命的缺點：底層是采用著名的 ASM 字節碼生成框架，使用字節碼技術生成代理類，也就是通過操作字節碼來生成的新的 .class 文件，而我們在 Android 中加載的是優化后的 .dex 文件，也就是說我們需要可以動態生成 .dex 文件代理類，因此 Cglib 不能在 Android 中直接使用。有大神根據 Dexmaker 框架（dex代碼生成工具）來仿照 Cglib 庫動態生成 .dex 文件，實現了類似于 Cglib 的 AOP 的功能。詳細的用法可參考：將cglib動態代理思想帶入Android開發
靜態織入方式
- 在編譯期織入，切面直接以字節碼的形式編譯到目標字節碼文件中，，這要求使用特殊的 Java 編譯器。
- 在類裝載期織入，這要求使用特殊的類裝載器。
靜態織入對系統無性能影響。但靈活性不夠。
APT
AspectJ
ASM
Javassist
DexMaker
ASMDEX
這么多方法？有什么區別？
方法作用期比對
一圖勝千言
AOP 是思想，上面的方法其實都是工具，只不過是插入時機和方式不同。
同：都可以織入邏輯，都體現了 AOP 思想
異：作用的時機不一樣，且適用的注解的類型不一樣。
方法優缺點、難點比對
| 方法 | 作用時機 | 操作對象 | 優點 | 缺點 | 為了上手，我需要掌握什么？ |
|---|---|---|---|---|---|
| APT | 編譯期：還未編譯為 class 時 | .java 文件 | 1. 可以織入所有類；2. 編譯期代理，減少運行時消耗 | 1. 需要使用 apt 編譯器編譯；2. 需要手動拼接代理的代碼（可以使用 Javapoet 彌補）；3. 生成大量代理類 | 設計模式和解耦思想的靈活應用 |
| AspectJ | 編譯期、加載時 | .java 文件 | 功能強大，除了 hook 之外，還可以為目標類添加變量，接口。也有抽象，繼承等各種更高級的玩法。 | 1. 不夠輕量級；2. 定義的切點依賴編程語言，無法兼容Lambda語法；3. 無法織入第三方庫；4. 會有一些兼容性問題，如：D8、Gradle 4.x等 | 復雜的語法，但掌握幾個簡單的，就能實現絕大多數場景 |
| Javassist | 編譯期：class 還未編譯為 dex 時或運行時 | class 字節碼 | 1. 減少了生成子類的開銷；2. 直接操作修改編譯后的字節碼，直接繞過了java編譯器，所以可以做很多突破限制的事情，例如，跨 dex 引用，解決熱修復中 CLASS_ISPREVERIFIED 問題。 | 運行時加入切面邏輯，產生性能開銷。 | 1. 自定義 Gradle 插件；2. 掌握groovy 語言 |
| ASM | 編譯期或運行期字節碼注入 | class 字節碼 | 小巧輕便、性能好，效率比Javassist高 | 學習成本高 | 需要熟悉字節碼語法，ASM 通過樹這種數據結構來表示復雜的字節碼結構，并利用 Push 模型來對樹進行遍歷，在遍歷過程中對字節碼進行修改。 |
| ASMDEX | 編譯期和加載時：轉化為 .dex 后 | Dex 字節碼，創建 class 文件 | 可以織入所有類 | 學習成本高 | 需要對 class 文件比較熟悉，編寫過程復雜。 |
| DexMaker | 同ASMDEX | Dex 字節碼，創建 dex 文件 | 同ASMDEX | 同ASMDEX | 同ASMDEX |
| Cglib | 運行期生成子類攔截方法 | 字節碼 | 沒有接口也可以織入 | 1. 不能代理被final字段修飾的方法；2. 需要和 dexmaker 結合使用 | -- |
| xposed | 運行期hook | -- | 能hook自己應用進程的方法，能hook其他應用的方法，能hook系統的方法 | 依賴三方包的支持，兼容性差，手機需要root | -- |
| dexposed | 運行期hook | -- | 只能hook自己應用進程的方法，但無需root | 1. 依賴三方包的支持，兼容性差；2. 只能支持 Dalvik 虛擬機 | -- |
| epic | 運行期hook | -- | 支持 Dalvik 和 Art 虛擬機 | 只適合在開發調試中使用，碎片化嚴重有兼容性問題 | -- |
四、常用的 AOP 方法介紹
業務中常用的 AOP 方式為靜態織入，接下來詳細介紹靜態織入中最常用的三種方式：APT、AspectJ、Javassist。
1. APT
APT （Annotation Processing Tool ）即注解處理器，是一種處理注解的工具，確切的說它是 javac 的一個工具，它用來在編譯時掃描和處理注解。注解處理器以 Java 代碼（ 或者編譯過的字節碼）作為輸入，生成 .java 文件作為輸出。簡單來說就是在編譯期，通過注解生成 .java 文件。使用的 Annotation 類型是 SOURCE。
代表框架：DataBinding、Dagger2、ButterKnife、EventBus3、DBFlow、AndroidAnnotation
為什么這些框架注解實現 AOP 要使用 APT？
目前 Android 注解解析框架主要有兩種實現方法，一種是運行期通過反射去解析當前類，注入相應要運行的方法。另一種是在編譯期生成類的代理類，在運行期直接調用代理類的代理方法，APT 指的是后者。
如果不使用APT基于注解動態生成 java 代碼，那么就需要在運行時使用反射或者動態代理，比如大名鼎鼎的 butterknife 之前就是在運行時反射處理注解，為我們實例化控件并添加事件，然而這種方法很大的一個缺點就是用了反射，導致 app 性能下降。所以后面 butterknife 改為 apt 的方式，可以留意到，butterknife 會在編譯期間生成一個 XXX_ViewBinding.java。雖然 APT 增加了代碼量，但是不再需要用反射，也就無損性能。
APT 的缺點改進
性能問題解決了，又帶來新的問題了。我們在處理注解或元數據文件的時候，往往有自動生成源代碼的需要。難道我們要手動拼接源代碼嗎？不不不，這不符合代碼的優雅，JavaPoet 這個神器就是來解決這個問題的。
JavaPoet
JavaPoet 是 square 推出的開源 java 代碼生成框架，提供 Java Api 生成 .java 源文件。這個框架功能非常有用，我們可以很方便的使用它根據注解、數據庫模式、協議格式等來對應生成代碼。通過這種自動化生成代碼的方式，可以讓我們用更加簡潔優雅的方式要替代繁瑣冗雜的重復工作。本質上就是用建造者模式來替代手工拼寫源文件。
JavaPoet詳細用法可參考：javapoet——讓你從重復無聊的代碼中解放出來
2. AspectJ
目前最好、最方便、最火的 AOP 實現方式當屬 AspectJ，它是一種幾乎和 Java 完全一樣的語言，而且完全兼容 Java。
但是在 Android 上集成 AspectJ 是比較復雜的。
我們需要使用 andorid-library gradle 插件在編譯時做一些 hook。使用 AspectJ 的編譯器（ajc，一個java編譯器的擴展）對所有受 aspect 影響的類進行織入。在 gradle 的編譯 task 中增加一些額外配置，使之能正確編譯運行。等等等等……
有很多庫幫助我們完成這些工作，可以方便快捷接入 AspectJ。
AspectJ 框架選型
| 庫 | 大小 | 兼容性 | 缺點 | 備注 |
|---|---|---|---|---|
| Hugo | 131kb | -- | 不支持AAR或JAR切入 | -- |
| gradle-android-aspectj-plugin | -- | -- | 無法兼容databinding，不支持AAR或JAR切入 | 該庫已經棄用 |
| AspectJx（推薦） | 44kb | 會和有transform功能的插件沖突，如：retroLambda | 在前兩者基礎上擴展支持AAR, JAR及Kotlin的應用 | 僅支持annotation的方式，不支持 *.aj 文件的編譯 |
3. Javassist
代表框架：熱修復框架HotFix 、Savior（InstantRun）
Javassist 是一個編輯字節碼的框架，作用是修改編譯后的 class 字節碼，ASM也有這個功能，不過 Javassist 的 Java 風格 API 要比 ASM 更容易上手。
既然是修改編譯后的 class 字節碼，首先我們得知道什么時候編譯完成，并且我們要在 .class文件被轉為 .dex 文件之前去做修改。在 Gradle Transfrom 這個 api 出來之前，想要監聽項目被打包成 .dex 的時機，就必須自定義一個 Gradle Task，插入到 predex 或者 dex 之前，在這個自定義的 Task 中使用 Javassist 或者 ASM 對 class 字節碼進行操作。而 Transform 更為方便，我們不再需要插入到某個Task前面。Tranfrom 有自己的執行時機，一經注冊便會自動添加到 Task 執行序列中，且正好是 class 被打包成dex之前。
五、總結
AOP 重在理解這種思想：
- 先考慮要在什么期間插入代碼，選用合適的 AOP 方法；
- 找準切入點也就是代碼可注入的點，比如一個方法的調用處或者方法內部；
- 接著考慮怎么過濾方法，找到注入點的描述，比如注入到所有onClick方法：call(* view.onClick(..))；
- 接著要考慮以怎樣的方式處理代碼，是在代碼執行前？執行后？還是包裹代碼？還是替換目標代碼？
任何的技術都需要有業務依托和落地，想要一步步實現 AOP 應用落地？請戳 一文應用 AOP | 最全選型考量 + 邊剖析經典開源庫邊實踐，美滋滋。
六、還想了解更多？
博文推薦
書籍推薦
我是 FeelsChaotic，一個寫得了代碼 p 得了圖，剪得了視頻畫得了畫的程序媛，致力于追求代碼優雅、架構設計和 T 型成長。
歡迎關注 FeelsChaotic 的簡書和掘金，如果我的文章對你哪怕有一點點幫助，歡迎 ??！你的鼓勵是我寫作的最大動力！
最最重要的，請給出你的建議或意見，有錯誤請多多指正！
