一、位元組碼與引用檢測

　　1.1 Java位元組碼

　　本章中的位元組碼重點研究Java 位元組碼，Java位元組碼(Java bytecode)是Java虛擬機器執行的一種指令格式。可以通過javap -c -v xxx.class(Class檔案路徑) 命令來檢視一個Class對應的位元組碼檔案，如下圖所示：

　　1.2 位元組碼檢測

　　位元組碼檢測本質就是對.java或.kt檔案編譯後生成的Class檔案進行相關的分析和檢測。在正式介紹位元組碼分析在引用檢測上的原理與實戰前，先介紹下位元組碼引用檢測的技術預研背景。

　　二、位元組碼檢測技術的預研背景

　　整個預研背景需要先從筆者負責的APP--內銷官網APP的軟體架構講起。

　　2.1 內銷官網APP軟體架構

　　內銷官網APP目前共12個子倉，子倉分別獨立編譯成AAR檔案供APP工程使用，軟體架構圖如下圖所示：

　　APP以下，上層淺藍色為業務層，中間綠色為元件層，最下層深藍色為基礎框架層：

　　業務層：位於架構最上層，根據業務線劃分的業務模組(比如商城、社群、服務)，與產品業務相對應。鄭州看心理醫生哪家好http://www.hyde8731.com/

　　元件層：是APP的一些基礎功能(比如登入、自升級)和業務公用的元件(比如分享、地址管理、視訊播放)，提供一定的複用能力。

　　基礎框架層：通過跟業務完全無關的基礎元件(比如三方框架、自行封裝的通用能力)，提供完全的複用能力。

　　2.2 內銷官網APP客戶端開發模式

　　官網APP目前主要分3條業務線，多業務版本並行開發是常態，所以模組化非常必要。

　　官網APP模組化的子倉均已AAR形式供APP使用，且存在上層AAR依賴下層AAR的情況。

　　官網APP模組化分倉優化工作穿插在各業務版本中，各業務版本並行開發，底層倉庫難免有修改。

　　官網APP各業務版本並行開發時，一般只會新拉取當前版本需要修改程式碼的倉庫，其他倉庫均繼續依賴老版本的AAR。

　　2.3 類、方法、屬性引用錯誤導致的執行時崩潰

　　假設以下場景：

　　官網APP5.0版本開發過程中，由於HardWare倉沒有業務修改，所以繼續使用上個版本4.9.0.0的HardWare(版本開發過程中一般只會重新拉取需要修改的倉庫，無需修改的倉庫會繼續使用老版本)，但Core倉有程式碼修改，所以拉取了新的5.0分支，並修改了相關程式碼，刪除了CoreUtils類中的某個fun1方法