本文來自jsonchao的投稿，個人微信：bcce5360? ? ?? ? ? ?

現(xiàn)如今，編譯插樁技術(shù)已經(jīng)深入 Android 開發(fā)中的各個領(lǐng)域，而 AOP 技術(shù)正是一種高效實現(xiàn)插樁的模式，它的出現(xiàn)正好給處于黑暗中的我們帶來了光明，極大地解決了傳統(tǒng)開發(fā)過程中的一些痛點，而 AspectJ 作為一套基于 Java 語言面向切面的擴展設(shè)計規(guī)范，能夠賦予我們新的能力。在這篇文章我們將來學(xué)習(xí)如何使用 AspectJ 來進行插樁。本篇內(nèi)容如下所示：

• 1)、編譯插樁技術(shù)的分類與應(yīng)用場景。

• 2)、AspectJ 的優(yōu)勢與局限性。

• 3)、AspectJ 核心語法簡介。

• 4)、AspectJX 實戰(zhàn)。

• 5)、使用 AspectJX 打造自己的性能監(jiān)控框架。

• 6)、總結(jié)。

面向切面的程序設(shè)計 (aspect-oriented programming (AOP)) 吸引了很多開發(fā)者的目光， 但是如何在編碼中有效地實現(xiàn)這一套設(shè)計概念卻并不簡單，幸運的是，早在 2003 年，一套基于 Java 語言面向切面的擴展設(shè)計：AspectJ 誕生了。

不同與傳統(tǒng)的 OOP 編程，AspectJ (即 AOP) 的獨特之處在于 發(fā)現(xiàn)那些使用傳統(tǒng)編程方法無法處理得很好的問題。例如一個要在某些應(yīng)用中實施安全策略的問題。安全性是貫穿于系統(tǒng)所有模塊間的問題，而且每一個模塊都必須要添加安全性才能保證整個應(yīng)用的安全性，并且安全性模塊自身也需要安全性，很明顯這里的 安全策略的實施問題就是一個橫切關(guān)注點，使用傳統(tǒng)的編程解決此問題非常的困難而且容易產(chǎn)生差錯，這正是 AOP 發(fā)揮作用的時候了。傳統(tǒng)的面向?qū)ο缶幊讨?#xff0c;每個單元就是一個類，而 類似于安全性這方面的問題，它們通 常不能集中在一個類中處理，因為它們橫跨多個類，這就導(dǎo)致了代碼無法重用，它們是不可靠和不可繼承的，這樣的編程方式使得可維護性差而且產(chǎn)生了大量的代碼冗余，這是我們所不愿意看到的。

而面向切面編程的出現(xiàn)正好給處于黑暗中的我們帶來了光明，它針對于這些橫切關(guān)注點進行處理，就似面向?qū)ο缶幊烫幚硪话愕年P(guān)注點一樣。

在我繼續(xù)講解 AOP 編程之前，我們有必要先來看看當(dāng)前編譯插樁技術(shù)的分類與應(yīng)用場景。這樣能讓我們 從更高的緯度上去理解各個技術(shù)點之間的關(guān)聯(lián)與作用。

一、編譯插樁技術(shù)的分類與應(yīng)用場景

編譯插樁技術(shù)具體可以分為兩類，如下所示：

• 1)、APT(Annotation Process Tools) ：用于生成 Java 代碼。

• 2)、AOP(Aspect Oriented Programming)：用于操作字節(jié)碼。

下面?，我們分別來詳細介紹下它們的作用。

1、APT(Annotation Process Tools)

總所周知，ButterKnife、Dagger、GreenDao、Protocol Buffers 這些常用的注解生成框架都會在編譯過程中生成代碼。而 這種使用 AndroidAnnotation 結(jié)合 APT 技術(shù) 來生成代碼的時機，是在編譯最開始的時候介入的。而 AOP 是在編譯完成后生成 dex 文件之前的時候，直接通過修改 .class 文件的方式，來直接添加或者修改代碼邏輯的。

使用 APT 技術(shù)生成 Java 代碼的方式具有如下 兩方面 的優(yōu)勢：

• 1)、隔離了框架復(fù)雜的內(nèi)部實現(xiàn)，使得開發(fā)更加地簡單高效。

• 2)、大大減少了手工重復(fù)的工作量，降低了開發(fā)時出錯的機率。

2、AOP(Aspect Oriented Programming)

而對于操作字節(jié)碼的方式來說，一般都在 代碼監(jiān)控、代碼修改、代碼分析 這三個場景有著很廣泛的應(yīng)用。

相對于 Java 代碼生成的方式，操作字節(jié)碼的方式有如下 特點：

• 1)、應(yīng)用場景更廣。

• 2)、功能更加強大。

• 3)、使用復(fù)雜度較高。

此外，我們不僅可以操作 .class 文件的 Java 字節(jié)碼，也可以操作 .dex 文件的 Dalvik 字節(jié)碼。下面我們就來大致了解下在以上三類場景中編譯插樁技術(shù)具體是如何應(yīng)用的。

1、代碼監(jiān)控

編譯插樁技術(shù)除了 不能夠?qū)崿F(xiàn)耗電監(jiān)控，它能夠?qū)崿F(xiàn)各式各樣的性能監(jiān)控，例如：網(wǎng)絡(luò)數(shù)據(jù)監(jiān)控、耗時方法監(jiān)控、大圖監(jiān)控、線程監(jiān)控 等等。

譬如 網(wǎng)絡(luò)數(shù)據(jù)監(jiān)控 的實現(xiàn)，就是在 網(wǎng)絡(luò)層通過 hook 網(wǎng)絡(luò)庫方法 和 自動化注入攔截器的形式，實現(xiàn)網(wǎng)絡(luò)請求的全過程監(jiān)控，包括獲取握手時長，首包時間，DNS 耗時，網(wǎng)絡(luò)耗時等各個網(wǎng)絡(luò)階段的信息。

實現(xiàn)了對網(wǎng)絡(luò)請求過程的監(jiān)控之后，我們便可以 對整個網(wǎng)絡(luò)過程的數(shù)據(jù)表現(xiàn)進行詳細地分析，找到網(wǎng)絡(luò)層面性能的問題點，并做出針對性地優(yōu)化措施。例如針對于 網(wǎng)絡(luò)錯誤率偏高 的問題，我們可以采取以下幾方面的措施，如下所示：

• 1)、使用 HttpDNS。

• 2)、將錯誤數(shù)據(jù)同步 CDN。

• 3)、CDN 調(diào)度鏈路優(yōu)化。

2、代碼修改

用編譯插樁技術(shù)來實現(xiàn)代碼修改的場景非常之多，而使用最為頻繁的場景具體可細分為為如下四種：

• 1)、實現(xiàn)無痕埋點：如網(wǎng)易HubbleData之Android無埋點實踐、51 信用卡 Android 自動埋點實踐。

• 2)、統(tǒng)一處理點擊抖動：編譯階段統(tǒng)一 hook ?android.view.View.OnClickListener#onClick() 方法，來實現(xiàn)一個快速點擊無效的防抖動效果，這樣便能高效、無侵入性地統(tǒng)一解決客戶端快速點擊多次導(dǎo)致頻繁響應(yīng)的問題。

• 3)、第三方 SDK 的容災(zāi)處理：我們可以在上線前臨時修改或者 hook 第三方 SDK 的方法，做到快速容災(zāi)上線。

• 4)、實現(xiàn)熱修復(fù)框架：我們可以在 Gradle 進行自動化構(gòu)建的時候，即在 Java 源碼編譯完成之后，生成 dex 文件之前進行插樁，而插樁的作用是在每個方法執(zhí)行時先去根據(jù)自己方法的簽名尋找是否有自己對應(yīng)的 patch 方法，如果有，執(zhí)行 patch 方法；如果沒有，則執(zhí)行自己原有的邏輯。

3、代碼分析

例如 Findbugs 等三方的代碼檢查工具里面的 自定義代碼檢查 也使用了編譯插樁技術(shù)，利用它我們可以找出 不合理的 Hanlder 使用、new Thread 調(diào)用、敏感權(quán)限調(diào)用 等等一系列編碼問題。

二、AspectJ 的優(yōu)勢與局限性

最常用的字節(jié)碼處理框架有 AspectJ、ASM 等等，它們的相同之處在于輸入輸出都是 Class 文件。并且，它們都是 在 Java 文件編譯成 .class 文件之后，生成 Dalvik 字節(jié)碼之前執(zhí)行。

而 AspectJ 作為 Java 中流行的 AOP(aspect-oriented programming) 編程擴展框架，其內(nèi)部使用的是 BCEL框架 來完成其功能。下面，我們就來了解下 AspectJ 具備哪些優(yōu)勢。

1、AspectJ 的優(yōu)勢

它的優(yōu)勢有兩點：成熟穩(wěn)定、使用非常簡單。

1、成熟穩(wěn)定

字節(jié)碼的處理并不簡單，特別是 針對于字節(jié)碼的格式和各種指令規(guī)則，如果處理出錯，就會導(dǎo)致程序編譯或者運行過程中出現(xiàn)問題。而 AspectJ 作為從 2001 年發(fā)展至今的框架，它已經(jīng)發(fā)展地非常成熟，通常不用考慮插入的字節(jié)碼發(fā)生正確性相關(guān)的問題。

2、使用非常簡單

AspectJ 的使用非常簡單，并且它的功能非常強大，我們完全不需要理解任何 Java 字節(jié)碼相關(guān)的知識，就可以在很多情況下對字節(jié)碼進行操控。例如，它可以在如下五個位置插入自定義的代碼：

• 1)、在方法(包括構(gòu)造方法)被調(diào)用的位置。

• 2)、在方法體(包括構(gòu)造方法)的內(nèi)部。

• 3)、在讀寫變量的位置。

• 4)、在靜態(tài)代碼塊內(nèi)部。

• 5)、在異常處理的位置的前后。

此外，它也可以 直接將原位置的代碼替換為自定義的代碼。

2、AspectJ 的缺陷

而 AspectJ 的缺點可以歸結(jié)為如下 三點：

1、切入點固定

AspectJ 只能在一些固定的切入點來進行操作，如果想要進行更細致的操作則很難實現(xiàn)，它無法針對一些特定規(guī)則的字節(jié)碼序列做操作。

2、正則表達式的局限性

AspectJ 的匹配規(guī)則采用了類似正則表達式的規(guī)則，比如 匹配 Activity 生命周期的 onXXX 方法，如果有自定義的其他以 on 開頭的方法也會匹配到，這樣匹配的正確性就無法滿足。

3、性能較低

AspectJ 在實現(xiàn)時會包裝自己一些特定的類，它并不會直接把 Trace 函數(shù)直接插入到代碼中，而是經(jīng)過一系列自己的封裝。這樣不僅生成的字節(jié)碼比較大，而且對原函數(shù)的性能會有不小的影響。如果想對 App 中所有的函數(shù)都進行插樁，性能影響肯定會比較大。如果你只插樁一小部分函數(shù)，那么 AspectJ 帶來的性能損耗幾乎可以忽略不計。

三、AspectJ 核心語法簡介

AspectJ 其實就是一種 AOP 框架，AOP 是實現(xiàn)程序功能統(tǒng)一維護的一種技術(shù)。利用 AOP 可以對業(yè)務(wù)邏輯的各個部分進行隔離，從而使得業(yè)務(wù)邏輯各部分之間的耦合性降低，提高程序的可重用性，同時大大提高了開發(fā)效率。因此 AOP 的優(yōu)勢可總結(jié)為如下 兩點：

• 1)、無侵入性。

• 2)、修改方便。

此外，AOP 不同于 OOP 將問題劃分到單個模塊之中，它把 涉及到眾多模塊的同一類問題進行了統(tǒng)一處理。比如我們可以設(shè)計兩個切面，一個是用于處理 App 中所有模塊的日志輸出功能，另外一個則是用于處理 App 中一些特殊函數(shù)調(diào)用的權(quán)限檢查。

下面?，我們就來看看要掌握 AspectJ 的使用，我們需要了解的一些 核心概念。

1、橫切關(guān)注點

對哪些方法進行攔截，攔截后怎么處理。

2、切面(Aspect)

類是對物體特征的抽象，切面就是對橫切關(guān)注點的抽象。

3、連接點(JoinPoint)

JPoint 是一個程序的關(guān)鍵執(zhí)行點，也是我們關(guān)注的重點。它就是指被攔截到的點(如方法、字段、構(gòu)造器等等)。

4、切入點(PointCut)

對 JoinPoint 進行攔截的定義。PointCut 的目的就是提供一種方法使得開發(fā)者能夠選擇自己感興趣的 JoinPoint。

5、通知(Advice)

切入點僅用于捕捉連接點集合，但是，除了捕捉連接點集合以外什么事情都沒有做。事實上實現(xiàn)橫切行為我們要使用通知。它 一般指攔截到 JoinPoint 后要執(zhí)行的代碼，分為 前置、后置、環(huán)繞 三種類型。這里，我們需要注意 Advice Precedence(優(yōu)先權(quán)) 的情況，比如我們對同一個切面方法同時使用了 @Before 和 @Around 時就會報錯，此時會提示需要設(shè)置 Advice 的優(yōu)先級。

AspectJ 作為一種基于 Java 語言實現(xiàn)的一套面向切面程序設(shè)計規(guī)范。它向 Java 中加入了 連接點(Join Point) 這個新概念，其實它也只是現(xiàn)存的一個 Java 概 念的名稱而已。它向 Java 語言中加入了少許新結(jié)構(gòu)，譬如 切入點(pointcut)、通知(Advice)、類型間聲明(Inter-type declaration) 和 切面(Aspect)。切入點和通知動態(tài)地影響程序流程，類型間聲明則是 靜態(tài)的影響程序的類等級結(jié)構(gòu)，而切面則是對所有這些新結(jié)構(gòu)的封裝。

對于 AsepctJ 中的各個核心概念來說，其 連接點就恰如程序流中適當(dāng)?shù)囊稽c。而切入點收集特定的連接點集合和在這些點中的值。一個通知則是當(dāng)一個連接點到達時執(zhí)行的代碼，這些都是 AspectJ 的動態(tài)部分。其實連接點就好比是 程序中那一條一條的語句，而切入點就是特定一條語句處設(shè)置的一個斷點，它收集了斷點處程序棧的信息，而通知就是在這個斷點前后想要加入的程序代碼。

此外，AspectJ 中也有許多不同種類的類型間聲明，這就允許程序員修改程序的靜態(tài)結(jié)構(gòu)、名稱、類的成員以及類之間的關(guān)系。AspectJ 中的切面是橫切關(guān)注點的模塊單元。它們的行為與 Java 語言中的類很象，但是切面 還封裝了切入點、通知以及類型間聲明。

在 Android 平臺上要使用 AspectJ 還是有點麻煩的，這里我們可以直接使用滬江的 AspectJX 框架。下面，我們就來使用 AspectJX 進行 AOP 切面編程。

四、AspectJX 實戰(zhàn)

首先，為了在 Android 使用 AOP 埋點需要引入 AspectJX，在項目根目錄的 build.gradle 下加入：

classpath 'com.hujiang.aspectjx:gradle-android-plugin- aspectjx:2.0.0'

然后，在 app 目錄下的 build.gradle 下加入：

apply plugin: 'android-aspectjx'implement 'org.aspectj:aspectjrt:1.8.+'

JoinPoint 一般定位在如下位置:

• 1)、函數(shù)調(diào)用。

• 2)、獲取、設(shè)置變量。

• 3)、類初始化。

使用 PointCut 對我們指定的連接點進行攔截，通過 Advice，就可以攔截到 JoinPoint 后要執(zhí)行的代碼。Advice 通常有以下 三種類型：

• 1)、Before：PointCut 之前執(zhí)行。

• 2)、After：PointCut 之后執(zhí)行。

• 3)、Around：PointCut 之前、之后分別執(zhí)行。

1、最簡單的 AspectJ 示例

首先，我們舉一個 小栗子?：

@Before("execution(* android.app.Activity.on**(..))")public void onActivityCalled(JoinPoint joinPoint) throws Throwable { Log.d(...)}

其中，在 execution 中的是一個匹配規(guī)則，第一個 * 代表匹配任意的方法返回值，后面的語法代碼匹配所有 Activity 中以 on 開頭的方法。這樣，我們就可以 在 App 中所有 Activity 中以 on 開頭的方法中輸出一句 log。

上面的 execution 就是處理 Join Point 的類型，通常有如下兩種類型：

• 1)、call：代表調(diào)用方法的位置，插入在函數(shù)體外面。

• 2)、execution：代表方法執(zhí)行的位置，插入在函數(shù)體內(nèi)部。

2、統(tǒng)計 Application 中所有方法的耗時

那么，我們?nèi)绾卫盟y(tǒng)計?Application?中的所有方法耗時呢？

@Aspectpublic class ApplicationAop { @Around("call (* com.json.chao.application.BaseApplication.**(..))") public void getTime(ProceedingJoinPoint joinPoint) { Signature signature = joinPoint.getSignature(); String name = signature.toShortString(); long time = System.currentTimeMillis(); try { joinPoint.proceed(); } catch (Throwable throwable) { throwable.printStackTrace(); } Log.i(TAG, name + " cost" + (System.currentTimeMillis() - time)); }}

需要注意的是，當(dāng) Action 為 Before、After 時，方法入?yún)?JoinPoint。當(dāng) Action 為 Around 時，方法入?yún)?ProceedingPoint。

而 Around 和 Before、After 的最大區(qū)別就是 ProceedingPoint 不同于 JoinPoint，其提供了 proceed 方法執(zhí)行目標(biāo)方法。

3、對 App 中所有的方法進行 Systrace 函數(shù)插樁

@Aspectpublic class SystraceTraceAspectj { private static final String TAG = "SystraceTraceAspectj"; @Before("execution(* **(..))") public void before(JoinPoint joinPoint) { TraceCompat.beginSection(joinPoint.getSignature().toString()); } @After("execution(* **(..))") public void after() { TraceCompat.endSection(); }}

了解了 AspectJX 的基本使用之后，接下來我們就會使用它和 AspectJ 去打造一個簡易版的 APM(性能監(jiān)控框架)。

五、使用 AspectJ 打造自己的性能監(jiān)控框架

現(xiàn)在，我們將以奇虎360的 ArgusAPM 性能監(jiān)控框架來全面分析下 AOP 技術(shù)在性能監(jiān)控方面的應(yīng)用。主要分為 三個部分：

• 1)、監(jiān)控應(yīng)用冷熱啟動耗時與生命周期耗時。

• 2)、監(jiān)控 OKHttp3 的每一次網(wǎng)絡(luò)請求。

• 3)、監(jiān)控 HttpConnection 的每一次網(wǎng)絡(luò)請求。

1、監(jiān)控應(yīng)用冷熱啟動耗時與生命周期耗時

在 ArgusAPM 中，實現(xiàn)了 Activity 切面文件 TraceActivity， 它被用來監(jiān)控應(yīng)用冷熱啟動耗時與生命周期耗時，TraceActivity 的實現(xiàn)代碼如下所示：

@Aspectpublic class TraceActivity { // 1、定義一個切入點方法 baseCondition，用于排除 argusapm 中相應(yīng)的類。 @Pointcut("!within(com.argusapm.android.aop.*) && !within(com.argusapm.android.core.job.activity.*)") public void baseCondition() { } // 2、定義一個切入點 applicationOnCreate，用于執(zhí)行 Application 的 onCreate方法。 @Pointcut("execution(* android.app.Application.onCreate(android.content.Context)) && args(context)") public void applicationOnCreate(Context context) { } // 3、定義一個后置通知 applicationOnCreateAdvice，用于在 application 的 onCreate 方法執(zhí)行完之后插入 AH.applicationOnCreate(context) 這行代碼。 @After("applicationOnCreate(context)") public void applicationOnCreateAdvice(Context context) { AH.applicationOnCreate(context); } // 4、定義一個切入點，用于執(zhí)行 Application 的 attachBaseContext 方法。 @Pointcut("execution(* android.app.Application.attachBaseContext(android.content.Context)) && args(context)") public void applicationAttachBaseContext(Context context) { } // 5、定義一個前置通知，用于在 application 的 onAttachBaseContext 方法之前插入 AH.applicationAttachBaseContext(context) 這行代碼。 @Before("applicationAttachBaseContext(context)") public void applicationAttachBaseContextAdvice(Context context) { AH.applicationAttachBaseContext(context); } // 6、定義一個切入點，用于執(zhí)行所有 Activity 中以 on 開頭的方法，后面的 ”&& baseCondition()“ 是為了排除 ArgusAPM 中的類。 @Pointcut("execution(* android.app.Activity.on**(..)) && baseCondition()") public void activityOnXXX() { } // 7、定義一個環(huán)繞通知，用于在所有 Activity 的 on 開頭的方法中的開始和結(jié)束處插入相應(yīng)的代碼。(排除了 ArgusAPM 中的類) @Around("activityOnXXX()") public Object activityOnXXXAdvice(ProceedingJoinPoint proceedingJoinPoint) { Object result = null; try { Activity activity = (Activity) proceedingJoinPoint.getTarget(); // Log.d("AJAOP", "Aop Info" + activity.getClass().getCanonicalName() + // "\r\nkind : " + thisJoinPoint.getKind() + // "\r\nargs : " + thisJoinPoint.getArgs() + // "\r\nClass : " + thisJoinPoint.getClass() + // "\r\nsign : " + thisJoinPoint.getSignature() + // "\r\nsource : " + thisJoinPoint.getSourceLocation() + // "\r\nthis : " + thisJoinPoint.getThis() // ); long startTime = System.currentTimeMillis(); result = proceedingJoinPoint.proceed(); String activityName = activity.getClass().getCanonicalName(); Signature signature = proceedingJoinPoint.getSignature(); String sign = ""; String methodName = ""; if (signature != null) { sign = signature.toString(); methodName = signature.getName(); } if (!TextUtils.isEmpty(activityName) && !TextUtils.isEmpty(sign) && sign.contains(activityName)) { invoke(activity, startTime, methodName, sign); } } catch (Exception e) { e.printStackTrace(); } catch (Throwable throwable) { throwable.printStackTrace(); } return result; } public void invoke(Activity activity, long startTime, String methodName, String sign) { AH.invoke(activity, startTime, methodName, sign); }}

我們注意到，在注釋4、5這兩處代碼是用于 在 application 的 onAttachBaseContext 方法之前插入 AH.applicationAttachBaseContext(context) 這行代碼。此外，注釋2、3兩處的代碼是用于 在 application 的 onCreate 方法執(zhí)行完之后插入 AH.applicationOnCreate(context) 這行代碼。下面，我們再看看 AH 類中這兩個方法的實現(xiàn)，代碼如下所示：

public static void applicationAttachBaseContext(Context context) { ActivityCore.appAttachTime = System.currentTimeMillis(); if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, "applicationAttachBaseContext time : " + ActivityCore.appAttachTime); }}public static void applicationOnCreate(Context context) { if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, "applicationOnCreate"); }}

可以看到，在 AH 類的 applicationAttachBaseContext 方法中將啟動時間 appAttachTime 記錄到了 ActivityCore 實例中。而 applicationOnCreate 基本上什么也沒有實現(xiàn)。

然后，我們再回到切面文件 TraceActivity 中，看到注釋6、7處的代碼，這里用于 在所有 Activity 的 on 開頭的方法中的開始和結(jié)束處插入相應(yīng)的代碼。需要注意的是，這里 排除了 ArgusAPM 中的類。

下面，我們來分析下 activityOnXXXAdvice 方法中的操作。首先，在目標(biāo)方法執(zhí)行前獲取了 startTime。然后，調(diào)用了 proceedingJoinPoint.proceed() 用于執(zhí)行目標(biāo)方法；最后，調(diào)用了 AH 類的 invoke 方法。我們看看 invoke 方法的處理，代碼如下所示：

public static void invoke(Activity activity, long startTime, String lifeCycle, Object... extars) { // 1 boolean isRunning = isActivityTaskRunning(); if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, lifeCycle + " isRunning : " + isRunning); } if (!isRunning) { return; } // 2 if (TextUtils.equals(lifeCycle, ActivityInfo.TYPE_STR_ONCREATE)) { ActivityCore.onCreateInfo(activity, startTime); } else { // 3 int lc = ActivityInfo.ofLifeCycleString(lifeCycle); if (lc <= ActivityInfo.TYPE_UNKNOWN || lc > ActivityInfo.TYPE_DESTROY) { return; } ActivityCore.saveActivityInfo(activity, ActivityInfo.HOT_START, System.currentTimeMillis() - startTime, lc); }}

首先，在注釋1處，我們會先去查看當(dāng)前應(yīng)用的 Activity 耗時統(tǒng)計任務(wù)是否打開了。如果打開了，然后就會走到注釋2處，這里 會先判斷目標(biāo)方法名稱是否是 “onCreate”，如果是 onCreate 方法，就會執(zhí)行 ActivityCore 的 onCreateInfo 方法，代碼如下所示：

// 是否是第一次啟動public static boolean isFirst = true;public static long appAttachTime = 0;// 啟動類型public static int startType;public static void onCreateInfo(Activity activity, long startTime) { // 1 startType = isFirst ? ActivityInfo.COLD_START : ActivityInfo.HOT_START; // 2 activity.getWindow().getDecorView().post(new FirstFrameRunnable(activity, startType, startTime)); //onCreate 時間 long curTime = System.currentTimeMillis(); // 3 saveActivityInfo(activity, startType, curTime - startTime, ActivityInfo.TYPE_CREATE);}

首先，在注釋1處，會 記錄此時的啟動類型，第一次默認是冷啟動。然后在注釋2處，當(dāng)?shù)谝粠@示時會 post 一個 Runnable。最后，在注釋3處，會 調(diào)用 saveActivityInfo 將目標(biāo)方法相關(guān)的信息保存起來。這里我們先看看這個 FirstFrameRunnable 的 run 方法的實現(xiàn)代碼，如下所示：

@Override public void run() { if (DEBUG) { LogX.d(TAG, SUB_TAG, "FirstFrameRunnable time:" + (System.currentTimeMillis() - startTime)); } // 1 if ((System.currentTimeMillis() - startTime) >= ArgusApmConfigManager.getInstance().getArgusApmConfigData().funcControl.activityFirstMinTime) { saveActivityInfo(activity, startType, System.currentTimeMillis() - startTime, ActivityInfo.TYPE_FIRST_FRAME); } if (DEBUG) { LogX.d(TAG, SUB_TAG, "FirstFrameRunnable time:" + String.format("[%s, %s]", ActivityCore.isFirst, ActivityCore.appAttachTime)); } if (ActivityCore.isFirst) { ActivityCore.isFirst = false; if (ActivityCore.appAttachTime <= 0) { return; } // 2 int t = (int) (System.currentTimeMillis() - ActivityCore.appAttachTime); AppStartInfo info = new AppStartInfo(t); ITask task = Manager.getInstance().getTaskManager().getTask(ApmTask.TASK_APP_START); if (task != null) { // 3 task.save(info); if (AnalyzeManager.getInstance().isDebugMode()) { // 4 AnalyzeManager.getInstance().getParseTask(ApmTask.TASK_APP_START).parse(info); } } else { if (DEBUG) { LogX.d(TAG, SUB_TAG, "AppStartInfo task == null"); } } } }}

首先，在注釋1處，會計算出當(dāng)前的 第一幀的時間，即 當(dāng)前 Activity 的冷啟動時間，將它與 activityFirstMinTime 這個值作比較(activityFirstMinTime 的值默認為300ms)，如果 Activity 的冷啟動時間大于300ms的話，就會將冷啟動時間調(diào)用 saveActivityInfo 方法保存起來。

然后，在注釋2處，我們會 記錄 App 的啟動時間 并在注釋3處將它 保存到 AppStartTask 這個任務(wù)實例中。最后，在注釋4處，如果是 debug 模式，則會調(diào)用 AnalyzeManager 這個數(shù)據(jù)分析管理單例類的 getParseTask 方法獲取 AppStartParseTask 這個實例，關(guān)鍵代碼如下所示：

private Map mParsers;private AnalyzeManager() { mParsers = new HashMap(3); mParsers.put(ApmTask.TASK_ACTIVITY, new ActivityParseTask()); mParsers.put(ApmTask.TASK_NET, new NetParseTask()); mParsers.put(ApmTask.TASK_FPS, new FpsParseTask()); mParsers.put(ApmTask.TASK_APP_START, new AppStartParseTask()); mParsers.put(ApmTask.TASK_MEM, new MemoryParseTask()); this.isUiProcess = Manager.getContext().getPackageName().equals(ProcessUtils.getCurrentProcessName());}public IParser getParseTask(String name) { if (TextUtils.isEmpty(name)) { return null; } return mParsers.get(name);}

接著，就會調(diào)用 AppStartParseTask 類的 parse 方法，可以看出，它是一個 專門用于在 Debug 模式下的應(yīng)用啟動時間分析類。parse 方法的代碼如下所示：

/** * app啟動 * * @param info */@Overridepublic boolean parse(IInfo info) { if (info instanceof AppStartInfo) { AppStartInfo aInfo = (AppStartInfo) info; if (aInfo == null) { return false; } try { JSONObject obj = aInfo.toJson(); obj.put("taskName", ApmTask.TASK_APP_START); // 1 OutputProxy.output("啟動時間:" + aInfo.getStartTime(), obj.toString()); } catch (JSONException e) { e.printStackTrace(); } DebugFloatWindowUtls.sendBroadcast(aInfo); } return true;}

在注釋1處，parse 方法中僅僅是繼續(xù)調(diào)用了 OutputProxy 的 output 方法 將啟動時間和記錄啟動信息的字符串傳入。我們再看看 OutputProxy 的 output 方法，如下所示：

/** * 警報信息輸出 * * @param showMsg */public static void output(String showMsg) { if (!AnalyzeManager.getInstance().isDebugMode()) { return; } if (TextUtils.isEmpty(showMsg)) { return; } // 1、存儲在本地 StorageManager.saveToFile(showMsg);}

注釋1處，在 output 方法中又繼續(xù)調(diào)用了 StorageManager 的 saveToFile 方法 將啟動信息存儲在本地，saveToFile 的實現(xiàn)代碼如下所示：

/** * 按行保存到文本文件 * * @param line */public static void saveToFile(String line) { TraceWriter.log(Env.TAG, line);}

這里又調(diào)用了 TraceWriter 的 log 方法 將啟動信息按行保存到文本文件中，關(guān)鍵代碼如下所示：

public static void log(String tagName, String content) { log(tagName, content, true);}private synchronized static void log(String tagName, String content, boolean forceFlush) { if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, "tagName = " + tagName + " content = " + content); } if (sWriteThread == null) { // 1 sWriteThread = new WriteFileRun(); Thread t = new Thread(sWriteThread); t.setName("ApmTrace.Thread"); t.setDaemon(true); t.setPriority(Thread.MIN_PRIORITY); t.start(); String initContent = "---- Phone=" + Build.BRAND + "/" + Build.MODEL + "/verName:" + " ----"; // 2 sQueuePool.offer(new Object[]{tagName, initContent, Boolean.valueOf(forceFlush)}); if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, "init offer content = " + content); } } if (Env.DEBUG) { LogX.d(Env.TAG, SUB_TAG, "offer content = " + content); } // 3 sQueuePool.offer(new Object[]{tagName, content, Boolean.valueOf(forceFlush)}); synchronized (LOCKER_WRITE_THREAD) { LOCKER_WRITE_THREAD.notify(); }}

在注釋1處，如果 sWriteThread 這個負責(zé)寫入 log 信息的 Runnable 不存在，就會新建并啟動這個寫入 log 信息的低優(yōu)先級守護線程。

然后，會在注釋2處，調(diào)用 sQueuePool 的 offer 方法將相關(guān)的信息保存，它的類型為 ConcurrentLinkedQueue，說明它是一個專用于并發(fā)環(huán)境下的隊列。如果 Runnable 已經(jīng)存在了的話，就直接會在注釋3處將 log 信息入隊。最終，會在 sWriteThread 的 run 方法中調(diào)用 sQueuePool 的 poll() 方法將 log 信息拿出并通過 BufferWriter 封裝的 FileWriter 將信息保存在本地。

到此，我們就分析完了 onCreate 方法的處理，接著我們再回到 invoke 方法的注釋3處來分析不是 onCreate 方法的情況。如果方法名不是 onCreate 方法的話，就會調(diào)用 ActivityInfo 的 ofLifeCycleString 方法，我們看看它的實現(xiàn)，如下所示：

/** * 生命周期字符串轉(zhuǎn)換成數(shù)值 * * @param lcStr * @return */public static int ofLifeCycleString(String lcStr) { int lc = 0; if (TextUtils.equals(lcStr, TYPE_STR_FIRSTFRAME)) { lc = TYPE_FIRST_FRAME; } else if (TextUtils.equals(lcStr, TYPE_STR_ONCREATE)) { lc = TYPE_CREATE; } else if (TextUtils.equals(lcStr, TYPE_STR_ONSTART)) { lc = TYPE_START; } else if (TextUtils.equals(lcStr, TYPE_STR_ONRESUME)) { lc = TYPE_RESUME; } else if (TextUtils.equals(lcStr, TYPE_STR_ONPAUSE)) { lc = TYPE_PAUSE; } else if (TextUtils.equals(lcStr, TYPE_STR_ONSTOP)) { lc = TYPE_STOP; } else if (TextUtils.equals(lcStr, TYPE_STR_ONDESTROY)) { lc = TYPE_DESTROY; } return lc;}

可以看到，ofLifeCycleString 的作用就是將生命周期字符串轉(zhuǎn)換成相應(yīng)的數(shù)值，下面是它們的定義代碼：

/** * Activity 生命周期類型枚舉 */public static final int TYPE_UNKNOWN = 0;public static final int TYPE_FIRST_FRAME = 1;public static final int TYPE_CREATE = 2;public static final int TYPE_START = 3;public static final int TYPE_RESUME = 4;public static final int TYPE_PAUSE = 5;public static final int TYPE_STOP = 6;public static final int TYPE_DESTROY = 7;/** * Activity 生命周期類型值對應(yīng)的名稱 */public static final String TYPE_STR_FIRSTFRAME = "firstFrame";public static final String TYPE_STR_ONCREATE = "onCreate";public static final String TYPE_STR_ONSTART = "onStart";public static final String TYPE_STR_ONRESUME = "onResume";public static final String TYPE_STR_ONPAUSE = "onPause";public static final String TYPE_STR_ONSTOP = "onStop";public static final String TYPE_STR_ONDESTROY = "onDestroy";public static final String TYPE_STR_UNKNOWN = "unKnown";

然后，我們再回到 AH 類的 invoke 方法的注釋3處，僅僅當(dāng)方法名是上述定義的方法，也就是 Acitivity 的生命周期方法或第一幀的方法時，才會調(diào)用 ActivityCore 的 saveActivityInfo 方法。該方法的實現(xiàn)代碼如下所示：

public static void saveActivityInfo(Activity activity, int startType, long time, int lifeCycle) { if (activity == null) { if (DEBUG) { LogX.d(TAG, SUB_TAG, "saveActivityInfo activity == null"); } return; } if (time < ArgusApmConfigManager.getInstance().getArgusApmConfigData().funcControl.activityLifecycleMinTime) { return; } String pluginName = ExtraInfoHelper.getPluginName(activity); String activityName = activity.getClass().getCanonicalName(); activityInfo.resetData(); activityInfo.activityName = activityName; activityInfo.startType = startType; activityInfo.time = time; activityInfo.lifeCycle = lifeCycle; activityInfo.pluginName = pluginName; activityInfo.pluginVer = ExtraInfoHelper.getPluginVersion(pluginName); if (DEBUG) { LogX.d(TAG, SUB_TAG, "apmins saveActivityInfo activity:" + activity.getClass().getCanonicalName() + " | lifecycle : " + activityInfo.getLifeCycleString() + " | time : " + time); } ITask task = Manager.getInstance().getTaskManager().getTask(ApmTask.TASK_ACTIVITY); boolean result = false; if (task != null) { result = task.save(activityInfo); } else { if (DEBUG) { LogX.d(TAG, SUB_TAG, "saveActivityInfo task == null"); } } if (DEBUG) { LogX.d(TAG, SUB_TAG, "activity info:" + activityInfo.toString()); } if (AnalyzeManager.getInstance().isDebugMode()) { AnalyzeManager.getInstance().getActivityTask().parse(activityInfo); } if (Env.DEBUG) { LogX.d(TAG, SUB_TAG, "saveActivityInfo result:" + result); }}

可以看到，這里的邏輯很簡單，僅僅是 將 log 信息保存在 ActivityInfo 這個實例中，并將 ActivityInfo 實例保存在了 ActivityTask 中，需要注意的是，在調(diào)用 ArgusAPM.init() 這句初始化代碼時就已經(jīng)將 ActivityTask 實例保存在了 taskMap 這個 HashMap 對象中 了，關(guān)鍵代碼如下所示：

/** * 注冊 task:每添加一個task都要進行注冊，也就是把 * 相應(yīng)的 xxxTask 實例放入 taskMap 集合中。 */public void registerTask() { if (Env.DEBUG) { LogX.d(Env.TAG, "TaskManager", "registerTask " + getClass().getClassLoader()); } if (Build.VERSION.SDK_INT >= 16) { taskMap.put(ApmTask.TASK_FPS, new FpsTask()); } taskMap.put(ApmTask.TASK_MEM, new MemoryTask()); taskMap.put(ApmTask.TASK_ACTIVITY, new ActivityTask()); taskMap.put(ApmTask.TASK_NET, new NetTask()); taskMap.put(ApmTask.TASK_APP_START, new AppStartTask()); taskMap.put(ApmTask.TASK_ANR, new AnrLoopTask(Manager.getContext())); taskMap.put(ApmTask.TASK_FILE_INFO, new FileInfoTask()); taskMap.put(ApmTask.TASK_PROCESS_INFO, new ProcessInfoTask()); taskMap.put(ApmTask.TASK_BLOCK, new BlockTask()); taskMap.put(ApmTask.TASK_WATCHDOG, new WatchDogTask());}

接著，我們再看看 ActivityTask 類的實現(xiàn)，如下所示：

public class ActivityTask extends BaseTask { @Override protected IStorage getStorage() { return new ActivityStorage(); } @Override public String getTaskName() { return ApmTask.TASK_ACTIVITY; } @Override public void start() { super.start(); if (Manager.getInstance().getConfig().isEnabled(ApmTask.FLAG_COLLECT_ACTIVITY_INSTRUMENTATION) && !InstrumentationHooker.isHookSucceed()) {//hook失敗 if (DEBUG) { LogX.d(TAG, "ActivityTask", "canWork hook : hook失敗"); } mIsCanWork = false; } } @Override public boolean isCanWork() { return mIsCanWork; }}

可以看到，這里并沒有看到 save 方法，說明是在基類 BaseTask 類中，繼續(xù)看到 BaseTask 類的實現(xiàn)代碼：

/*** ArgusAPM任務(wù)基類** @author ArgusAPM Team*/public abstract class BaseTask implements ITask { ... @Override public boolean save(IInfo info) { if (DEBUG) { LogX.d(TAG, SUB_TAG, "save task :" + getTaskName()); } // 1 return info != null && mStorage != null && mStorage.save(info); } ...}

在注釋1處，繼續(xù)調(diào)用了 mStorage 的 save 方法，它是一個接口 IStorage，很顯然，這里的實現(xiàn)類是在 ActivityTask 的 getStorage() 方法中返回的 ActivityStorage 實例，它是一個 Activity 存儲類，專門負責(zé)處理 Activity 的信息。到此，監(jiān)控應(yīng)用冷熱啟動耗時與生命周期耗時的部分就分析完畢了。

下面，我們再看看如何使用 AspectJ 監(jiān)控 OKHttp3 的每一次網(wǎng)絡(luò)請求。

2、監(jiān)控 OKHttp3 的每一次網(wǎng)絡(luò)請求

首先，我們看到 OKHttp3 的切面文件，代碼如下所示：

/*** OKHTTP3 切面文件** @author ArgusAPM Team*/@Aspectpublic class OkHttp3Aspect { // 1、定義一個切入點，用于直接調(diào)用 OkHttpClient 的 build 方法。 @Pointcut("call(public okhttp3.OkHttpClient build())") public void build() { } // 2、使用環(huán)繞通知在 build 方法執(zhí)行前添加一個 NetWokrInterceptor。 @Around("build()") public Object aroundBuild(ProceedingJoinPoint joinPoint) throws Throwable { Object target = joinPoint.getTarget(); if (target instanceof OkHttpClient.Builder && Client.isTaskRunning(ApmTask.TASK_NET)) { OkHttpClient.Builder builder = (OkHttpClient.Builder) target; builder.addInterceptor(new NetWorkInterceptor()); } return joinPoint.proceed(); }}

在注釋1、2處，在調(diào)用 OkHttpClient 的 build 方法之前添加了一個 NetWokrInterceptor。我們看看它的實現(xiàn)代碼，如下所示：

@Overridepublic Response intercept(Chain chain) throws IOException { // 1、獲取每一個 OkHttp 請求的開始時間 long startNs = System.currentTimeMillis(); mOkHttpData = new OkHttpData(); mOkHttpData.startTime = startNs; if (Env.DEBUG) { Log.d(TAG, "okhttp request 開始時間：" + mOkHttpData.startTime); } Request request = chain.request(); // 2、記錄當(dāng)前請求的請求 url 和請求數(shù)據(jù)大小 recordRequest(request); Response response; try { response = chain.proceed(request); } catch (IOException e) { if (Env.DEBUG) { e.printStackTrace(); Log.e(TAG, "HTTP FAILED: " + e); } throw e; } // 3、記錄這次請求花費的時間 mOkHttpData.costTime = System.currentTimeMillis() - startNs; if (Env.DEBUG) { Log.d(TAG, "okhttp chain.proceed 耗時：" + mOkHttpData.costTime); } // 4、記錄當(dāng)前請求返回的響應(yīng)碼和響應(yīng)數(shù)據(jù)大小 recordResponse(response); if (Env.DEBUG) { Log.d(TAG, "okhttp chain.proceed end."); } // 5、記錄 OkHttp 的請求數(shù)據(jù) DataRecordUtils.recordUrlRequest(mOkHttpData); return response;}

首先，在注釋1處，獲取了每一個 OkHttp 請求的開始時間。接著，在注釋2處，通過 recordRequest 方法記錄了當(dāng)前請求的請求 url 和請求數(shù)據(jù)大小。然后，注釋3處，記錄了這次 請求所花費的時間。

接下來，在注釋4處，通過 recordResponse 方法記錄了當(dāng)前請求返回的響應(yīng)碼和響應(yīng)數(shù)據(jù)大小。最后，在注釋5處，調(diào)用了 DataRecordUtils 的 recordUrlRequest ?方法記錄了 mOkHttpData 中保存好的數(shù)據(jù)。我們繼續(xù)看到 recordUrlRequest 方法，代碼如下所示：

/** * recordUrlRequest * * @param okHttpData */public static void recordUrlRequest(OkHttpData okHttpData) { if (okHttpData == null || TextUtils.isEmpty(okHttpData.url)) { return; } QOKHttp.recordUrlRequest(okHttpData.url, okHttpData.code, okHttpData.requestSize, okHttpData.responseSize, okHttpData.startTime, okHttpData.costTime); if (Env.DEBUG) { Log.d(Env.TAG, "存儲okkHttp請求數(shù)據(jù)，結(jié)束。"); }}

可以看到，這里調(diào)用了 QOKHttp 的 recordUrlRequest 方法用于記錄網(wǎng)絡(luò)請求信息。我們再看到 QOKHttp 的 recordUrlRequest 方法，如下所示：

/** * 記錄一次網(wǎng)絡(luò)請求 * * @param url 請求url * @param code 狀態(tài)碼 * @param requestSize 發(fā)送的數(shù)據(jù)大小 * @param responseSize 接收的數(shù)據(jù)大小 * @param startTime 發(fā)起時間 * @param costTime 耗時 */public static void recordUrlRequest(String url, int code, long requestSize, long responseSize, long startTime, long costTime) { NetInfo netInfo = new NetInfo(); netInfo.setStartTime(startTime); netInfo.setURL(url); netInfo.setStatusCode(code); netInfo.setSendBytes(requestSize); netInfo.setRecordTime(System.currentTimeMillis()); netInfo.setReceivedBytes(responseSize); netInfo.setCostTime(costTime); netInfo.end();}

可以看到，這里 將網(wǎng)絡(luò)請求信息保存在了 NetInfo 中，并最終調(diào)用了 netInfo 的 end 方法，代碼如下所示：

/** * 為什存儲的操作要寫到這里呢? * 歷史原因 */public void end() { if (DEBUG) { LogX.d(TAG, SUB_TAG, "end :"); } this.isWifi = SystemUtils.isWifiConnected(); this.costTime = System.currentTimeMillis() - startTime; if (AnalyzeManager.getInstance().isDebugMode()) { AnalyzeManager.getInstance().getNetTask().parse(this); } ITask task = Manager.getInstance().getTaskManager().getTask(ApmTask.TASK_NET); if (task != null) { // 1 task.save(this); } else { if (DEBUG) { LogX.d(TAG, SUB_TAG, "task == null"); } }}

可以看到，這里 最終還是調(diào)用了 NetTask 實例的 save 方法保存網(wǎng)絡(luò)請求的信息。而 NetTask 肯定是使用了與之對應(yīng)的 NetStorage 實例將信息保存在了 ContentProvider 中。至此，OkHttp3 這部分的分析就結(jié)束了。

對于使用 OkHttp3 的應(yīng)用來說，上述的實現(xiàn)可以有效地獲取網(wǎng)絡(luò)請求的信息，但是如果應(yīng)用沒有使用 OkHttp3 呢？這個時候，我們就只能去監(jiān)控 HttpConnection 的每一次網(wǎng)絡(luò)請求。下面，我們就看看如何去實現(xiàn)它。

3、監(jiān)控 HttpConnection 和 HttPClient 的每一次網(wǎng)絡(luò)請求

在 ArgusAPM 中，使用的是 TraceNetTrafficMonitor 這個切面類對 HttpConnection 的每一次網(wǎng)絡(luò)請求進行監(jiān)控。關(guān)鍵代碼如下所示：

@Aspectpublic class TraceNetTrafficMonitor { // 1 @Pointcut("(!within(com.argusapm.android.aop.*) && ((!within(com.argusapm.android.**) && (!within(com.argusapm.android.core.job.net.i.*) && (!within(com.argusapm.android.core.job.net.impl.*) && (!within(com.qihoo360.mobilesafe.mms.transaction.MmsHttpClient) && !target(com.qihoo360.mobilesafe.mms.transaction.MmsHttpClient)))))))") public void baseCondition() { } // 2 @Pointcut("call(org.apache.http.HttpResponse org.apache.http.client.HttpClient.execute(org.apache.http.client.methods.HttpUriRequest)) && (target(httpClient) && (args(request) && baseCondition()))") public void httpClientExecuteOne(HttpClient httpClient, HttpUriRequest request) { } // 3 @Around("httpClientExecuteOne(httpClient, request)") public HttpResponse httpClientExecuteOneAdvice(HttpClient httpClient, HttpUriRequest request) throws IOException { return QHC.execute(httpClient, request); } // 排查一些處理異常的切面代碼 // 4 @Pointcut("call(java.net.URLConnection openConnection()) && (target(url) && baseCondition())") public void URLOpenConnectionOne(URL url) { } // 5 @Around("URLOpenConnectionOne(url)") public URLConnection URLOpenConnectionOneAdvice(URL url) throws IOException { return QURL.openConnection(url); } // 排查一些處理異常的切面代碼

}

TraceNetTrafficMonitor 里面的操作分為 兩類，一類是用于切 HttpClient 的 execute 方法，即注釋1、2、3處所示的切面代碼；一類是用于切 HttpConnection 的 openConnection 方法，對應(yīng)的切面代碼為注釋4、5處。我們首先分析 HttpClient 的情況，這里最終 調(diào)用了 QHC 的 execute 方法進行處理，如下所示：

public static HttpResponse execute(HttpClient client, HttpUriRequest request) throws IOException { return isTaskRunning() ? AopHttpClient.execute(client, request) : client.execute(request);}

這里又 繼續(xù)調(diào)用了 AopHttpClient 的 execute 方法，代碼如下所示：

public static HttpResponse execute(HttpClient httpClient, HttpUriRequest request) throws IOException { NetInfo data = new NetInfo(); // 1 HttpResponse response = httpClient.execute(handleRequest(request, data)); // 2 handleResponse(response, data); return response;}

首先，在注釋1處，調(diào)用了 handleRequest 處理請求數(shù)據(jù)，如下所示：

private static HttpUriRequest handleRequest(HttpUriRequest request, NetInfo data) { data.setURL(request.getURI().toString()); if (request instanceof HttpEntityEnclosingRequest) { HttpEntityEnclosingRequest entityRequest = (HttpEntityEnclosingRequest) request; if (entityRequest.getEntity() != null) { // 1、將請求實體使用 AopHttpRequestEntity 進行了封裝 entityRequest.setEntity(new AopHttpRequestEntity(entityRequest.getEntity(), data)); } return (HttpUriRequest) entityRequest; } return request;}

可以看到，在注釋1處，使用 AopHttpRequestEntity 對請求實體進行了封裝，這里的目的主要是為了 便于使用封裝實體中的 NetInfo 進行數(shù)據(jù)操作。接著，在注釋2處，將得到的響應(yīng)信息進行了處理，這里的實現(xiàn)很簡單，就是 使用 NetInfo 這個實體類將響應(yīng)信息保存在了 ContentProvider 中。至此，HttpClient 的處理部分我們就分析完畢了。

下面，我們接著分析下 HTTPConnection 的切面部分代碼，如下所示：

// 4@Pointcut("call(java.net.URLConnection openConnection()) && (target(url) && baseCondition())")public void URLOpenConnectionOne(URL url) {}// 5@Around("URLOpenConnectionOne(url)")public URLConnection URLOpenConnectionOneAdvice(URL url) throws IOException { return QURL.openConnection(url);}

可以看到，這里是 調(diào)用了 QURL 的 openConnection 方法進行處理。我們來看看它的實現(xiàn)代碼：

public static URLConnection openConnection(URL url) throws IOException { return isNetTaskRunning() ? AopURL.openConnection(url) : url.openConnection();}

這里 又調(diào)用了 AopURL 的 openConnection 方法，繼續(xù) 看看它的實現(xiàn)：

public static URLConnection openConnection(URL url) throws IOException { if (url == null) { return null; } return getAopConnection(url.openConnection());}private static URLConnection getAopConnection(URLConnection con) { if (con == null) { return null; } if (Env.DEBUG) { LogX.d(TAG, "AopURL", "getAopConnection in AopURL"); } // 1 if ((con instanceof HttpsURLConnection)) { return new AopHttpsURLConnection((HttpsURLConnection) con); } // 2 if ((con instanceof HttpURLConnection)) { return new AopHttpURLConnection((HttpURLConnection) con); } return con;}

最終，在注釋1處，會判斷如果是 https 請求，則會使用 AopHttpsURLConnection 封裝 con，如果是 http 請求，則使用 AopHttpURLConnection 進行封裝。AopHttpsURLConnection 的實現(xiàn)與它類似，僅僅是多加了 SSL 證書驗證的部分。所以這里我們就直接分析一下 AopHttpURLConnection 的實現(xiàn)，這里面的代碼非常多，就不貼出來了，但是，它的 核心的處理 可以簡述為如下 兩點：

• 1)、在回調(diào) getHeaderFields()、getInputStream()、getLastModified() 等一系列方法時會調(diào)用 inspectAndInstrumentResponse 方法把響應(yīng)大小和狀態(tài)碼保存在 NetInfo 中。

• 2)、在回調(diào) onInputstreamComplete()、onInputstreamError()等方法時，即請求完成或失敗時，此時會直接調(diào)用 myData 的 end 方法將網(wǎng)絡(luò)響應(yīng)信息保存在 ContentProvider 中。

至此，ArgusAPM 的 AOP 實現(xiàn)部分就已經(jīng)全部分析完畢了。

五、總結(jié)

最后，我們再來回顧一下本篇文章中我們所學(xué)到的知識，如下所示：

• 1、編譯插樁技術(shù)的分類與應(yīng)用場景。

  • 1)、APT。

  • 2)、AOP。

• 2、AspectJ 的優(yōu)勢與局限性。

• 3、AspectJ 核心語法簡介。

• 4、AspectJX 實戰(zhàn)。

  • 1)、最簡單的 AspectJ 示例。

  • 2)、統(tǒng)計 Application 中所有方法的耗時。

  • 3)、對 App 中所有的方法進行 Systrace 函數(shù)插樁。

• 5、使用 AspectJ 打造自己的性能監(jiān)控框架。

  • 1)、監(jiān)控應(yīng)用冷熱啟動耗時與生命周期耗時。

  • 2)、監(jiān)控 OKHttp3 的每一次網(wǎng)絡(luò)請求。

  • 3)、監(jiān)控 HttpConnection 和 HttpClient 的每一次網(wǎng)絡(luò)請求。

可以看到，AOP 技術(shù)的確很強大，使用 AspectJ 我們能做很多事情，但是，它也有一系列的缺點，比如切入點固定、正則表達式固有的缺陷導(dǎo)致的使用不靈活，此外，它還生成了比較多的包裝代碼。那么，有沒有更好地實現(xiàn)方式，既能夠在使用上更加地靈活，也能夠避免生成包裝代碼，以減少插樁所帶來的性能損耗呢？沒錯，就是 ASM，但是它 需要通過操作 JVM 字節(jié)碼的方式來進行代碼插樁，入手難度比較大，所以，下篇文章我們將會先深入學(xué)習(xí) JVM 字節(jié)碼的知識，敬請期待~

? ? ? ? ? ? ? ? ? ? ? ? 喜歡 就關(guān)注吧，歡迎投稿！

總結(jié)

以上是生活随笔為你收集整理的aspectj 获取方法入参_深入探索编译插桩技术（二、AspectJ）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。