背景

热修复技术越来越成为一些公司的必备技术点（主要还是主管大大的要求 T.T）。它的优势显而易见，面对突发性BUG时候，相较于传统方式依靠于发新版apk上传到应用市场，无论是对于用户还是开发者而言 都是一次非常糟糕的体验。于是热修复技术应运而生，完美解决突发BUG而不被用户所察觉。（嘻嘻）下面我们来看下阿里最新的热修复技术Hotfix2.0 Sophix的集成使用和项目体验。

先来看一组市面上的几款热修复对比图：

热修复对比  (图片来源阿里百川)

当然，其中的接入复杂度这一条可以无视了，因为每一家的热修复都觉得自己的热修复接入方式比较傻瓜式。（理由大家都懂，hiahia...）其它几条还是具有一定的参考价值的。在之前项目热修复集成过AndFix、HotFix1.0，这次的HotFix2.0(Sophix)的发版给了我们一些全新的体验——图形界面一键打包、加密传输、签名校验和服务端控制发布与灰度功能还是相当强大。

我们可以看看阿里系的新旧热修复对比图:

阿里系热修复对比 (图片来源阿里百川)

Sophix的集成

1.创建APP应用

首先在阿里百川hotfix官方地址创建对应的App，并把生成的 App ID、App Secret、RSA密钥在AndroidManifest.xml里配置一下。

创建应用 minifest文件配置

2.权限配置

权限

3.build.gradle添加依赖。

这里需要注意的地方是传递性依赖utdid这个sdk, 所以不需要重复依赖utdid.但是另一方面其它阿里系SDK也可能依赖了utdid这个SDK, 如果编译期间报utdid重复, 所以此时进行如下处理即可, 关闭传递性依赖:

一般情况下依赖 utdid重复，关闭传递性依赖 maven地址

4.代码中集成

在Application的onCreate里完成初始化工作。

初始化

在启动页或者其它非application位置完成查询补丁包的工作。

查询加载补丁包

这里需要特别注意的一点：关于SophixManager.getInstance().queryAndLoadNewPatch(); 

  i:拉取补丁的代码 不要放置在application中，否则会报异常: java.lang.NoClassDefFoundError;

  ii:当然了，除了这个问题，如果在热修复了一些res或者so文件而且在比较差异包的时候，未勾选强制冷启动，那么也会导致这个NoClassDefFoundError异常。而且会一直crash，直到下个补丁包修复该问题。所以说，安全起见，在比较差异包的时候最好还是强制要求冷启动，这样可以提升安全系数。

5.代码混淆

混淆代码

6.使用图形化比较工具

工具下载地址baichuan.taobao.com/docs/doc.htm

通过下载的比较工具 对比某一相同版本的新旧包。最后生成差异包baichuan-hotfix-patch.jar。

差异包生成工具

7.测试并发布

登录阿里百川hotfix管理后台，上传补丁包baichuan-hotfix-patch.jar。分别进行扫码测试、灰度发布、全量发布三个流程。

8.Sophix项目体验

说说这些天集成Sophix在项目中遇到的坑：

1.android4.X版本热修复后出现各种Crash和ANR的问题。根据提示联系了HotFix官方钉钉群的技术人员也未能解决该问题，他们提供的解决方案亲测无效。如果想尝试使用Sophix热修复可以参考一下这个解决方法。并且目前最新版本的Sophix3.0.2也同样存在该问题。当然，android5.0以上稳定性还是可以得。

2.在部分5.x机型(例如Oppo 5.1)修复成功后会出现Dialog变形的问题。尚未找到官方给出的合理解释。

3.差异包过大的问题。一个很小的改动，动辄几M，对于项目团队来说，耗费流量这一点很难接受。

4.热修复的测试工具扫码不准，经常提示错误信息：请检查AppSecret。 但实际上这些配置参数都是正确的，多次尝试后才能加载补丁包成功，因为这个测试要花费很久，非常影响测试效率。