Gradle 常用配置總結
這裡分享下我在日常開發中對 Gradle 的常用配置規則
一、版本號配置
當專案逐漸演進的過程中，主工程依賴的 Module 可能會越來越多，此時就需要統一配置各個 Module 的編譯引數了
在工程的根目錄下新建一個 gradle 檔案，命名為 config.gradle ，在此檔案中統一宣告工程的編譯屬性和依賴庫的版本號
ext {
compileSdkVersion = 28
minSdkVersion = 15
targetSdkVersion = 28
versionCode = 1
versionName = '1.0'
dependencies = [
appcompatV7: 'com.android.support:appcompat-v7:28.0.0-rc02',
constraintLayout: 'com.android.support.constraint:constraint-layout:1.1.3',
junit: 'junit:junit:4.12',
testRunner: 'com.android.support.test:runner:1.0.2',
espressoCore: 'com.android.support.test.espresso:espresso-core:3.0.2'
]
}
預設情況下， App Module 的 build.gradle 檔案的預設配置如下所示
apply plugin: 'com.android.application'
android {
compileSdkVersion 28
defaultConfig {
applicationId "leavesc.hello.gradlesamples"
minSdkVersion 15
targetSdkVersion 28
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:28.0.0-rc02'
implementation 'com.android.support.constraint:constraint-layout:1.1.3'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}
這裡將其改為引用 config.gradle 檔案的形式
首先，需要在根目錄下的 build.gradle 檔案中應用 config.gradle 檔案，這樣在 Module 配置檔案中才引用得到當中的屬性值
此時就可以修改應用版本號以及依賴庫的宣告方式了
apply plugin: 'com.android.application'
def globalConfiguration = rootProject.ext
def presentationDependencies = globalConfiguration.dependencies
android {
compileSdkVersion globalConfiguration["compileSdkVersion"]
defaultConfig {
applicationId "leavesc.hello.gradlesamples"
minSdkVersion globalConfiguration["minSdkVersion"]
targetSdkVersion globalConfiguration["targetSdkVersion"]
versionCode globalConfiguration["versionCode"]
versionName globalConfiguration["versionName"]
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
implementation fileTree(include: ['*.jar'], dir: 'libs')
implementation presentationDependencies.appcompatV7
implementation presentationDependencies.constraintLayout
testImplementation presentationDependencies.junit
androidTestImplementation presentationDependencies.testRunner
androidTestImplementation presentationDependencies.espressoCore
}
這樣，即使以後工程中包含多個 Module ，只要配置的屬性都是來自於 config.gradle 檔案，就可以做到統一修改編譯屬性與依賴庫版本了
二、簽名屬性配置
通常，應用的簽名型別會分為 release 和 debug 兩類，並分別使用不同的簽名檔案
為了安全考慮以及實現自動化打包，可以通過 gradle 來宣告簽名配置，包括簽名檔案路徑、簽名別名、簽名密碼等
在 local.properties 檔案中宣告簽名檔案路徑以及簽名密碼
sdk.dir=C\:\\Software\\SDK key.keyStorePath=..\\doc\\key.jks key.keyAlias=leavesC key.keyPassword=987654321 key.storePassword=123456789
根據配置可知，簽名檔案是放在工程的 doc 資料夾內
通過程式碼獲取到簽名的各個配置項
Properties properties = new Properties()
properties.load(project.rootProject.file('local.properties').newDataInputStream())
def keyStorePath_ = properties.getProperty("key.keyStorePath")
def storePassword_ = properties.getProperty("key.storePassword")
def keyAlias_ = properties.getProperty("key.keyAlias")
def keyPassword_ = properties.getProperty("key.keyPassword")
def storeFile_ = file(keyStorePath_)
配置不同的簽名屬性以及 build 型別
signingConfigs {
release {
storeFile storeFile_
storePassword storePassword_
keyAlias keyAlias_
keyPassword keyPassword_
v1SigningEnabled true
v2SigningEnabled true
}
debug {
storeFile storeFile_
storePassword storePassword_
keyAlias keyAlias_
keyPassword keyPassword_
v1SigningEnabled true
v2SigningEnabled true
}
}
buildTypes {
debug {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug
}
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
此處，我配置了兩種不同的 buildType ： debug 、 release ，並對應不同的簽名檔案
以後只要選定不同的 Build Variant ，即可打包具體簽名的 Apk 檔案
而 local.properties 檔案可以儲存到伺服器來實現遠端打包，從而保證了隱私安全
三、多渠道打包
有時候，為了方便進行精準營銷，會有生成不同渠道包的要求，此時就需要在同個應用上打上不同的渠道ID（channelId），這可以通過 productFlavors 來實現
先在 AndroidManifest.xml 檔案中配置佔位符， appKey 即對應各個渠道的 ID 值
<meta-data android:name="APP_KEY" android:value="${appKey}" />
在 gradle.properties 檔案中宣告需要的 ChannelId 以及對應的 ApplicationId ，在此檔案中宣告的屬性可以直接在 build.gradle 中直接獲取到
#預設配置 defaultApplicationId=leavesc.hello.gradlesamples ##各個渠道的配置 #應用寶 yingyongbaoChannelId="yingyongbao" yingyongbaoApplicationId=leavesc.hello.gradlesamples.yingyongbao yingyongbaoAppKey=appKey_yingyongbao #豌豆莢 wandoujiaChannelId="wandoujia" wandoujiaApplicationId=leavesc.hello.gradlesamples.wandoujia wandoujiaAppKey=appKey_wandoujia #小米 xiaomiChannelId="xiaomi" xiaomiApplicationId=leavesc.hello.gradlesamples.xiaomi xiaomiAppKey=appKey_xiaomi
productFlavors 可以理解為是對同個產品的不同“風味要求”，可以根據配置項生成特定風味的產品（App）
例如，此處就為不同渠道設定了不同的 applicationId
buildConfigField 屬性則用於在 BuildConfig.java 檔案中生成特定型別的欄位，此處就生成了一個型別為 String ，名為 channelId 的欄位，用於方便在應用執行過程中判斷當前應用的渠道型別
manifestPlaceholders 就是用於替換 AndroidManifest.xml 檔案中的指定佔位符了
productFlavors {
yingyongbao {
applicationId yingyongbaoApplicationId
buildConfigField "String", "channelId", yingyongbaoChannelId
manifestPlaceholders = [appKey: yingyongbaoAppKey]
}
wandoujia {
applicationId wandoujiaApplicationId
buildConfigField "String", "channelId", wandoujiaChannelId
manifestPlaceholders = [appKey: wandoujiaAppKey]
}
xiaomi {
applicationId xiaomiApplicationId
buildConfigField "String", "channelId", xiaomiChannelId
manifestPlaceholders = [appKey: xiaomiAppKey]
}
}
在主佈局檔案中展示當前應用的各項屬性值
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
StringBuilder sb = new StringBuilder();
sb.append("ApplicationId: ");
sb.append(getApplicationInfo().packageName);
sb.append("\n");
sb.append("ApplicationName: ");
sb.append(getString(getApplicationInfo().labelRes));
sb.append("\n");
sb.append("ChannelId: ");
sb.append(BuildConfig.channelId);
sb.append("\n");
try {
ApplicationInfo appInfo = getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
String appKey = appInfo.metaData.getString("APP_KEY");
sb.append("AppKey: ");
sb.append(appKey);
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
TextView tv_appInfo = findViewById(R.id.tv_appInfo);
tv_appInfo.setText(sb);
ImageView iv_log = findViewById(R.id.iv_log);
iv_log.setImageResource(getApplicationInfo().icon);
}
四、打包時指定 Apk 名字
為了方便標識各個測試包的版本已經打包時間，可以通過 Gradle 來指定生成的 Apk 檔案的命名規則
例如，以下配置就根據 buildType、flavorName 和 編譯時間 來命名 Apk 檔案
applicationVariants.all { variant ->
def buildType = variant.buildType.name
def flavorName = variant.flavorName
def createTime = new Date().format("YYYY-MM-dd_hh_mm_ss", TimeZone.getTimeZone("GMT+08:00"))
variant.outputs.all {
outputFileName = flavorName + "_" + buildType + "_v" + defaultConfig.versionName + "_" + createTime + ".apk"
}
}
五、生成屬性欄位與資原始檔值
上邊講過， buildConfigField 屬性可用於在 BuildConfig.java 檔案中生成特定型別的欄位，此處可以利用其來記錄應用的編譯時間
此外，也可以利用 resValue 來生成一個 ID 引用型別的 string 字串
首先，宣告兩個方法，分別用於獲取當前時間以及當前電腦的使用者資訊
static def buildTime() {
return new Date().format("yyyy-MM-dd HH:mm:ss")
}
static def hostName() {
return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
}
defaultConfig {
applicationId defaultApplicationId
minSdkVersion globalConfiguration["minSdkVersion"]
targetSdkVersion globalConfiguration["targetSdkVersion"]
versionCode globalConfiguration["versionCode"]
versionName globalConfiguration["versionName"]
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
flavorDimensions '1'
resValue "string", "build_host", hostName()
buildConfigField "String", "build_time", "\"" + buildTime() + "\""
}
用程式碼來獲取這兩個屬性值
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
StringBuilder sb = new StringBuilder();
sb.append("ApplicationId: ");
sb.append(getApplicationInfo().packageName);
sb.append("\n");
sb.append("ApplicationName: ");
sb.append(getString(getApplicationInfo().labelRes));
sb.append("\n");
sb.append("ChannelId: ");
sb.append(BuildConfig.channelId);
sb.append("\n");
sb.append("BuildTime: ");
sb.append(BuildConfig.build_time);
sb.append("\n");
sb.append("BuildUser: ");
sb.append(getString(R.string.build_host));
sb.append("\n");
try {
ApplicationInfo appInfo = getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
String appKey = appInfo.metaData.getString("APP_KEY");
sb.append("AppKey: ");
sb.append(appKey);
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
TextView tv_appInfo = findViewById(R.id.tv_appInfo);
tv_appInfo.setText(sb);
ImageView iv_log = findViewById(R.id.iv_log);
iv_log.setImageResource(getApplicationInfo().icon);
}
六、替換資原始檔
在多渠道打包時，除了需要在應用中打上特定的標籤外，也可能需要使之使用不同的資原始檔，例如應用圖示和應用名稱
此時可以以各個 productFlavor 的名稱來命名相應的資料夾，並在其中放置相應的圖示檔案以及聲明瞭應用名稱的 string.xml 檔案，這樣在多渠道打包時，Gradle 就會自動引用相應的資原始檔
上述所有的示例程式碼可以在這裡獲取： ofollow,noindex" target="_blank">GradleSamples
更多的讀書筆記可以看這裡： Java_Kotlin_Android_Learn" rel="nofollow,noindex" target="_blank">一份關於 Java 、Kotlin 、 Android 的學習筆記