面试的时候，如果面试官突然问到：你们渠道包是怎么打的？如果你说是用gradle一个一个编译的，然后他很鄙视的说这个效率太低啦，你们写过什么脚本自己打渠道包没？你肯定心里想，卧槽，这么狂炫吊炸天，自己写脚本打包？！其实这个根本也不是太难啦！！今天就来聊聊多渠道打包的原理以及如何自己DIY多渠道打包的工具！

渠道包出现

当一个产品到发版的时候，我们搞Android的就会面临一个超级尴尬的问题：国内这么多的渠道，渠道统计是必须做滴，那么十多个主要渠道再加无限量的地推渠道包就成了一个巨坑了！这一块耗费的时间是一个无底洞啊！！！

方式一览

这里一共会介绍三种渠道包的实现方式，分别是：
1、使用gradle配置直接编译出不同的渠道包。
2、通过反编译修改对应的渠道号。
3、META-INF里面新加一个文件。

Gradle方式

不管是用友盟统计还是其他什么的，首先肯定都是要有一些准备工作的，由于本人就比较了解友盟的，所以就用友盟统计来举例啦！
友盟统计提供了两种渠道统计策略，其实就是一个自动挡的一个手动挡的。

在对应的build.gradle里面配置对应的信息：

如果手动去设置对应的渠道号的话，就在程序入口处调用以下方法：

那么怎么获取到对应的渠道号呢？！这个方法在之后的所有方式中都要使用滴，其实不管是哪种方式，最后都会调用这个方法去读相关数据的！！

 buildVariants.png

当然你也可以使用命令行：gradlew assemble 组装出所有的渠道包！！

反编译方式

gradle方式用着也挺不错的，为什么还要去搞什么反编译这么麻烦的东西呢？因为它有一个很大的问题，那就是每一个包都是要去编译打包的！这是相当的耗时！time is 加班啊！谁也不想加班打渠道包咯！！反编译的方式就是节省了每个渠道包都去编译的时间，而是编译好一个渠道包之后就使用该渠道包，通过反编译动态修改AndroidManifest.xml里面的信息，然后再重新打包签名！

说到反编译，那么这里就不得不提大名鼎鼎的apktool.jar了！纳尼，你说你从未听说过？！没事儿，以前没有听过，现在会用了就行了！！

然后总结一下接下来的一系列套路：

解包->修改相关参数->打包->签名->Zipalign优化

• 1、解包

你没有看错，就是这样的！因为我们是站在巨人的肩膀上工作的嘛，所以好多工作就不同自己搞了！

执行以上命令之后，如果不出什么意外，你就会得到一个文件夹：

 

相关代码：

1 2 3 4 5 6 7

try {         brut.apktool.Main.main(new String[]{"d", "-f", apkFilePath, "-o", class="crayon-sy">]{"d", "-f", apkFilePath, "-o",渠道包没？你肯定心里想，卧槽，这么狂炫吊炸天，自己写脚本打包？！其实这个根本也不是太难啦！！今天就来聊聊多渠道打包的原理以及如何自己DIY多渠道打包的工具！ 渠道包出现 当一个产品到发版的时候，我们搞Android的就会面临一个超级尴尬的问题：国内这么多的渠道，渠道统计是必须做滴，那么十多个主要渠道再加无限量的地推渠道包就成了一个巨坑了！这一块耗费的时间是一个无底洞啊！！！ 方式一览 这里一共会介绍三种渠道包的实现方式，分别是： 1、使用gradle配置直接编译出不同的渠道包。 2、通过反编译修改对应的渠道号。 3、META-INF里面新加一个文件。 Gradle方式 不管是用友盟统计还是其他什么的，首先肯定都是要有一些准备工作的，由于本人就比较了解友盟的，所以就用友盟统计来举例啦！ 友盟统计提供了两种渠道统计策略，其实就是一个自动挡的一个手动挡的。 1 2 3 4 5 6 <meta-data         android:name="UMENG_APPKEY"         android:value="xxxxxxxx"/>     <meta-data         android:name="UMENG_CHANNEL"         android:value="${GRADLE_CHANNEL_VALUE}"/> 在对应的build.gradle里面配置对应的信息： 1 2 3 4 5 6 7 8 9 10 11 productFlavors.all { flavor ->     flavor.manifestPlaceholders = [GRADLE_CHANNEL_VALUE: name] } productFlavors {     dev {     }     baidu {         minSdkVersion 18         applicationId "com.test.michat"     } } 如果手动去设置对应的渠道号的话，就在程序入口处调用以下方法： 1 2 3 4 5 6 7 MobclickAgent. startWithConfigure(UMAnalyticsConfig config)   UMAnalyticsConfig(Context context, String appkey, String channelId)   UMAnalyticsConfig(Context context, String appkey, String channelId, EScenarioType eType)   UMAnalyticsConfig(Context context, String appkey, String channelId, EScenarioType eType,Boolean isCrashEnable) 那么怎么获取到对应的渠道号呢？！这个方法在之后的所有方式中都要使用滴，其实不管是哪种方式，最后都会调用这个方法去读相关数据的！！ 1 2 3 4 5 6 7 8 9 10     private String getChannel(Context context) {     try {         PackageManager pm = context.getPackageManager();         ApplicationInfo appInfo = pm.getApplicationInfo(context.getPackageName(), PackageManager.GET_META_DATA);         return appInfo.metaData.getString("CHANNEL_VALUE");     } catch (PackageManager.NameNotFoundException ignored) {     }     return "";   }  buildVariants.png 当然你也可以使用命令行：gradlew assemble 组装出所有的渠道包！！ 反编译方式 gradle方式用着也挺不错的，为什么还要去搞什么反编译这么麻烦的东西呢？因为它有一个很大的问题，那就是每一个包都是要去编译打包的！这是相当的耗时！time is 加班啊！谁也不想加班打渠道包咯！！反编译的方式就是节省了每个渠道包都去编译的时间，而是编译好一个渠道包之后就使用该渠道包，通过反编译动态修改AndroidManifest.xml里面的信息，然后再重新打包签名！ 说到反编译，那么这里就不得不提大名鼎鼎的apktool.jar了！纳尼，你说你从未听说过？！没事儿，以前没有听过，现在会用了就行了！！ 然后总结一下接下来的一系列套路： 解包->修改相关参数->打包->签名->Zipalign优化 1、解包 1 apktool d your_original_apk build 你没有看错，就是这样的！因为我们是站在巨人的肩膀上工作的嘛，所以好多工作就不同自己搞了！ 执行以上命令之后，如果不出什么意外，你就会得到一个文件夹：   相关代码： 1 2 3 4 5 6 7