我们在 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 包对应不同的商店名,然后上传到相应的商店,最后获取这个字符串值返回给后台。那么,本篇关于多渠道打包的内容就这样讲完了。
以上这篇Android 多渠道(友盟)打包教程分享就是小编分享给大家的全部内容了,希望能给大家一个参考。