通過前面幾篇文章學習了 Gradle 基礎知識以及 Gradle 插件相關的知識,關於 Gradle 及其插件相關知識請先閱讀下面幾篇文章:
- Gradle 系列之初識 Gradle
- Gradle 之 Groovy 基礎
- Gradle 系列之構建腳本基礎
- Gradle 系列之 Gradle 任務
- Gradle 系列之 Gradle 插件
- Gradle 系列之 Java Gradle 插件
- Gradle 系列之 Android Gradle 插件
上篇文章 了解了 Android Gradle 插件的一些配置方法,記得剛開始接觸 Android 中的 build.gradle 配置文件也是一臉懵逼,不知道各個配置項的具體含義,這篇文章將對 Android 開發中一些最基本的配置進行介紹,如果你有這方面的疑惑,相信這篇文章對你有一定收穫
- 默認配置
- 配置簽名信息
- 構建應用類型
- 使用混淆
- 啟用 zipalign 優化
默認配置#
defaultConfig 是 Android Gradle 配置文件中的一個配置塊,defaultConfig 的類型是 ProductFlavor,如果沒有自定義 ProductFlavor,則使用默認的 ProductFlavor 來配置 Android 工程,下面對 defaultConfig 中的一些配置屬性進行介紹:
//默認的ProductFlavor配置塊
defaultConfig {
//配置App的包名
applicationId "com.manu.base"
//配合App最低支持的Android系統版本,下面兩種minSdkVersion的配置效果是一致的
minSdkVersion 19
<!--minSdkVersion 'KitKat'-->
//配置App基於哪個Android SDK開發
targetSdkVersion 26
//配置App的內部版本號,一般用於版本升級
versionCode 1
//配置App外部版本號,該版本號供用戶查看
versionName "1.0"
//配置單元測試時使用的Runner
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
//配置測試App的包名
testApplicationId "com.manu.androidgradleproject.test"
//使用指定的簽名文件配置
signingConfig signingConfigs.release
}
配置簽名信息#
配置 App 簽名信息的好處無非是防止 App 被惡意篡改,簽名可保證 App 的唯一性且只有使用相同簽名的後續升級包才能正常安裝,在創建完簽名文件之後,如果不做配置打包時每次都必須要指定簽名文件的密碼、別名等,一般 App 開發時在 denug 和 release 模式下時配置不同的簽名文件。
第一步:創建簽名證書文件,如下圖所示填寫相關信息:
第二步:使用 signConfigs 配置塊配置已創建簽名證書文件的相關信息如下:
//簽名文件配置
signingConfigs {
release{
//簽名證書文件
storeFile file("project.jks")
//簽名證書文件密碼
storePassword "111111"
//簽名證書密鑰別名
keyAlias "project_jks"
//簽名證書中密鑰密碼
keyPassword "111111"
}
debug{
//默認情況下,debug模式下的簽名已配置為Android SDK自動生成的debug簽名文件證書
//默認簽名文件位置:.android/debug.keystore
}
}
第三步:使用簽名文件配置,在 android {} 下 defaultConfig {} 中使用上述配置,具體如下:
defaultConfig {
//...
//使用指定的簽名文件配置
signingConfig signingConfigs.release
}
除了在 defaultConfig {} 中配置,還可以在分別在 denbug 或者是 release 模式下配置不同的簽名文件,可在 buildTypes {} 中單獨配置,具體如下:
buildTypes {
release {
signingConfig signingConfigs.release
//...
}
debug{
signingConfig signingConfigs.debug
//...
}
//...
}
構建應用的類型#
Android Gradle 內置了兩種構建類型 debug 和 release,兩者區別是前者一般用在調試狀態,後者一般用於正式發布狀態,其他方面都一樣,那麼如何增加新的構建類型呢,可直接在 buildTypes {} 中添加要添加的類型即可,buildTypes 接收的參數是一個域對象,添加的構建類型都是 BuildType,所以可以通過 BuildType 的相關屬性來配置構建類型,下面是 BuildType 的常見的一些配置屬性:
buildTypes {
release {
//...
}
debug{
//配置簽名
signingConfig signingConfigs.debug
//配置在當前構建類型下applicationId的後綴,構建生成Apk的包名會在applicationId的基礎上添加後綴
applicationIdSuffix '.debug'
//配置是否生成一個可供調試的Apk
denbuggable true
//配置是否生成一個可供調試jni(c/c++)代碼的Apk
jniDebuggable true
//是否啟用proguard混淆
minifyEnabled true
//配置當程序中方法數超過65535個時,是否啟用自動拆分多個dex的功能,
multiDexEnabled true
//配置proguard混淆使用的配置文件,可配置對個混淆文件
proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
//配置是否自動清理未使用的資源,默認為false
shrinkResources true
//開啟zipalign優化(見下文)
zipAlignEnabled true
}
}
當在 buildTypes {} 中添加新的構建類型之後,Android Gradle 都會自動生成一個 SourceSet,構建 Apk 會從對應的 SourceSet 中進行構建,切記新構建類型的名稱不能和已有的相同。且要在 src 目錄下為新創建的構建類型添加源代碼目錄和資源文件等,在創建好構建類型的同時,Android Gradle 插件也會生成對應的 assemble 任務來用於構建該類型的項目,如 release 對應的是 assembleRelease,執行該任務會生成對應的 Apk.
使用混淆#
代碼混淆主要了增加反編譯的難度,發布正式版 App 時一般都得進行代碼混淆,實際上 Android SDK 下面已經提供了默認的混淆文件,具體位置在 Android SDK 下面的 tools/progrard 下面,裡面的內容主要是一些最基本的不能混淆的內容,兩個默認的混淆文件如下:
//沒優化
proguard-android.txt
//已優化
proguard-android-optimize.txt
那麼如何使用混淆呢,在 buildTypes {} 中對應的構建類型下設置 minifyEnabled 為 true 開啟混淆,然後配置具體的混淆文件,具體如下:
buildTypes {
release {
//開啟混淆
minifyEnabled false
//配置混淆文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
//...
}
啟用 zipalign 優化#
zipalign 是 Android 提供的一個整理優化 apk 文件的工具,可在一定程度上提高系統和應用的運行效率,更快的讀取 apk 中的資源,降低內存的使用,開啟 zipalign 優化只需要在 buildTypes {} 中對應的構建類型下開啟 zipalign 優化即可,具體如下:
buildTypes {
release {
//開啟zipalign優化
zipAlignEnabled true
//''
}
//...
}
這篇算介紹了 Android 開發中一些常見配置項的介紹,如果感覺有幫助,可以關注或點讚支持一下。