一款Android APK的結構構成解析

eb6d235ec553b953be47babcf3c79214.gif

作者:hockeyli,騰訊 PCG 客戶端開發工程師

一、 APK 組成解析

在開始解析 Android 構建流程之前,我們先來看下構建的最終產物 APK 的整體組成:

373c7fa912fa93d601a2bee46c76ae2d.jpg

APK 主要由五個部分組成,分別是:

  • Dex:.class 文件處理後的產物,Android 系統的可執行文件
  • Resource:資源文件,主要包括 layout、drawable、animator,通過 R.XXX.id 引用
  • Assets:資源文件,通過 AssetManager 進行加載
  • Library:so 庫存放目錄
  • META-INF:APK 簽名有關的信息

1.1 Apk 分析工具

工欲善其事,必先利其器,既然想分析 APK 必然少不瞭好用的工具。

① Android Studio 自帶的 APK 分析器

通過 APK 分析器,我們可以完成這些操作:

  • 查看 APK 中文件(如 DEX 和 Android 資源文件)的絕對大小和相對大小
  • 瞭解 DEX 文件的組成
  • 快速查看 APK 中文件(如 AndroidManifest.xml)的最終版本
  • 對兩個 APK 進行並排比較

17ea071ebbfe2d53570e88ff4f28ba76.jpg

32b7dc60ca5a947d729733c3149aa1c8.jpg

② ClassyShark 可以做為 AS 自帶 APK 分析器的補充,幫我們分析 dex 中的詳細數據,以及查看 APK 中的總方法數以及各個模塊的方法數分佈。

d2879d43ba14e877bcbd96418f5fcb02.jpg

bd3279cc4853ce9876ff287d19573e5e.jpg

1.2 Dex 知識點拓展

當我們在 Android 查看一個 APK 的時候,可以看到右上角有 Defined Methods 和 Referenced Methods,但大多數人可能不知道這兩者的區別,這裡簡單說明下:

Defined Methods:在這個 Dex 中定義的方法;Referenced Methods:Defined Methods 以及 Defined Methods 引用到的方法。

4ae1ce91df4fdc74510ff8cc805e0c95.jpg

Android 有 64K 引用限制,當 type_ids、method_ids 或者 field_ids 超過 65536(64 * 1024)的時候,需要進行 dex 分包,為瞭 Dex 的數量盡可能少,我們需要盡量實現「Dex 信息有效率」的提升。

Dex 信息有效率 = Defined Methods 數量 / Referenced Methods 數量

fcbd12157381ce3d4fce1f805d3f458a.jpg

二、 構建源碼導讀

當我們用 Android Studio 進行安裝包構建的時候,會發現其實是運行瞭一連串的 Task,也就是說其實是這些 task 的配合,最終構建出我們的 APK 的。

f7effceb22288a5f0bc954d9b2f21079.jpg

2.1 源碼引入

如果我們想更瞭解 Android 的構建流程,對於相關的源碼肯定是要有所瞭解的。那我們如何看到這些 Task 相關的源碼呢,我們知道 Android 是用 Gradle 進行構建的,也就意味著這些 task 其實都是放在 Gradle 中,我們想看 Gradle 中源碼的話,可以在 build.gradle 將 Gradle 進行編譯。

compileOnly "com.android.tools.build:gradle:3.0.1"

編譯完之後,可以在 ApplicationTaskManager#createTasksForVariantScope 中找到創建這些 Task 相關的代碼,也就意味著順藤摸瓜找到這些 Task 的真正實現邏輯。

2.2 BuildConfig Task 詳解

這裡以 BuildConfig 文件的生成為例,來梳理下如何查看某個 task 的代碼邏輯。

e00bdb38830dbbc72bfabf6040247256.jpg

生成 BuildConfig 文件,是通過 ApplicationTaskManager 中通過 createBuildConfigTask 來創建對應的 task。

c3d54f1c5e87e629dd6851b62272d237.jpg

e4274c4ca18605c2cbe68f64718fbf82.jpg

順著代碼邏輯,我們找到最終真正實現這個邏輯的是:GenerateBuildConfig 這個 task,GenerateBuildConfig 是繼承自 BaseTask,這裡有個小技巧是,Task 中真正的執行邏輯都是在帶著 @TaskAction 註解的方法上的,所以我們能很快找到對應的 generate() 方法。可以看到生成 BuildConfig 整體的邏輯還是比較簡單的,其實就是將 build.gradle 中自帶的屬性以及我們自定義的屬性進行讀取,然後通過 JavaWriter 生成對應的 BuildConfig 文件。

df07f7f471b6ece6c98a1e12b9052de4.jpg

7a1ba666a1140804ce039a0a0364a2c7.jpg

2.3 獲取所有 task 對應的類名

看到上面的例子,可能有些人會拋出一個疑問就是那我們怎麼確定構建中執行的 task 具體對應哪個類呢,這裡提供一個小技巧,其實我們可以在 taskGraph 構建完成之後,將所有 task name 以及對應的 class 進行打印。例如在 build.gradle 中加入這個代碼之後,我們在運行的時候,就會把 task 所對應的類名也都一起打印出來。

a377eee7e3d8968efb8d4f609aed5ad3.jpg

222d9ed225de75f9c46600e5ab253fc8.jpg

三、構建流程梳理

44cbf4df08724a4f3247cc0fe276ea86.jpg

可以看到 Android 構建中會涉及到多個工具,我們可以通過 open $ANDROID_HOME/build-tools 來查看相關的構建工具。

92871bad7d2fc9268769a14710a1f17e.jpg

四、手動構建 APK

最後我們通過命令行來手動打包一個可執行的 APK,能讓我們對 APK 構建的理解更加深入。首先需要準備下 代碼、資源文件、AndroidManifest 這些構建 APK 的必要文件。

ddaadfa687ef474d71fd94b48e89a5fd.jpg

① 通過 aapt2 compile 將 res 資源編譯成 .flat 的二進制文件:

aapt2 compile -o build/res.zip --dir res

② 通過 aapt2 link 將 .flat 和 AndroidManifest 進行連接,轉化成不包含 dex 的 apk 和 R.java:

aapt2 link build/res.zip -I $ANDROID_HOME/platforms/android-30/android.jar --java build --manifest AndroidManifest.xml -o build/app-debug.apk

③ 通過 javac 將 Java 文件編譯成 .class 文件:

javac -d build -cp $ANDROID_HOME/platforms/android-30/android.jar com/**/**/**/*.java

④ 通過 d8 將 .class 文件轉化成 dex 文件:

d8 --output build/ --lib $ANDROID_HOME/platforms/android-30/android.jar build/com/tencent/hockeyli/androidbuild/*.class

⑤ 合並 dex ⽂件和資源⽂件:

zip -j build/app-debug.apk build/classes.dex

⑥ 對 apk 通過 apksigner 進行簽名:

apksigner sign -ks ~/.android/debug.keystore build/appdebug.apk

歡迎點贊

到此這篇關於一款Android APK的結構構成解析的文章就介紹到這瞭,更多相關Android apk 結構內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: