Android 热修复Bugly和Sophix介绍

最近在学习热修复技术，主流的就是阿里的AndFix基础上开发的商业级框架Sophix和腾讯在tinker基础上开发的商业级框架Bugly，当然热修复都只是两者其中的一部分功能，还有一些其他的功能

一、Sophix

特点：

1、从底层native直接替换原有方法，在原来类的基础上进行修改。核心在于replaceMethod函数，所以只支持方法的替换，对于方法的增删、资源更新、so文件更新、类的属性替换都不支持。
2、可以立即生效，消耗很低，实测上传官网之后可以立即进行修改
3、补丁包很小，下面的就是之前实际测试的补丁包，只是修改了一个方法和布局文件，内部只包含修改的内容，所以补丁包很小

4、由于更换底层native方法，因此对于深度定制的国产机可能存在机型适配问题
5、AndFix只能修复方法的bug，不能修改资源和so文件的bug，并且已经4年多没有更新了，存在兼容问题；Sophix可以修复方法bug、资源、so文件的问题，但是Sophix是收费的，两者接入都是比较简单的，

接入：

根据官网的接入规则接入包，然后使用Sophix提供工具生成修复包，直接上传官网即可https://emas.console.aliyun.com/?current=man#/product/3738229/push/31707161/2

阿里的EMAS移动研发平台提供多个功能

1、移动测试：远程真机测试、运行测试、用例测试
2、移动热修复：热修复，可以过滤版本机型
3、崩溃分析：崩溃、卡顿、异常
4、性能分析：启动速度、页面性能、网络请求、页面加载耗时
5、远程日志：设备的日志
6、移动推送：推送相关信息
7、移动用户反馈：用户反馈
8、移动数据分析：统计用户的信息，包括日活，用户操作日志
9、HTTPDNS：经过阿里云的网络协议解析

二、Bugly

特点：

1、让ClassLoader去加载新的类。这就必须重新启动，而且是冷启动。在没有走到业务逻辑的时候，将变更的补丁和原有的补丁一起组合成新的dex文件，并且将变更的补丁文件放在最前面，这样就能使用补丁文件，而不会继续使用后面的原来文件了，变相达到修复的功能。可以修复各类文件，包括类、资源文件、so文件
2、必须重新启动才能生效，消耗很低，但是生效需要等待十几分钟，而且必须冷启动
3、因为tinker是开源的，之前的用户就很多，文档很多
4、占用内存很大
5、今年被google play封禁了，不给使用热修复功能
6、免费的

接入：

操作步骤参考官网介绍即可：https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20200622202242
搭建的环境（实测有效）：

gradle：3.4.0+5.4.1
as版本：4.1
tinker-support插件版本：1.2.1
classpath "com.tencent.bugly:tinker-support:1.2.1"
tinker版本：1.9.6
// 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）
implementation 'com.tencent.tinker:tinker-android-lib:1.9.6'
bugly版本：
implementation 'com.tencent.bugly:crashreport_upgrade:1.3.5'
implementation 'com.tencent.bugly:nativecrashreport:2.2.0'
multidex版本：
implementation "com.android.support:multidex:1.0.3"

**注意点：**执行补丁任务的时候，是选择tinker-support下的命令buildeTinkerPatchRelease，而不是上面的tinker下面的tinkerPatchRelease，上面的命令生成的不是补丁包，不包含补丁信息，是无法上传的

上传的包也是目录output/patch下的包，而不是output/apk/tinkerpatch下面的包

Bugly提供其他功能：

热更新：app热修复
版本更新：app内置版本更新功能
运营统计：即用户的操作统计数据
异常上报：包括用户的崩溃日志、ANR日志、错误日志
功能相对Sophix来说少了几个，但是满足日常所需了。

三、对比

作为商业级应用，二者热修复功能基本都满足，包括修复类、资源文件、so文件，所以使用全看个人选择了。