热修复Sophix的爬坑之路

写该篇博客就是为了总结下使用Sophix的过程中碰到的一些Bug及爬坑过程，希望各位极客还没碰到，看了我的回顾总结后能对可能出现的困惑有帮助。

爬坑之路会 随着路程越远逐步完善

坑一：AndroidX 不兼容

开发环境

win10 + android studio 3.5.1 + gradle-5.4.1 + 设备API 5.1.1 + jdk1.8+ alicloud-android-hotfix:3.2.10

爬坑过程

这个Bug简单来说就是3.2.10的时候Sophix还不支持androidx，使用了Androidx的Android5.1.1在进行resource 资源更新是就会报如图错误。

最终的解决方法是通过我的坚持，Sophix最终进行修改优化兼容Androidx。版本升级为3.2.12后支持了Androidx。心酸过程让我一一道来。

我这个人有升级狂魔症，经常喜欢升级依赖，Gradle、插件等，反正只要能更新的，能升级的我都要立马升级，更新，因此踩了不少的坑，碰到了不少的雷。本着我不入地狱谁入地狱的精神，依然一往无前，乐此不疲。 不扯远了，回正题。

首先，我发现将项目转为Androidx后，发现自己的Sophix不能正常工作了，app打完补丁就崩溃，于是各种测试，测试其他还未转androidx的项目正常。没办法只能求助全能的技术支持。

此时自己开始怀疑Sophix自身有问题，虽然Sophix是阿里的技术团队开发的，我也对它迷之自信，但是我的怀疑心战胜了崇拜心，大胆的猜测。 虽然技术支持坚称SDK不会有问题，但是我一直坚持自己的观点。


通过不断地多种测试，拿出我的多Gradle版本,多Android SDk版本的热更新测试，终于说服了Sophix 进行Androidx的兼容检查，最终发现 sophix 3.2.8之前的sdk确实不兼容android 5.0、5.1、 6.0的androidx apk进行热更新.


问题解决
OK,经过Sophix的工程师修复，Sophix 3.2.10升级到Sophix 3.2.12就能解决5.0，5.1,6.0 中安装了 Androidx的apk后，进行resource修复报错崩溃的bug。

总结

1. 常常看到阿里腾讯等大厂的产品我们就会觉得他们的产品肯定厉害，肯定没问题，其实这是个误解。 作为程序员大家其实是认同软件产品不能不存在Bug,好的和坏的就看bug率的多少了。 软件产品是一个逐步完善逐步修复bug完善的过程。
2. 对于任何开发中碰到的问题，我们要大胆的假设和猜测，不能根据自己的经验去认为不可能。
   一切皆有可能，何况我们大多数人还不是特级大神，我们需要怀疑需要假设，通过实际的排查和验证，才能排除不是那些因素造成了我们的问题。
   实践是检验一切真理的唯一标准

坑二：patch 补丁反复失效

这次碰到的Bug是补丁反复失效，具体症状是：补丁成功后，下次重启软件又恢复了原样，继续重启补丁成功，继续重启恢复原样。简直就是子子孙孙无穷尽也！

开发环境

1. win10+gradle-5.6.4+android studio 3.6.3 + 设备API 5.1.1+jdk1.8
2. ‘com.aliyun.ams:alicloud-android-hotfix:3.2.14’
3. 有个特殊的情况是，我的软件需要进行系统签名，制作成系统软件以便于软件的静默安装。生成的apk需要经如下文件签名，让程序获得系统级权限。
   
   系统签名还需在AndroidManifest.xml中配置android:sharedUserId="android.uid.system"

爬坑过程

首先进行相关因素排查，然后根据自己的进行假设，一步步验证排除假设直至找到最终真相。

1. 缓存清理

首先怀疑我进行了清缓存操作，于是我把各种自动清理垃圾缓存的代码操作屏蔽 和管理软件卸载，继续测试，Bug未解决，该Bug与缓存清理无关。
补充说明： 后面交流才知道patch的下载路径在/data/data/com.axecom.smartweightdj/files/sophix/patch(非系统签名app的路径，系统签名的下载路径我也没权限看不到啊)。

2. MultiDex不正常
各种日志分析测试，发现apk中有多个.dex文件，怀疑MultiDex失败的问题。我的apk中有7个.dex文件，后面几个.dex文件方法数只有几百个。 一般来说只有方法数超过65535，才会有两个.dex文件，后面依次计算，超过65535*2才会有3个.dex文件。

技术支持小哥让我生成正常的apk,这可难倒我了，找不出我的apk生成多个.dex文件的原因，，我只能笨办法，重建工程把内容以过去，好了，发现apk正常了，只有了2个.dex文件。



满心欢喜的以为搞定了，测试看看。我去，bug还是没解决，依然存在。

3. System.exit(0)
继续测试找背锅侠。在关闭的过程中，有System.exit(0)这个操作，好吧会不会是它造成的，我猜一般应该和这个没关系吧。

果然屏蔽了System.exit(0)方法后，Bug还是没有解决。继续其他猜想。

4. patch补丁是否加载正常
没办法，同样一个补丁，Sophix是不会不断下载同一补丁的，那么实时观察它的状态吧。

此时不尝试获得两个总结：
1.为了能看到data\data\package中的patch文件，我取消了系统签名，发现补丁竟然成功了。
2.非系统签名app,如果系统未root，一般也看不到data\data\package中的信息，此时只能通过配置debuggable true，此时我们能通过 看到data\data\package中的数据。
意外惊喜是非系统签名的app debuggable=true时， 补丁能正常。此时能看到data\data\package中的内容

赶紧测试debuggable=false时，补丁也能正常。此时权限问题无法看到data\data\package中的内容

在这里插入图片描述
3我的bug造成的原因肯定和系统签名有关系

5. 系统root
为了能看到系统签名，我需要找一个root 版本进行测试。
找到 root 系统进行测试后补充该处的内容

该Bug肯定是和系统权限方面有关。

问题解决：
bug源码解决了。这个bug折磨了我一个周的时间去整理和排除，可谓是伤透了心。

我的这个Bug一般人是碰不到的，需要系统签名的软件才会碰到如此问题,希望你们不会碰到，截止20200516，我所知道能让系统签名的app也支持Sophix的只有让Android 系统root。

总结

1. 其实生成了多个.dex的原因是：设置了 debuggable= true，此时生成了7个.dex文件，debuggable= false时生成的apk有2个.dex文件。

2. 这个Bug其实与debuggable的设置其实毫无关系，也即与.dex的多寡无关。这是后面经过我多次测试终于明白的。`**

3. 碰到技术bug能耐下心来去研究，排查，网上搜资料，始终能解决问题的。

4. 我的这个Bug的唯一解决方式是系统要root,或者将patch下载到外部空间如public\download中(但是Sophix现在是不支持修改设置patch下载地址的)

结语

• 首先要感谢自己的持之以恒，碰到的bug和爬坑过程，时间跨度在一个星期和一个多月。中间要做各种测试操作和验证，补充相关论点支持，每次自己都未有想放弃的想法，虽然头疼还是坚持排查最终也得到了解决。

• 非常感谢Sophix的技术支持@涂中和@徐厚、@刘宝文，这些Sophix的技术支持团队非常的有耐心，对于技术疑惑回答都很及时且对提问者的问题都是有问必答比解决。非常敬佩他们的敬业精神，果然觉得阿里的招牌不是盖的。

• 我在热更新方向是从Bugly平台转到EMAS的，两者的技术高低暂且不论，技术支持方面是高低立下的，真的建议大家更偏向Sophix,少踩Bugly的坑，我将用一片博文来阐述为什么。