說說 ByteX 的能力

說說 ByteX 的能力

ByteX 的能力說明

ByteX 的實作

今天以筆者簡陋的知識說下對 ByteX 的了解。

ByteX 是一個 Android gradle 插件管理庫，其中預設提供了很多功能。今天隻是希望可以簡明地述說一下 ByteX 的功能，以及其實作的一些重點。因為筆者了解能力有限，可能有些錯誤，希望可以有朋友指出哈。

Android 使用 gradle 進行編譯的時候，java 源碼部分會先編譯成 class 檔案，然後 class 檔案再經過打包處理，成為 dex 檔案。為了簡化了解的步驟，可以認為 dex 檔案就是最後 Android 應用執行時候的代碼。

在開發的時候，很多情況下都會有這樣的需求：在符合某些條件的方法執行的某個位置，執行某操作。例如：給現在的代碼裡的所有方法的第一句都增加一條 log。我們以 “給現在的代碼裡的所有方法都增加一條 log” 為例，做法可以是

在 java 檔案轉成 class 之前，在所有的 java 方法第一句都增加 log 。(為了簡化表述，這裡不考慮構造方法需要先 super 了。😄)

在 class 檔案生成後，在所有的 class 方法第一句都增加 log。 (為了簡化表述，這裡也忽略有的不應該加了。😄)

這裡通常會選擇第二種方式，原因有：

因為 java 檔案的處理相比 class 檔案不夠通用（比如 Kotlin 檔案也會轉成 class 檔案，但是如果是按照 java 檔案進行處理的話，還需要新增一份對 kotlin 檔案的處理）。

目前 Android 編譯提供的就是 class 的周遊處理，而不是 java 的檔案處理。

而 class 檔案的處理很簡單，就是将許多個 class 檔案依次進行周遊并進行處理，處理之後會生成新的 class 檔案。

假設有多個修改代碼的需求的話，比如說除了 給現在的代碼裡的所有方法的第一句都增加一條 log ， 我們還要 給現在的代碼裡的所有方法的最後一句都增加一條 log 。那麼我們有兩種方式：

是在一次 class 的周遊之中做兩件事情。

進行兩次周遊，一次在頭部加一句 log，一次在尾部加一句 log。

上面的隻是類比，實際上肯定會有很多類似“給每個方法增加 log”這類需求，比如說檢測并攔截對敏感裝置字段的通路 、給某些關鍵方法增加性能統計以及日志上報 等。我們一般的應對也是上面兩種，但是前者是不能接受的，因為 各個需求是互不相幹的代碼執行的（甚至大部分是第三方庫裡提供的處理），無法整合到一起，是以隻能接受第二種模式——重複周遊處理 class。

這樣的話，循環周遊 class 檔案會導緻 class 處理用了太多的時間，增加了編譯時間。

而 ByteX 的誕生，就是為了将這些處理整合到一起，即将第二種模式修改為第三種模式。

那麼我們推測一下 ByteX 所作的事情 :

作為一個普通的 class 處理者，周遊 class 進行處理

作為一個 “class 處理者” 的容器，将 周遊 class 的操作 傳遞到其中每個元素上面。

其實基本上也差不多哈。