walle多渠道打包+Tinker(bugly)热更新集成+360加固(乐固)

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

多渠道打包

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

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

而后在AndroidManifest.xml中定义：

<meta-data
            android: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了，到此整个过程就搞定了，能够拿生成的渠道包分发到各个渠道了。

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