android打包之重叠包技术浅谈

转载请注明出处

http://blog.csdn.net/BruceHurrican/article/details/51755194

一个app经过几个大版本迭代后都会遇到一个问题，越来越臃肿，但是本文不是讲怎样给app瘦身的方法。本文仅当本人之工作手记罢了。主要记录我在项目中遇到的问题及解决办法。

先说问题吧。业务需要将现有app中部分组件单独抽出作为公共组件和商业组件分别提供给公司内部其他app使用和潜在合作方使用。

之前准备采用类似友盟的多渠道打包技术，主要是修改app.gradle中的productFlaors函数（相关技术方法请参考网上资料），而我和同事在项目中用到的是重叠包技术和多渠道打包技术，其在工程中的分包结构和多友盟多渠道打包技术很像。

代码如下：

app.gradle
productFlavors {
tt {
applicationId 'com.bruce.demo.tt'
minSdkVersion 15
targetSdkVersion 23
signingConfig signingConfigs.release
}
tt2 {
applicationId 'com.bruce.demo.tt2'
minSdkVersion 15
targetSdkVersion 23
signingConfig signingConfigs.debug
}
}

这主要是根据productFlavors来打多渠道包，用在我的项目是需求为通过设置productFlavor来将打公共组件包、潜在合作方包、项目自用包。刚开始我是按照这个思路来进行的，但是随着工作的进行，发现将要抽离的组件与其他module之间的耦合性太高，代码之间的侵入性太强抽离难度太大，无奈此种方案在经过技术论证后，不适合当前公司复杂的app 架构，放弃。

此路不通只能另辟蹊径了，通过查 gradle资料 发现可以通过增加buildTypes来增加构建类型，buildTypes 按照字面中文翻译不正是构建类型吗？之前居然没有注意到T_T。

dmeo工程目录如下：





blue 和 red 就是我要的两个具有各自独立业务的模块，可以理解为上面的公司用组件和潜在合作方组件。

关键代码如下：

buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
minifyEnabled false
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
blue {
applicationIdSuffix 'blue'
versionNameSuffix 'blue'
}
red {
applicationIdSuffix 'red'
versionNameSuffix 'red'
}
}

通过AS上的 BuildVariants 在types之前切换



这样就可以打出多个包了并进行相应的代码修改，如果设置多BuildTypes不是app工程而是一个lib的话，即此lib要根据不同的需求提供给不同的业务方，一个一个切换再打包是很麻烦的，可以通过gradle脚本来生成相应的lib包，



也可以通过输入命令

gradle assembleBlue
gradle assembleRed

注意

通过AS这种方法生成的是aar包，关于aar在AS的使用此文略去不表。

作为公共入口LibActivity在主目录即main文件夹下不能存在否则报错。

如果各业务模块使用各自的依赖则应在申明中分别申明不应笼统的申明为compile以免增大安装包的体积



到此，通过增加buildtypes的方法来达到生成不同需求的app/lib的要求已经达到了，各个业务需求可以在相应的blue、red下去实现。

小结如下：

如果需要替换相同资源如首发icon图片，字段名，可以考虑多渠道打包技术，各个模块之间没有代码侵入或者侵入性低。

如果业务模块blue、red对main目录下的代码依赖性强，并且有引用到其他模块的话，非业务模块间有相互依赖的话，考虑使用重叠包技术。

demo下载

如果文中有什么不对的地方或者您有更好的建议欢迎不吝赐教。