在build.gradle里面通过productFlavors就可以方便的实现不同的编译方案。
flavorDimensions定义维度
flavorDimensions 从单词字面理解知道是 “风味维度”,是需要结合 “产品风味(即productFlavors)” 来一起使用的。flavorDimensions 的使用会定义出维度,供接下来的 productFlavors 使用。
android {
// 省略其他参数
flavorDimensions('abi', 'version')
}
使用上面代码,则会定义出两个维度:version 和 abi。一个参数一个维度。
productFlavors的意义
productFlavors 从字面了解是“产品风味”。他需要和一个风味维度对接,否则会报错。
android{
// ...
flavorDimensions('abi', 'version')
// 创建产品风味
productFlavors {
v1 {
// 关联纬度
dimension 'version'
}
v2 {
dimension 'version'
}
x86 {
dimension 'abi'
}
armV7 {
dimension 'abi'
}
}
}
在 abi 维度上关联了两个产品,即 “armV7” 和 “x86”,在 version 的维度上关联了两个个产品,而这些维度的交织就会形成最终的风味,即我们上面所标出来的 “armV7V1”、“armV7V2”、“x86V1”、“x86V2”。
我们可以根据不同的风味,打出不同的apk包,便可以实现一套核心代码打出多个有些差异的包。
我的flavorDimensions & productFlavors
我的项目对abi不区分,只需要区分高通和mtk,所以维度就只定义了platform,cmake部分针对qcom和mtk分别定义了不同的宏,还可以指定其他native的参数。
flavorDimensions "platform"
productFlavors {
// Qualcomm platform
qcom {
dimension "platform"
externalNativeBuild {
cmake {
cppFlags "-std=c++11"
arguments "-DCMAKE_BUILD_TYPE=Release",
"-DUSE_QCOM=TRUE"
}
}
}
// mtk platform
mtk {
dimension "platform"
externalNativeBuild {
cmake {
cppFlags "-std=c++11"
arguments "-DCMAKE_BUILD_TYPE=Release",
"-DUSE_MTK=TRUE",
"-DCMAKE_ANDROID_NDK=\$(System.getenv('ANDROID_NDK_HOME'))"
}
}
}
}
实验证明上面的"-DCMAKE_ANDROID_NDK=$(System.getenv('ANDROID_NDK_HOME'))"不生效的。换成"-DANDROID_NDK=/home/tools/android-ndk/android-ndk-r19c"这样的绝对路径也不行。
只有通过修改local.properties才可以,可以通过编译脚本修改ndk.dir。
#!/usr/bin/env bash
#set build ndk to android-ndk-r19c
ndkdir=${ANDROID_NDK}
echo "ndk.dir=${ndkdir}" >> local.properties
# clean
./gradlew clean
# build snpe
./gradlew assembleqcomRelease
# build mace
./gradlew assemblemtkRelease
参考:
https://blog.csdn.net/weixin_37625173/article/details/100867037