热修复的两个框架Bugly+Sophix

前几天在一些公众号中看到这两个框架，但是没在意，毕竟我从来没用过热修复，因为根本用不到，我们做的外包，只针对一家，出了Bug及时改并且发布版本（反正是一个没什么前途的app），而且合作方 也默认如此，所以从来没用到过，周日闲的无聊，就先把Sophix看了一下，最终运行成功。
我不说是怎么集成的，毕竟再怎么讲也讲过官方文档还有一些大神的博客，我只说一下我遇到的问题：

官方文档

想了想，Sophix用起来挺傻瓜式的，没什么好讲的，开始配置的时候一个App ID，一个App Secret、RSA密钥他们的位置不好找，在这个位置点击列表的管理就可以看到这三个

这篇从头到尾讲的挺清楚的

在通过新旧包进行对比产生补丁包的时候，我（window版本）只是勾选了日志，并配置了签名，正常；
在用官方提供的测试软件的时候，不管我怎么输入包名都没用，都显示连接不上，然后我就没用这个测试软件，直接上传补丁后下发，然后正常接收，如果有问题

SophixManager.getInstance().setContext(this)
                .setAppVersion(appVersion)
                .setAesKey(null)
                .setEnableDebug(true)
                .setPatchLoadStatusStub(new PatchLoadStatusListener() {
                    @Override
                    public void onLoad(final int mode, final int code, final String info, final int handlePatchVersion) {
                        // 补丁加载回调通知
                        if (code == PatchStatus.CODE_LOAD_SUCCESS) {
                            // 表明补丁加载成功
                            Log.e("ccer", "成功");
                        } else if (code == PatchStatus.CODE_LOAD_RELAUNCH) {
                            // 表明新补丁生效需要重启. 开发者可提示用户或者强制重启;
                            // 建议: 用户可以监听进入后台事件, 然后调用killProcessSafely自杀，以此加快应用补丁，详见1.3.2.3
                            Log.e("ccer", "重启");
                        } else {
                            // 其它错误信息, 查看PatchStatus类说明
                            Log.e("ccer", "other"+code);
                        }
                    }
                }).initialize();

可以在最后的else中打印一下code，对比code码来找原因，这个官方文档有。然后这个没怎么费时间就ok了，当然，我没深入使用，只是简单的试试效果，还不错，然后就无意中看到了费用问题。

价格总览

万一哪天要是做大了，这也是一大笔钱啊；

走，换一家；

今天看的Bugly，用起来挺头疼的，开始集成的时候还好，然后到调整出效果一大堆毛病；

官方文档

正常的集成

thinker-support.gradle

...

/**
 * 此处填写每次构建生成的基准包目录
 */
def baseApkDir = "app-1225-13-47-33"

/**
 * 对于插件各参数的详细解析请参考
 */
tinkerSupport {

   ...

    // 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
//    tinkerId = "base-3.0"
    tinkerId = "patch-3.0-2"

  ...

}

...

其他的都和官网差不多，主要用到的就是这几个参数

在配置混淆规则的时候，要打开混淆

   buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }

不然生成不了app-release-mapping.txt文件；

顺序：
先生成基准包（也就是你要上线的包）

thinker-support.gradle中要更改一下

tinkerId = "base-3.0"

最好base后面跟着版本号

从右往左看，双击assembleRelease，会生成最左侧的那个日期基准包，等下次你要执行这个命令的时候，直接可以在中间那个红框中找到直接执行；现在基准包生成了，准备生成补丁包；

thinker-support.gradle中要更改一下

def baseApkDir = "app-1225-13-47-33"

这个日期要和左侧的那个基准包的日期以及名字要 一样（我这左边有多个，你选择你要上线的那个）

tinkerId = "patch-3.0-2"

这个也要改一下；
然后执行生成补丁，双击buildTinkerPatchRelease

还是从右往左看，双击后，大概3、5秒后生成补丁包，最左边的，下次生成同样可在中间选择

最终提交那个patch-signed_7zip.apk到官网中；

这个才是整个修改后的针对基准包而生成的补丁文件，之前我就搞错了，每次我都是先在手机上运行一遍，然后生成基准包，补丁，压根就不是针对我手机上运行的那个的补丁，所以一直没效果；还有那个tinkerId我也只是改动base后面的数字，直到偶然才换到patch，浪费了不少时间；开始连那两个命令都没找到，找了半天，我还以为那两个命令是在终端执行。。。

还有

public class SampleApplication extends TinkerApplication {
    public SampleApplication() {
        super(ShareConstants.TINKER_ENABLE_ALL, "com.xiey94.bugly.SampleApplicationLike",
                "com.tencent.tinker.loader.TinkerLoader", true);
    }
}

里面的参数看清楚，第三个参数要搞清楚自己的包名，官网给的是xxx.xxx，不要一时眼花看过去了。

在SampleApplicationLike中要配置自己的App ID

    @Override
    public void onCreate() {
        super.onCreate();
        // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
        // 调试时，将第三个参数改为true
        Bugly.init(getApplication(), "App ID", true);
    }

很奇怪，App Key怎么没用到？？？还是只是初始阶段没用到

最后，一切按照官方的来，我的就OK了！

还有一个好消息，就是他不收费。当然还得吐槽一下，它的生效时间有点慢。

（我在xml中放了一个TextView，写到我帅吗？然后补丁改为贼帅，第一遍竟然不出来，我还以为他在质疑自己，终于第二次他遵从了心底的声音，但是这个停顿让我很受打击，这个圣诞节有点不愉快！！！）

多渠道打包官网也有讲：
方法一：gradle配置productFlavors方式[有限制，一次最多五个渠道包]

如果你配置超过5个的话，那么就意味着你要一个补丁，一个补丁上传到Bugly补丁管理后台，况且我们也只允许同时下发5个版本的补丁。这里提一下为什么要上传所有渠道的补丁，因为通过productFlavors配置，会修改buildConfig类中的FLAVOR字段，这会导致生成的不同渠道包的dex是不一样的，所以只能针对具体渠道进行打补丁。这就非常的尴尬了，那怎么办呢？有没有版本通过一个补丁就能够修复所有渠道，答案是：有的，但前提是你要保证所有渠道包代码是一致的。

方法二：多渠道打包、walle

目前只遇到、解决这么些问题，应该是我只处于尝试阶段，所以见识浅短，当我正真用到的时候载深入探究。

值得注意的一点就是他们都有一些限制，当你考虑用到这个的时候，你要考虑清楚它的限制。

---