这三个东东是干啥的相信大家都有所耳闻了，如果你没有听说过，请出门左拐，百度一下你就知道。这里不对这三个东东具体的集成方式做详细的介绍，因为官方文档已经写的很详细了，主要是对同时使用这三个东东时所需要注意的关键点进行填坑。

多渠道打包

项目原本使用的打包方式是传统的方式，相信大家都知道的，就是通过build.gradle中定义好各个渠道：

productFlavors {yingyongbao {manifestPlaceholders = [UMENG_CHANNLE: "yingyongbao"]}baidu {manifestPlaceholders = [UMENG_CHANNLE: "baidu"]}}

然后在AndroidManifest.xml中定义：

 <meta-dataandroid:name="UMENG_CHANNEL"android:value="${UMENG_CHANNEL}" />

然后执行打包命令后就是漫长的打包等待....
差不多每次打包都要花费1，2个小时(我们每次差不多打20个包?)...，然后就是对每个包进行360加固，这个时间看网速，差不多也是1，2个小时...

然而最无奈的是想集成Tinker的时候，sorry，Tinker不支持这种打包方式....?
Tinker推荐了新一代的打包工具walle，walle是什么？
传送门：https://github.com/Meituan-Dianping/walle
walle怎么集成官方文档已经说的很清楚了，我在这里就不在累述了。。

关键点是(敲黑板)：如果你集成了Umeng等第三方的数据统计SDK，可以通过代码设置，而不再通过定义meta-data的方式。Umeng的方式如下：

String channel = WalleChannelReader.getChannel(mApplication,"Official");
MobclickAgent.startWithConfigure(new MobclickAgent.UMAnalyticsConfig(mApplication,"key id",channel));

walle集成好后打渠道包试一下，这速度简直不是一个数量级的...

Tinker热更新集成

为了更新方便，我这里使用的bugly，这样不用自己搭建服务器管理补丁，同时bugly自带了应用的升级功能，还是比较方便的。bugly的集成相对来说稍微复杂一些，主要是要细心，特别是测试的时候，要反复改一些东西，这里我花了挺多时间。。。 官方文档链接：
传送门: https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20180521124306

关键点：主要是tinker-support.gradle中的配置，最重要的有几点：

• 1. tinkerId的配置，一般是定义成版本号，基线版本一般是base-version，补丁一般是patch-version(其中version对应你自己的版本号)，在发版的时候一定要记得修改这个值，bugly会根据这个来匹配对应补丁的版本的。
• 1. baseApkDir的配置，这个参数是打补丁的时候才用到，打基线版本的时候这个是没用的，我就是这个参数没理解，不知道干啥用的，后来试了几次后才知道。在打包的时候tinker会在module的build/bakApk/目录下生成基线版本(文件夹名称是应用名称-打包时间)，还有R文件和mapping混淆文件(如果你的应用使用了混淆), 记得把这些文件进行保存，在打补丁包的时候会需要这些文件。
     在需要打补丁的时候，在module的build下新建bakApk文件夹，然后在bakApk文件夹下新建一个文件夹，比如v1.0.0，这个可以自定义，然后将基线版本文件，包括R文件和mapping混淆文件拷贝到这个文件夹下，然后将baseApkDir参数改为你自定义的文件名，这个时候baseApkDir这个参数才有用，记得要保证配置的baseApk，baseApkProguardMapping，baseApkResourceMapping与你拷贝进去的文件名路径一致，否则编译的时候会出错，然后修改tinkerId为patch-version，之后就可以运行tinker-support的buildTinkerPatchRelease task。注意：是tinker-support下不是tinker下。
     
     运行完成后会在build/outputs/patch/release/下生成几个文件，将patch_signed_7zip.apk文件上传到bugly热更新后台，下发补丁即可。
     

到这里tinker也算集成好了，然后就是打开APP测试一下，可以通过logcat查看补丁是否合并成功。

360加固(腾讯的乐固也可以的)

现在基本每个上线的应用都不会裸奔了，都会选择各种加固，具体的加固方法很简单，只需要上传apk包到后台，然后加固好后重新下载过来签名就可以了。 这里不做详细的介绍了...

如果walle和tinker都已经集成好了，那么恭喜你，还有另外一个坑等着你....
当你使用walle打了渠道包后进行加固签名，你会发现写入的渠道信息丢失。。。 不要怀疑这不是你的姿势不对，加固重新签名后渠道信息会丢失，同时加固签名后tinker热更新也无效了，logcat中会提示合并失败了... WTF? 莫鸡冻，解决办法还是有的，这里要使用到一位大神的工具了：
传送门 https://github.com/Jay-Goo/ProtectedApkResignerForWalle
这个工具是专门解决360加固后渠道丢失问题的。

下面开始解决问题：

• 1. 开启tinker的加固支持，默认是关闭的。打开tinker-support.gradle，设置isProtectedApp = true(默认是被注释了，取消注释即可)。
• 1. 不再使用walle的./gradlew clean assembleReleaseChannels生成各个渠道包，而是使用./gradlew clean assembleRelease生成基线版本包。
• 1. 生成的基线版本包就是在集成tinker提到的基线包，一般在build/bakApk/应用名-时间的文件夹下，将基线版本包上传到360后台进行加固，加固好后下载下来，不要进行签名，要通过上面提到的工具进行签名。
• 1. 将 https://github.com/Jay-Goo/ProtectedApkResignerForWalle 工具下载下来，将集成walle时候配置的channel文件拷贝到根目录，将下载的加固后的apk也拷贝的根目录下，按照官方文档修改配置文件，配置秘钥和文件路径信息，注意配置的sdkBuildTool的路径，这是你的Android Sdk的build tools的路径，建议25.0以上。配置好后运行命令：
     python ApkResigner.py
     这个过程很快，只需要几秒钟，成功后会有提示，会在根目录下生成channels文件夹，该文件夹下的就是生成好的各个渠道包了。 该渠道包已经完成了签名和渠道写入，同时可以支持tinker热更新了?

OK了，到此整个过程就搞定了，可以拿生成的渠道包分发到各个渠道了。

很少写博客，写的不好还请大路大神不吝赐教，还有不明白的给我留言讨论吧...