系列文章：
Android的反编译和代码混淆
Android的打包签名
[Android的多渠道打包
前言
本篇包括以下内容：
- 多渠道打包概述
- 友盟的多渠道打包
- 美团的多渠道打包
- 360的多渠道打包
多渠道打包概述
什么是多渠道包
渠道包就是要在安装包中添加渠道信息，也就是channel,对应不同的渠道，例如:小米市场、360市场、应用宝市场等
产品在不同的应用市场可能有不同的统计需求，需要为每个应用市场的Android包设定一个可以区分应用市场的标识，这个为Android包设定应用市场标识的过程就是多渠道打包。
为什么要提供多渠道包
国内存在着有众多的应用市场，产品在不同的渠道可能有不同的统计需求，为此Android开发人员需要为每个应用市场发布一个安装包，这里就引出了Android的多渠道打包。
在安装包中添加不同的标识，应用在请求网络的时候携带渠道信息，方便后台做运营统计。
实现多渠道打包的原理
通过配置gradle脚本实现多渠道打包
这种打包方式是使用Android Studio的编译工具gradle配合使用的，其核心原理就是通过脚本修改AndroidManifest.xml中的mate-date内容，执行N次打包签名操作实现多渠道打包的需求。然后就可以在java中通过API获取对应的数据。
如何实现
现在android渠道多种多样，其实渠道不仅仅局限于应用市场，一种推广方式也可以看做一个渠道，比如：通过人拉人的方式去推广，官网上推广，百度推广等。所以说渠道成千上万，为了推广，有时候一次也会打成千的安装包，那你半天或者一天啥都别干了，所以介绍几个大公司高效的打包方式，借鉴一下。
友盟的多渠道打包
友盟就提供了多渠道打包的方式，可用于渠道统计等。
现在Android的构建工具换成了gradle,通过gradle,简单配置后就可以实现自动打所有渠道包。
补充知识
了解下BuildTypes、Flavors、BuildVariants三个定义：
1、BuildTypes : 构建类型，AndroidStudio的Gradle组件默认提供给了“debug”“release”两个配置。
2、Flavors : 产品渠道，可以根据productFlavors，针对不同的渠道配置个性化apk
3、BuildVariants：每一个buildtype和flavor组成一个buildvariant
友盟打包实现步骤
- 按照umeng的要求，manifest文件中需要有（在application下，和activity是并列关系）：
<meta-data
android:name="UMENG_CHANNEL"
android:value="${UMENG_CHANNEL_VALUE}"/>
这段配置，value那里就是wandoujia，360之类的渠道名称，但是我们在这里不会去写渠道名，写的是一个占位符，后面gradle编译的时候会动态的替换掉它。
- 在module（一般也就是app）的build.gradle的android{}中添加如下内容：
//productFlavors是android节点的一个自节点。你需要打什么渠道的包，就在这里按umeng的要求用渠道名给UMENG_CHANNEL_VALUE赋值。
/*productFlavors {
//方式1：里面是三个渠道
wandoujia {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
}
xiaomi {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
}
yingyongbao {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "yingyongbao"]
}
}*/
//优化1：上面只是三个渠道，如果有几十个渠道，都这样写，重复的东西太多，观察到每个渠道就是flavor的名称，所以修改如下：
/*productFlavors {
wandoujia {
//manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
}
xiaomi {
//manifestPlaceholders=[UMENG_CHANNEL_VALUE: "xiaomi"]
}
}
productFlavors.all { flavor ->
flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
}*/
//优化2：上面经过签名打包后生成的apk的名称是有默认命名规则的，
// 如：xxx-xiaomi-release.apk 但是我们想包含版本信息如：
// xxx-xiaomi-release-1.0.apk,所以最终打包脚本如下：
productFlavors {
wandoujia {
//manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
}
xiaomi {
//manifestPlaceholders=[UMENG_CHANNEL_VALUE: "xiaomi"]
}
}
//如果需要在不同渠道统一配置，使用productFlavors.all字段
productFlavors.all { flavor ->
flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
}
applicationVariants.all { variant ->
variant.outputs.each { output ->
def outputFile = output.outputFile
if (outputFile != null && outputFile.name.endsWith('.apk')) {
def fileName = outputFile.name.replace(".apk", "-${defaultConfig.versionName}.apk")
output.outputFile = new File(outputFile.parent, fileName)
}
}
}
如果没有错误情况，我们会在Android studio的BuildVariant看到对应的渠道，如下图所示：
- 获取渠道
在代码中我们可以通过读取mate-data信息来获取渠道，然后添加到请求参数中，获取方法如下：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
String channel=getChannel();
Toast.makeText(MainActivity.this, "channel==" + channel, Toast.LENGTH_SHORT).show();
}
private String getChannel() {
try {
PackageManager pm = getPackageManager();
ApplicationInfo appInfo = pm.getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
return appInfo.metaData.getString("UMENG_CHANNEL");
} catch (PackageManager.NameNotFoundException ignored) {
}
return "";
}
然后再进行签名
签名配置
签名主要有两种方式：
- 手动签名打包
- 自动签名。
手动签名打包：
使用之前签名的文件，输入密码进行签名打包，如下图
选择打包渠道，如下图
finish后，生成apk文件，如下图
自动签名打包（通过命令的方式进行签名）：
自动签名，是在我们的application中的build.gradle（Module:app），先配置好签名文件信息，我们要先创建好一个签名文件.
（1）加载Key Store:
我们先删掉上面的通过第一种方式所签名的apk文件。接下来进行第二种方式来签名，即命令行的方式。
打开Project Stucture图形化界面：
上图中，选中app这个module，然后切换到signing标签栏，紧接着点击添加，然后生成release签名信息，点击"OK"。
上图中，切换到Build Types标签，将Signing config选择为"release"，即将刚刚生成的release签名信息配置进去。
操作完成之后，我们可以看到app这个module的build.gradle文件多出了如下红框部分的代码：
然后执行菜单栏的"build-clean Project"：
(2)生成realease版本的apk：
在命令行Terminal输入如下命令：（AS已经将命令行Terminal集成到了软件当中）
gradlew assembleRelease
如果运行成功，效果如下：
项目/app/build/outputs/apk目录下
(3)为什么要使用gradlew命令而不是gradle命令：
在项目工程目录下有一个gradle文件夹，在gradle/wrapper目录下有一个gradle-wrapper.properties文件，打开：
上图代表着这个工程所依赖的gradle的版本信息。上图的红线表示，如果我们的工程中没有gradle，软件会根据这个url去下载gradle，终于知道为啥第一次打开AS时会这么慢了吧？
注意如果我们执行了gradlew命令，实际上是执行上面的gradle wrapper，然后找到我们已经下载好的gradle 2.2.1。如果现在有很多个工程，但是每个工程的gradle版本都不一样，我就必须要将每个版本的gradle都要配置到环境变量当中，而执行了gradlew命令，就会避免这个麻烦。
再把安装包在手机上安装即可。
缺点：
这样的打包方式效率比较低下，如果是几十个包还可以应付，打一个包快的话需要十几秒，慢的话需要几分钟不等，跟机器性能很有关系。
美团多渠道打包(速度比较快)
原理
把一个Android应用包当作zip文件包进行解压，然后发现在签名生成的目录下(META-INF)添加一个空文件不需要重新签名。利用这个机制，该文件的文件名就是渠道名。这种方式不需要重新签名等步骤，非常高效。
优点：
这种打包方式速度非常快，900多个渠道不到一分钟就能打完
缺点：
1、google如果哪天更改打包规则，使得在META-INF中建立空文件还需要重新打包，这种方式将不可用
2、一些不法的渠道商很容易通过工具修改渠道，如果一个渠道商，通过网络劫持和篡改渠道的组合方式来获取暴利，对于程序开发者来说可能会存在着巨大的经济损失
如何使用
把需要打包的apk放在一个文件夹PythonTool下：
info文件夹下，czt.txt自动生成：
360多渠道打包（如果打包上百个）
原理
apk文件本质就是zip文件,利用zip文件“可以添加comment（摘要）”的数据结构特点，在文件的末尾写入任意数据，而不用重新解压zip文件，我们就可以将渠道信息写入摘要区
优点:
1、5M的apk，1秒种能打300个
2、在下载apk的同时，服务端可以写入一些信息，例如邀请码，分享信息等
缺点:
渠道信息也是很容易修改，可以加密，相对于美团的方式好一些，只是提高了修改的门槛。
如何使用
360多渠道打包工具放入MCPTool文件夹中
1、将要写入渠道信息的apk放入MCPTool文件夹中
2、修改MCPTool.bat批处理文件，更改渠道和密码（渠道信息为了安全需要加密）
3、将apk拖到MCPTool.bat上执行，将会生成渠道包
4、修改MCPTool-check.bat中的密码和MCPTool.bat中的密码一致
5、将渠道包拖到MCPTool-check.bat上执行，就可以检查渠道信息是否正确
6、获取渠道：将MCPTool.java添加到工程或者将MCPTool.jar导入工程，调用MCPTool.getChannelId(this,"12345678","") 第一个参数为context，第二个是密码，第三个是默认值
MCPTool.bat打包时候用的，生成多个渠道，是加密的，MCPTool-check.bat查看某个信息，是解密的（里面也有密码）
以上是根据我的一些理解，做的总结分享，旨在抛砖引玉，希望有更多的志同道合的朋友一起讨论学习，共同进步！
