目 录
©本文由博主原创，未经允许，不得转载相关博文内容
-
介绍
我们在 app 正式发布的时候一定会使用正式签名的方式来打包，这种方式只能生成唯一的一个包，但是如今的应用商店非常多，如：小米、OPPO、360、百度、豌豆荚、应用宝等等。而我们只有一个 apk 文件要投入到这么多的应用商店中去，如果你的公司不需要统计每个应用商店的实际下载使用量的话，那倒是不会有这样的问题。
但是，如果你的公司就是需要统计每个商店的实际下载使用情况，那么你将如何去识别当前用户是从哪一个商店下载来的呢？出现问题原因是：我们使用的 apk 安装包当前仅有一个。
假设，我们可以向 apk 内植入一个字符串，比如我给发布到小米商店的 apk 中植入“xiaomi” ，然后拷贝一份 apk 安装包发布到小米商店中，给百度植入“baidu”，然后也拷贝一份发布到百度商店中，然后通过 JAVA 代码在用户从某一个商店中下载并使用时，我获取这个字符串，然后返回给后台，这不就可以知道用户从哪个商店下载了吗！
-
多渠道
多渠道就是指我们的应用程序可以从不同的商店下载，不同的应用商店就是不同的渠道。那你可能会有疑惑，我们为什么要知道用户从哪个渠道下载的呢？
这个问题其实与利益息息相关，你这样想。假如你写一个 app 发布到不同的商店上，你肯定会关注究竟哪一个商店的用户使用量比较多、下载量比较大的问题，你可能手头没有那么多经济去每一个商店平台都推广你的 app ，所以你要记录哪个商店用户量最大，然后着重推广。
-
友盟
说了这么多，相信你已经明白多渠道打包的重要性了。既然我们可以向每一个 apk 中植入一个标志这商店名称的字符串，那么如果一个一个的来的话，显然是一个庞大的工作，没有多大实际意义，而且 apk 文件是无法直接向里面添加一个外部文件的，你需要其他的手段来实现，那么我们先来看友盟多渠道打包的方式。
友盟的实现方式是通过 xxx.keystore 文件来进行一个一个的压包，通过代码的方式来分别生成一个你指定的应用商店的对应 apk 文件。这种方式会比较慢，如果你的需求是要投入到几百上千个商店的话，显然生成文件的速度会非常慢。但如果你的需求量在几十上百，我建议你可以使用友盟来打包，公司也通常使用这种方式。
那么我们看看如何实现吧！
一、引入友盟支持
在工程列表（AndroidManifest.xml）文件中加入友盟提供的支持，这个与 Activity 并列层级。
<!-- 添加友盟支持 -->
<meta-data android:value="${UMENG_CHANNEL_VALUE}" android:name="UMENG_CHANNEL"/>二、添加闭包
然后在 app 的 build.gradle 中添加以下代码，目的是为了生成对应的应用商店的 apk ，添加位置在 android 闭包下，以下代码不难理解。
注意：在 gradle 中是无法使用数字开头的名字，所以你应该懂得变更一下。
//友盟闭包
productFlavors {
wandoujia {}
xiaomi {}
baidu {}
yingyongbao {}
//注意 360：gradle 中不能以数字开头
_360{}
}
productFlavors.all { flavor ->
flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
}这里注意一下，也许你会报这个错误：ERROR: All flavors must now belong to a named flavor dimension.
解决方法就是在上面的 defalutConfig 闭包中添加内容：flavorDimensions "versionCode"
然后再同步一下就没有问题了。
三、签名打包
接下来就是打包的过程了，很简单，我们只需要选中如下图中的各个应用商店的版本即可，然后它就会在你设定的目录下生成对应的 apk 文件了。
如果对签名打包不懂的可以看这篇博文：Android App正式签名打包流程
这就是我的项目生成的对应的 apk 文件所在的文件夹，点进去就会看到安装包啦。
四、添加版本号
当然了，你可能希望加入当前 app 的开发版本号，这样就对每个版本升级时所用的 apk 包就一目了然了。这是你需要把当前 app build.gradle 中的 deflautConfig闭包下的 versionName 给设置到打包生成的 apk 名中。那代码是这样的：
//为多渠道包添加 app 版本号
applicationVariants.all { variant ->
variant.outputs.all { output ->
def outputFile = output.outputFile
if (outputFile != null && outputFile.name.endsWith(".apk")) {
def fileName = outputFile.name.replace(".apk", "-${ defaultConfig.versionName }.apk")
outputFileName = fileName;
}
}
}这是一段 groovy 语言，通常在 jvm 中使用，可以很好的和 java 代码配合。你只需要将它添加到刚刚写的友盟闭包后面就可以了，如这样：
然后你再一次打包一下，就可以在目录中看到 apk 文件了，一个是刚刚没有添加的默认版本，一个是拥有版本号。
注意：这里会有一个警告信息，内容是这样：
WARNING: API 'variantOutput.getPackageApplication()' is obsolete and has been replaced with 'variant.getPackageApplicationProvider()'.It will be removed at the end of 2019.
它是说这个 API 在 2019 年末将要被替换成后面的一个，不过别担心，只要你在升级 gradle 的时候注意一下就好了，在未来它要被替换的时候，你也要做出相应的更改！
五、获取渠道信息
到目前为止，我们还没真正的看到这样打包有什么用处。不着急，我们需要将每个 apk 文件发布到对应的商店以后才需要获取这个字符串，这样才能够真正的识别用户在哪个商店中下载来的，然后在用户使用量最大的商店中去大力推广。那么如何获取这个字符串呢？
我就简单一点，在 MainActivity 中直接获取这个字符串了，在实际开发中，显然是要把这个信息传给后台进行统计的，不然没有任何意义。我们的获取代码如下：
还记得我们在 meta-data 中定义了 UMENG_CHANNEL 属性的名字吗，现在我们就可以利用它来获取 字符串 了。
import android.content.Context;
import android.content.pm.ApplicationInfo;
import android.content.pm.PackageManager;
public class ChannelUtil {
public static String getChannel(Context context) {
PackageManager pm = context.getPackageManager();
ApplicationInfo appInfo = null;
try {
appInfo = pm.getApplicationInfo(context.getPackageName(), PackageManager.GET_META_DATA);
return appInfo.metaData.getString("UMENG_CHANNEL");
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
return "";
}
}然后我在启动 app 的时候使用 toast 验证一下是否如我们想象的一样：
结果没错，相信大家已经明白了多渠道打包的作用了，它的本质就是在签名打包的时候嵌入一个字符串，通过不同的 apk 包对应不同的商店名，然后上传到相应的商店，最后获取这个字符串值返回给后台。那么，本篇关于多渠道打包的内容就这样讲完了。
©原文链接：https://blog.csdn.net/smile_Running/article/details/88076069
©作者博客 ID：smile_running