AOP系列思維導圖

前前言

相信大家在入門 AOP 時，常常被繁多的術(shù)語、方法和框架繞暈。AOP 好像有點耳熟？Javaseopt 是個什么？Javassist 又是啥？Dexposed、APT 也是 AOP？本篇將輔助你快速理清概念，掌握 AOP 思想，找到最適合自己業(yè)務場景的 AOP 方法。

前言

上文 也談代碼 —— 重構(gòu)兩年前的代碼 中，我們提到最佳的系統(tǒng)架構(gòu)由模塊化的關(guān)注面領(lǐng)域組成，每個關(guān)注面均用純 Java 對象實現(xiàn)。不同的領(lǐng)域之間用最不具有侵害性的「方面」或「類方面」工具整合起來。

反思自己的項目，有很多模塊沒有做到恰當?shù)厍蟹株P(guān)注面，往往在業(yè)務邏輯中耦合了業(yè)務埋點、權(quán)限申請、登陸狀態(tài)的判斷、對不可預知異常 try-catch 和一些持久化操作。

雖說保證代碼最簡單化和可運行化很有必要，但我們還是可以嘗試小范圍的重構(gòu)。就如「代碼整潔之道」中所說：通過方面式的手段切分關(guān)注面的威力不可低估，假如你能用 POJO 編寫應用程序的領(lǐng)域邏輯，在代碼層面與架構(gòu)關(guān)注面分離開，就有可能真正地用測試來驅(qū)動架構(gòu)。

這里的切分關(guān)注面的思想就是 AOP。

一、AOP即面向切向編程

AOP 是 Aspect Oriented Programming 的縮寫，譯為面向切向編程。用我們最常用的 OOP 來對比理解：

縱向關(guān)系 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");
    }
}

看起來沒有任何問題是吧？

但是這個類是橫跨并嵌入眾多模塊里的，在各個模塊里分散得很厲害，到處都能見到。從對象組織角度來講，我們一般采用的分類方法都是使用類似生物學分類的方法，以「繼承」關(guān)系為主線，我們稱之為縱向，也就是 OOP。設計時只使用 OOP思想可能會帶來兩個問題：

1. 對象設計的時候一般都是縱向思維，如果這個時候考慮這些不同類對象的共性，不僅會增加設計的難度和復雜性，還會造成類的接口過多而難以維護（共性越多，意味著接口契約越多）。

2. 需要對現(xiàn)有的對象 動態(tài)增加 某種行為或責任時非常困難。

而AOP就可以很好地解決以上的問題，怎么做到的？除了這種縱向分類之外，我們從橫向的角度去觀察這些對象，無需再去到處調(diào)用 LogUtils 了，聲明哪些地方需要打印日志，這個地方就是一個切面，AOP 會在適當?shù)臅r機為你把打印語句插進切面。

// 只需要聲明哪些方法需要打印 log，打印什么內(nèi)容
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 就是把涉及到眾多模塊的某一類問題進行統(tǒng)一管理。AOP的目標是把這些功能集中起來，放到一個統(tǒng)一的地方來控制和管理。利用 AOP 思想，這樣對業(yè)務邏輯的各個部分進行了隔離，從而降低業(yè)務邏輯各部分之間的耦合，提高程序的可重用性，提高開發(fā)效率。

OOP 與 AOP 的區(qū)別

1. 面向目標不同：簡單來說 OOP 是面向名詞領(lǐng)域，AOP 面向動詞領(lǐng)域。

2. 思想結(jié)構(gòu)不同：OOP 是縱向結(jié)構(gòu)，AOP 是橫向結(jié)構(gòu)。

3. 注重方面不同：OOP 注重業(yè)務邏輯單元的劃分，AOP 偏重業(yè)務處理過程中的某個步驟或階段。

OOP 與 AOP 的聯(lián)系

兩者之間是一個相互補充和完善的關(guān)系。

二、應用場景

那AOP既然這么有用，除了上面提到的打印日志場景，還有沒有其他用處呢？

當然有！

只要系統(tǒng)的業(yè)務模塊都需要引用通用模塊，就可以使用AOP。以下是一些常用的業(yè)務場景：

1. 參數(shù)校驗和判空

系統(tǒng)之間在進行接口調(diào)用時，往往是有入?yún)鬟f的，入?yún)⑹墙涌跇I(yè)務邏輯實現(xiàn)的先決條件，有時入?yún)⒌娜笔Щ蝈e誤會導致業(yè)務邏輯的異常，大量的異常捕獲無疑增加了接口實現(xiàn)的復雜度，也讓代碼顯得雍腫冗長，因此提前對入?yún)⑦M行驗證是有必要的，可以提前處理入?yún)?shù)據(jù)的異常，并封裝好異常轉(zhuǎn)化成結(jié)果對象返回給調(diào)用方，也讓業(yè)務邏輯解耦變得獨立。

2. Android API23+的權(quán)限控制

避免到處都是申請權(quán)限和處理權(quán)限的代碼

3. 無痕埋點

4. 安全控制

比如全局的登錄狀態(tài)流程控制。

5. 日志記錄

6. 事件防抖

防止View被連續(xù)點擊觸發(fā)多次事件

7. 性能統(tǒng)計

檢測方法耗時其實已經(jīng)有一些現(xiàn)成的工具，比如 trace view。痛點是這些工具使用起來都比較麻煩，效率低下，而且無法針對某一個塊代碼或者某個指定的sdk進行查看方法耗時?？梢圆捎?AOP 思想對每個方法做一個切點，在執(zhí)行之后打印方法耗時。

8. 事務處理

聲明方法，為特定方法加上事務，指定情況下（比如拋出異常）回滾事務

9. 異常處理

替代防御性的 try-Catch。

10. 緩存

緩存某方法的返回值，下次執(zhí)行該方法時，直接從緩存里獲取。

11. 軟件破解

使用 Hook 修改軟件的驗證類的判斷邏輯。

12. 熱修復

AOP 可以讓我們在執(zhí)行一個方法的前插入另一個方法，運用這個思路，我們可以把有 bug 的方法替換成我們下發(fā)的新方法。

三、AOP 方法

本篇為入門篇，重在理解 AOP 思想和應用，輔助你快速進行 AOP 方法選型，所以 AOP 方法這塊暫不會深入原理和術(shù)語。

Android AOP 常用的方法有 JNI HOOK 和 靜態(tài)織入。

動態(tài)織入 Hook 方式

在運行期，目標類加載后，為接口動態(tài)生成代理類，將切面植入到代理類中。相對于靜態(tài)AOP更加靈活。但切入的關(guān)注點需要實現(xiàn)接口。對系統(tǒng)有一點性能影響。

1. Dexposed

2. Xposed

3. epic
   在 native 層修改 java method 對應的 native 指針

動態(tài)字節(jié)碼生成

1. Cglib + Dexmaker

Cglib 是一個強大的,高性能的 Code 生成類庫， 原理是在運行期間目標字節(jié)碼加載后，通過字節(jié)碼技術(shù)為一個類創(chuàng)建子類，并在子類中采用方法攔截的技術(shù)攔截所有父類方法的調(diào)用，順勢織入橫切邏輯。由于是通過子類來代理父類，因此不能代理被 final 字段修飾的方法。

但是 Cglib 有一個很致命的缺點：底層是采用著名的 ASM 字節(jié)碼生成框架，使用字節(jié)碼技術(shù)生成代理類，也就是通過操作字節(jié)碼來生成的新的 .class 文件，而我們在 Android 中加載的是優(yōu)化后的 .dex 文件，也就是說我們需要可以動態(tài)生成 .dex 文件代理類，因此 Cglib 不能在 Android 中直接使用。有大神根據(jù) Dexmaker 框架（dex代碼生成工具）來仿照 Cglib 庫動態(tài)生成 .dex 文件，實現(xiàn)了類似于 Cglib 的 AOP 的功能。詳細的用法可參考：將cglib動態(tài)代理思想帶入Android開發(fā)

靜態(tài)織入方式

• 在編譯期織入，切面直接以字節(jié)碼的形式編譯到目標字節(jié)碼文件中，，這要求使用特殊的 Java 編譯器。
• 在類裝載期織入，這要求使用特殊的類裝載器。

靜態(tài)織入對系統(tǒng)無性能影響。但靈活性不夠。

1. APT

2. AspectJ

3. ASM

4. Javassist

5. DexMaker

6. ASMDEX

這么多方法？有什么區(qū)別？

方法作用期比對

一圖勝千言

AOP 方法作用時期比對.png

AOP 是思想，上面的方法其實都是工具，只不過是插入時機和方式不同。

同：都可以織入邏輯，都體現(xiàn)了 AOP 思想
異：作用的時機不一樣，且適用的注解的類型不一樣。

方法優(yōu)缺點、難點比對

四、常用的 AOP 方法介紹

業(yè)務中常用的 AOP 方式為靜態(tài)織入，接下來詳細介紹靜態(tài)織入中最常用的三種方式：APT、AspectJ、Javassist。

1. APT

APT （Annotation Processing Tool ）即注解處理器，是一種處理注解的工具，確切的說它是 javac 的一個工具，它用來在編譯時掃描和處理注解。注解處理器以 Java 代碼（ 或者編譯過的字節(jié)碼）作為輸入，生成 .java 文件作為輸出。簡單來說就是在編譯期，通過注解生成 .java 文件。使用的 Annotation 類型是 SOURCE。

代表框架：DataBinding、Dagger2、ButterKnife、EventBus3、DBFlow、AndroidAnnotation

為什么這些框架注解實現(xiàn) AOP 要使用 APT？

目前 Android 注解解析框架主要有兩種實現(xiàn)方法，一種是運行期通過反射去解析當前類，注入相應要運行的方法。另一種是在編譯期生成類的代理類，在運行期直接調(diào)用代理類的代理方法，APT 指的是后者。

如果不使用APT基于注解動態(tài)生成 java 代碼，那么就需要在運行時使用反射或者動態(tài)代理，比如大名鼎鼎的 butterknife 之前就是在運行時反射處理注解，為我們實例化控件并添加事件，然而這種方法很大的一個缺點就是用了反射，導致 app 性能下降。所以后面 butterknife 改為 apt 的方式，可以留意到，butterknife 會在編譯期間生成一個 XXX_ViewBinding.java。雖然 APT 增加了代碼量，但是不再需要用反射，也就無損性能。

APT 的缺點改進

性能問題解決了，又帶來新的問題了。我們在處理注解或元數(shù)據(jù)文件的時候，往往有自動生成源代碼的需要。難道我們要手動拼接源代碼嗎？不不不，這不符合代碼的優(yōu)雅，JavaPoet 這個神器就是來解決這個問題的。

JavaPoet

JavaPoet 是 square 推出的開源 java 代碼生成框架，提供 Java Api 生成 .java 源文件。這個框架功能非常有用，我們可以很方便的使用它根據(jù)注解、數(shù)據(jù)庫模式、協(xié)議格式等來對應生成代碼。通過這種自動化生成代碼的方式，可以讓我們用更加簡潔優(yōu)雅的方式要替代繁瑣冗雜的重復工作。本質(zhì)上就是用建造者模式來替代手工拼寫源文件。

JavaPoet詳細用法可參考：javapoet——讓你從重復無聊的代碼中解放出來

2. AspectJ

目前最好、最方便、最火的 AOP 實現(xiàn)方式當屬 AspectJ，它是一種幾乎和 Java 完全一樣的語言，而且完全兼容 Java。

但是在 Android 上集成 AspectJ 是比較復雜的。

我們需要使用 andorid-library gradle 插件在編譯時做一些 hook。使用 AspectJ 的編譯器（ajc，一個java編譯器的擴展）對所有受 aspect 影響的類進行織入。在 gradle 的編譯 task 中增加一些額外配置，使之能正確編譯運行。等等等等……

有很多庫幫助我們完成這些工作，可以方便快捷接入 AspectJ。

AspectJ 框架選型

3. Javassist

代表框架：熱修復框架HotFix 、Savior（InstantRun）

Javassist 是一個編輯字節(jié)碼的框架，作用是修改編譯后的 class 字節(jié)碼，ASM也有這個功能，不過 Javassist 的 Java 風格 API 要比 ASM 更容易上手。

既然是修改編譯后的 class 字節(jié)碼，首先我們得知道什么時候編譯完成，并且我們要在 .class文件被轉(zhuǎn)為 .dex 文件之前去做修改。在 Gradle Transfrom 這個 api 出來之前，想要監(jiān)聽項目被打包成 .dex 的時機，就必須自定義一個 Gradle Task，插入到 predex 或者 dex 之前，在這個自定義的 Task 中使用 Javassist 或者 ASM 對 class 字節(jié)碼進行操作。而 Transform 更為方便，我們不再需要插入到某個Task前面。Tranfrom 有自己的執(zhí)行時機，一經(jīng)注冊便會自動添加到 Task 執(zhí)行序列中，且正好是 class 被打包成dex之前。

五、總結(jié)

AOP 重在理解這種思想：

1. 先考慮要在什么期間插入代碼，選用合適的 AOP 方法；
2. 找準切入點也就是代碼可注入的點，比如一個方法的調(diào)用處或者方法內(nèi)部；
3. 接著考慮怎么過濾方法，找到注入點的描述，比如注入到所有onClick方法：call(* view.onClick(..))；
4. 接著要考慮以怎樣的方式處理代碼，是在代碼執(zhí)行前？執(zhí)行后？還是包裹代碼？還是替換目標代碼？

任何的技術(shù)都需要有業(yè)務依托和落地，想要一步步實現(xiàn) AOP 應用落地？請戳 一文應用 AOP | 最全選型考量 + 邊剖析經(jīng)典開源庫邊實踐，美滋滋。

六、還想了解更多？

博文推薦

• 深入理解Android之AOP
• Aspect Oriented Programming in Android
• Aspect Oriented Programming in Android 翻譯版
• 安卓AOP三劍客:APT,AspectJ,Javassist

書籍推薦

• Manning.AspectJ.in.Action第二版

我是 FeelsChaotic，一個寫得了代碼 p 得了圖，剪得了視頻畫得了畫的程序媛，致力于追求代碼優(yōu)雅、架構(gòu)設計和 T 型成長。

歡迎關(guān)注 FeelsChaotic 的簡書和掘金，如果我的文章對你哪怕有一點點幫助，歡迎 ??！你的鼓勵是我寫作的最大動力！

最最重要的，請給出你的建議或意見，有錯誤請多多指正！