背景
热修复技术越来越成为一些公司的必备技术点（主要还是主管大大的要求 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。 但实际上这些配置参数都是正确的，多次尝试后才能加载补丁包成功，因为这个测试要花费很久，非常影响测试效率。
网友评论