看到这里的小伙伴，就默认你们已经接入了Bugly热更新和Walle多渠道打包，下面这篇文章就开始介绍应用加固解决方案。
二、Bugly热更新+Walle（瓦力）多渠道打包解决方案
三、Bugly热更新+Walle（瓦力）多渠道打包+应用加固解决方案
先说明：这里的应用加固方案是有缺陷的，具体是因为我的使用姿势不对，还是Walle多渠道打包存在缺陷，还是因为别的什么原因，目前我还不得而知，现在我只能记录下我的使用历程，供你们参考，谁有更好的解决方案，也欢迎补充。
先说我实现了的，bugly热更新+Walle多渠道打包+应用加固均已实现：
1、能实现一个补丁修复所有渠道
2、应用加固（使用了360加固和乐固）
3、应用加固后仍能实现一个补丁修复所有渠道
4、渠道统计（Bugly统计）能统计到使用Walle多渠道打包但是不经过应用加固的渠道
再说存在的缺陷：
渠道统计（Bugly统计），统计不到采用应用加固后的渠道的新增用户（能统计到使用用户）
如下图：
问题抛出，说下我的实验过程，Bugly热更新+Walle多渠道打包不存在任何问题，主要是应用加固，我采用了两种方案：
1、多渠道打包后，直接把渠道包用应用加固工具（360加固和乐固）加固（使用应用加固工具提供的自动签名工具）
2、先生成基线版本包，再使用应用加固工具加固，但是不使用加固工具提供的自动签名工具，然后使用Walle提供的关于360加固失效解决方案重新签名360加固失效？我使用了ProtectedApkResignerForWalle方案
关于ProtectedApkResignerForWalle的使用大家只要把这个工具下载下来，配置一下python环境，按照上面文档操作就行了，这里简单说一下：
1、config.py里的信息只需要修改以下几点，其他的保持默认就好
#keystore信息
#Windows 下路径分割线请注意使用\转义
keystorePath = “…path/your.keystore”
keyAlias = “your keyAlias”
keystorePassword = “your keystorePassword”
keyPassword = “your keyPassword”
#加固后的源文件名（未重签名）
protectedSourceApkName = “your protected.apk”
#Android SDK buidtools path , please use above 25.0+
#这是你的Android Sdk的build tools的路径，建议25.0以上
sdkBuildToolPath = “/Users/mac/Library/Android/sdk/build-tools/26.0.2”
2、在执行python ApkResigner.py命令时， 不要直接输入python ApkResigner.py命令，而要输入ApkResigner.py的绝对路径，比如：python E:/walle/ProtectedApkResignerForWalle-master/ApkResigner.py
关于配置python环境，欢迎参考：Windows配置python3.7.2环境
关于应用加固工具，相信不用我多啰嗦了吧。
下面说下我采用了两种方案后的结果：
采用第一个方案后：
Bugly统计完全统计不到渠道信息
采用第二个方案后：
Bugly统计，统计不到采用应用加固后的渠道的新增用户（能统计到使用用户），见上图
上面两种方案我也都接入了友盟统计，但是不管哪种方案，友盟统计都统计不到相关的渠道信息
String channel = WalleChannelReader.getChannel(getApplication());
/*
注意: 即使您已经在AndroidManifest.xml中配置过appkey和channel值，
也需要在App代码中调用初始化接口（如需要使用AndroidManifest.xml中配置好的appkey和channel值，
UMConfigure.init调用中appkey和channel参数请置为null）。
*/
UMConfigure.init(getApplication(), "YOUR_APPKY", channel, UMConfigure.DEVICE_TYPE_PHONE, null);
对了，要使用应用加固的话需要把tinker-support.gradle中的isProtectedApp 设为 true
// 是否使用加固模式，默认为false
isProtectedApp = true
关于热更新+多渠道打包+应用加固的方案就到这里了，由于本菜水平有限，并不能完美解决，欢迎各位大佬批评指正！