官方對APK構建過程的介紹
典型 Android 應用模塊的構建流程，按照以下常規步驟執行：
- 編譯器將您的源代碼轉換成 DEX 文件（Dalvik 可執行文件，其中包括在 Android 設備上運行的字節碼），并將其他所有內容轉換成編譯后的資源。
- 打包器將 DEX 文件和編譯后的資源組合成 APK 或 AAB（具體取決于所選的 build 目標）。 必須先為 APK 或 AAB 簽名，然后才能將應用安裝到 Android 設備或分發到 Google Play 等商店。
- 打包器使用調試或發布密鑰庫為 APK 或 AAB 簽名：
- 如果您構建的是調試版應用（即專門用來測試和分析的應用），則打包器會使用調試密鑰庫為應用簽名。Android Studio 會自動使用調試密鑰庫配置新項目。
- 如果您構建的是打算對外發布的發布版應用，則打包器會使用發布密鑰庫（您需要進行配置）為應用簽名。
- 在 Android Studio 中為應用簽名
- 在生成最終 APK 之前，打包器會使用
zipalign工具對應用進行優化，以減少其在設備上運行時所占用的內存。構建流程結束時，您將獲得應用的調試版或發布版 APK/AAB，以用于部署、測試或向外部用戶發布。
精通APK構建
APK的一般生成步驟
- 打包資源文件 aapt/aapt2
- 生成R文件
- 生成編譯后的資源文件
- aidl生成java文件 aidl
- Java代碼生成class文件 javac
- class文件生成dex文件 dx/d8/r8
- 打包（未簽名）apk apkbuilder
- 簽名apk jarsigner/apksigner
- 對齊apk zipalign
注：官方對上述部分命令行工具的使用有介紹：[ 官方指導：命令行工具 ]
1. 打包資源文件 aapt/aapt2
- aapt/aapt2：ANDROID_SDK/build-tools/
見[ 官方指導：命令行工具-aapt2 ]
aapt package -f -m -J ./gen -S res -M AndroidManifest.xml -I D:\android.jar
-f 如果編譯生成的文件已經存在，強制覆蓋。
-m 使生成的包的目錄存放在-J參數指定的目錄
-J 指定生成的R.java 的輸出目錄路徑
-S 指定res文件夾的路徑
-I 指定某個版本平臺的android.jar文件的路徑
-A 指定assert文件夾的路徑
aapt 入口為 frameworks/base/tools/aapt/Main.cpp ，其中對 assets文件夾路徑、res文件夾路徑、AndroidManifest文件等會采取不同的策略。
對assets目錄下的資源不進行編譯，會被原封不動的打入apk中，也就是說assets不會被壓縮。
AndroidManifest.xml會被aapt編譯成二進制。
res下的資源，大多會被編譯成針對Android平臺優化過的二進制文件。對drawable下的png默認會進行壓縮處理（raw目錄下除外）
資源文件（res/下的文件） ---AAPT---|---> R.java（資源索引表）
|---> resource.arsc 資源文件
|---> res文件(二進制&非二進制如res/raw和pic保持原樣)
// 每個資源ID占4字節
public final class R {
public static final class anim {
public static int fade_in = 0x7f010001;
public static int fade_out = 0x7f010002;
}
}
// 第一位字節 0x7f 表示 packageID ,用來限定資源的來源。系統資源包是 0x01，SharedLibrary類型資源包是 0x00， 普通App包則是 0x7f；
// 次一位字節 01 表示 TypeID，用來表示資源類型，如 drawable、layouts、anims、color、menu 等；
// 后2字節 0001/0002 表示 EntryID，指的是每一個資源在對應的 TypeID 中出現的順序
resources.arsc 是一個App的資源索引表，可以理解為一個map映射表，map的key是 R.java 中的資源ID，而 value 就是其對應的資源所在路徑，通過 R.java 文件和 resources.arsc 就可以在代碼中找到對應的資源引用。
res/raw和assets的相同點：
- 兩者目錄下的文件在打包后會原封不動的保存在apk包中，不會被編譯成二進制。
res/raw和assets的不同點：
- res/raw中的文件會被映射到R.java文件中，訪問的時候直接使用資源ID即R.id.filename；assets文件夾下的文件不會被映射到R.java中，訪問的時候需要AssetManager類，通過文件名訪問。
- res/raw不可以有目錄結構，而assets則可以有目錄結構，也就是assets目錄下可以再建立文件夾
2. aidl生成java文件 aidl
- aidl：ANDROID_SDK/build-tools/
3. Java代碼生成class文件 javac
- javac：jdk/
javac -target 1.7 -bootclasspath D:\android-sdk-windows\platforms\android-8\android.jar -d bin src\demo\project\*.java gen\demo\project\R.java
-target <版本> 生成特定 VM 版本的類文件
-bootclasspath <路徑> 覆蓋引導類文件的位置
-d <目錄> 指定存放生成的類文件的位置
-sourcepath <路徑> 指定查找輸入源文件的位置
Javac 入口為 com.sun.tools.javac.main.JavaCompiler 類，主要邏輯集中在 compile() 和 compile2() 方法中
4. class文件生成dex文件 dx/d8/r8
- dx：ANDROID_SDK/build-tools/
- 最老、僅支持編譯dex（dexing）
- d8：ANDROID_SDK/build-tools/（高版本sdk才提供）
- 較新，用于替代dx，支持編譯dex（dexing）與脫糖（desugaring）
- r8：/Applications/Android Studio.app/Contents/plugins/android/lib/r8.jar
- 最新，相當于
ProGuard + d8，支持縮減（shrinking）、編譯dex（dexing）與脫糖（desugaring） - sdk未提供r8.jar，網上也沒有下載，需自行下載源碼編譯jar包，但有點麻煩，可在Android Studio/plugin/目錄中找到
- 最新，相當于
注：關于dex生成的發展史，可以參考我的另一篇文章：[通過命令行進行R8混淆]
dx用法
dx --dex --output=D:\ProjectDemo\bin\classes.dex D:\ProjectDemo\bin
--output=<要生成的classes.dex路徑> <要處理的class文件的路徑>
d8用法
見[ 官方指導：命令行工具-d8 ]
# debug mode
$ java -jar build/libs/d8.jar --output out input.jar
# release mode
$ java -jar build/libs/d8.jar --release --output out input.jar
# example: java -jar build/libs/d8.jar --release --output . --pg-conf ./proguard-project.txt ./input.jar
r8用法
$ java -jar build/libs/r8.jar --release --output out --pg-conf proguard.cfg input.jar
ANDROID_SDK中提供的有些jar包由于沒有指定入口類main方法，不能直接通過 -jar 執行，可通過 -cp 顯式的指定入口，舉例：
java -cp r8.jar com.android.tools.r8.R8 --help
5. 打包（未簽名）apk apkbuilder
- apkbuilder：
- 較老SDK：ANDROID_SDK/tools/
- 較新SDK：ANDROID_SDK/tools/lib/sdklib.jar
apkbuilder只是一個腳本，實際上調用的是 ANDROID_SDK/tools/ 下的jar包中的 com.android.build.ApkBuilderMain 類。
這個jar包在低版本SDK中是哪個我沒注意看過。而高版本SDK中已經不提供 apkbuilder 了，但 ANDROID_SDK/tools/lib/sdklib.jar 中有ApkBuilderMain類，可以使用（未指定Main方法入口，調用時需顯式的指定：java -cp sdklib.jar com.android.build.ApkBuilderMain --help）。
apkbuilder D:\ProjectDemo\bin\projectdemo.apk -v -u -z D:\ProjectDemo\bin\resources.ap_ -f D:\ProjectDemo\bin\classes.dex -rf D:\ProjectDemo\src
-v Verbose 顯示過程信息
-u 創建一個無簽名的包
-z 指定apk資源路徑
-f 指定dex文件路徑
-rf 指定源碼路徑
6. 簽名apk jarsigner/apksigner
- jarsigner：v1簽名，jdk/bin/，參考 [jarsigner指導文檔]
- apksigner：v2簽名，ANDROID_SDK/build-tools/
jarsigner用法
jarsigner -digestalg SHA1 -sigalg MD5withRSA -keystore mykeystore.key -storepass STORE_PASS MY_APP.apk KEY_ALIAS
-verbose 簽名/驗證時輸出詳細信息
-keystore 密鑰庫位置
-storepass 用于密鑰庫完整性的口令
-keypass 專用密鑰的口令（如果不同）
-signedjar 已簽名的 JAR 文件的名稱 （第一個apk是簽名之后的文件， 第二個apk是需要簽名的文件）
apksigner用法
見[ 官方指導：命令行工具-apksigner ]
- apksigner：ANDROID_SDK/build-tools/
apksigner sign --ks **.keystore --ks-key-alias [別名] --ks-pass pass:[別名密碼] --key-pass pass:[證書密碼] --out [簽名后文件存放路徑] [未簽名的文件路徑]
// 私鑰和證書必須提供，有兩種方式：
--ks：指定密鑰庫文件（即.keystore/.jks，私鑰和證書被存放其中）
--key 和 --cert：分別指定私鑰和證書，私鑰必須使用 PKCS #8 格式(.pk8)，證書必須使用 X.509 格式(x509.pem)。
7. 對齊apk zipalign
見[ 官方指導：命令行工具-zipalign ]
- zipalign：ANDROID_SDK/build-tools/
- 若使用v1簽名，zipalign 必須在簽名后進行
- 若使用v2簽名，zipalign 必須在簽名前進行
// 對齊
zipalign -p -f -v 4 infile.apk outfile.apk
// 確認existing.apk的對齊方式
zipalign -c -v 4 existing.apk
-c 僅檢查對齊情況（不會修改文件）。
-f 覆蓋現有輸出文件。
-h 顯示工具幫助。
-p 使未壓縮的 .so 文件對齊頁面。
-v 詳細輸出。
-z 使用 Zopfli 重新壓縮。
zipalign是一個zip歸檔文件對齊工具，它將zip（apk也是zip文件）中的所有未壓縮文件相對于文件開頭對齊（偏移為4字節的整數倍），這樣就可以通過內存映射（mmap）訪問這些文件，而無需在 RAM 中復制這些數據，既高效又減少了應用的內存使用。
CPU在處理內存數據時，并非一次提取一個memory cell，通常是提取一組相鄰內存單元。在32-bit machine，CPU一次從內存中讀取4個連續的memory cell(4-byte) 。4 byte chunk(4字節流) 為一個讀取周期。比如，讀取一個int型 數據時，需要一個讀取周期(int 占4 byte)，讀取Double型，則需要2個讀取周期。
注：上圖是以c代碼為例，c語言中 1char = 1byte，而在java中 1char=2byte。
附加：smali工具
baksmali：將dex編譯為smali
java -jar baksmali-1.3.2.jar -o classout/ classes.dex
smali：將smali反編譯成dex
java -jar smali-1.3.2.jar classout/ -o classes.dex
