热修复是很多开发者关心的技术，8月27日晚，阿里百川组织了“百川解码”在线直播，以“热修复的坑和阿里的解”为主题，邀请了三位业界嘉宾对热修复技术进行了探讨，并介绍了阿里百川全面接受公测的热修复解决方案：阿里百川HotFix，就网友提出的相关问题进行了解答。本文是此次直播的精彩回顾。
歩川，阿里巴巴资深开发工程师，《让App像Web一样发布新版本》一文作者，在OPPO从事Android Framework两年，腾讯QQ空间工作一年半，热衷研究安卓热补丁方案。目前在手机淘宝终端架构，主要负责动态部署增强和优化、存储相关工作。
刘昭，中华英才网Android技术负责人，具有丰富的移动开发经验，崇尚开源社区文化，关注性能优化、研发效率、热修复、插件化、数据驱动等，善于评估技术方案，解决疑难杂症。
泽胤，阿里巴巴无线技术专家，阿里百川HotFix项目负责人，无线事业部初创技术员工之一。经历阿里巴巴无线技术从小到大的整个过程，参与过多个无线的重要项目，包括无线的H5建站，无线统一接入层，阿里的无线PUSH系统，以及第一版的Android客户端等。主要技术方向是在线高并发和高可用性的维护与实现。
刘昭认为，热修复是在应用的App包发布到市场之后，出现了Bug，无需替换包来进行在线更新的一种技术，对用户是无感知的。
泽胤认为，谈到热修复，就应该和动态部署的概念进行区分。热修复是特指对微小改动进行修复的一个技术，它强调快速和无感的修复。而动态部署会复杂更多，它涵盖的东西也更多，但核心的技术还是热修复技术。
步川认为，热修复可以从技术上来理解并和动态部署进行区分。他提到，目前广义上有两种方案可以实现代码的替换，一种是类的替换，基于Classloader，另一种是方法的替换，而这两种方式各有优缺点。
方法的替换：只能替换方法的内容，所以不能够对要patch的类进行方法的新增和删除；但同时，方法的替换可以在应用不重启的情况下实现。它包小、快速、功能单一、比较轻量，这种方案是热修复。
类的替换：可以修改类结构，功能更加的强大；但是必须要重启一次才会有效，因为已经加载过的类是不能够被替换的。这种方案叫做“动态部署”。它几乎能够适应任何代码的变更，所以很适合进行业务功能的迭代。
目前，业内有很多的热修复方案，步川就热修复技术向观众进行了对比讲解。他提到，从广义上来讲，热修复的实现方式可以被分为类的替换和方法的替换。
类的替换
如图1所示，APK包中包含了代码和资源，代码存放在classes.dex中，资源存放在APK的res目录下，系统会通过ClassLoader装载classes.dex来进行类加载。如果有多个classes.dex，那么这多个classes.dex会在ClassLoader中会用数组的形式来进行组织，然后从前往后进行遍历查找。
![]()
图1
一种具体的方案如图2所示，是利用多dex从前往后遍历的有序特性，把patch.dex插入到数组的最前面，对patch进行有限查找，达到替换的目的，这时候就会出现preverify问题，为了绕过这个问题，就必须往每个类的构造函数里面进行插桩防止安装期间的校验，把校验从编译期间移动到了运行期间，导致运行期间每加载一个类，都要进行校验和优化，降低了运行性能。
![]()
图2
刘昭认为，这种方案利用了ClassLoader，思想是比较好的，但是如果工程中的类比较多，就会在性能上造成比较大的影响。同时，有可能会导致patch包比较大。
步川提到，为了解决上述性能问题，出现了另一种方案，如图3所示：就是全量替换dex，下发一个patch.dex，然后把原来的dex和下发的patch.dex，合成一个新的全量dex，这个dex会全量替换原来的dex，最终本质上也只会在这个全量的dex中查找，从而不会出现preverify问题，所以这种方案不用插入构造函数，不会影响性能。
但是，这种方案的包也可能会比较大，只改动了一行代码，也必须合成一个全量的dex，如图4所示，然后再dexopt中一个全量的odex。
![]()
图3
![]()
图4
方法的替换
如图5所示，方法的替换的原理如下：在Android底层，有个数据结构记录着类的信息，比如成员变量的个数，方法的个数，每个方法的code执行地址，程序运行的时候会根据这个地址跳转到具体的code区域执行代码。方法的替换就是替换这些地址，把地址指向另一个类的方法，从而达到了替换的目的。
这种方式的包比较小，而且也不需要插桩来影响性能，但是它无法修改类的结构（比如方法数的增删），而且有可能会有兼容性问题，例如厂商修改了类和方法的底层结构。
![]()
图5
所以基于他们的优点和限制，区分热修复和动态部署这两种场景，可以在这两种不同的情况下，选择最优的方案，达到修复的目的。
刘昭认为，热修复技术方案的选择应该对应具体的使用场景。在patch包的数量、大小方面，HotFix是占优势的；但是HotFix不能新增类、新增字段（下文泽胤有回应），从这个角度考虑，ClassLoader更好，但是会有一定的性能损耗；合成dex的方式，则需要知道用户手机的ROM有多大，能不能提供20多M的空间来。
阿里百川HotFix是基于AndFix的，泽胤提到，手机淘宝（下文简称“手淘”）对于Andfix实践了大约一年左右，在工程和技术上做了一些改善，提高了其在稳定性、周边工具链的性能和稳定性等方面的表现，使得这项技术更加成熟，同时也解决了不能新增类等问题，并成功落地手淘App。
具体的优化工作包括：在产品化方面，接入简单，2行代码即可接入，一般开发者1个小时即可完全跑通流程，大大降低工程成本；提供了相对完善的周边工具链，通过后台操作自由控制patch发布，最大化保证用户体验。
针对patch打包慢的问题进行优化，持续在工具链方面进行优化；在“打包工具交互”方面，开发了一个独立的可执行文件，可以在工程里面，用GRADLE、ANT中集成，甚至在JENKINS里面去执行，提高了灵活性。
在产品化方面，接入简单，2行代码即可接入，一般开发者1个小时即可完全跑通流程，大大降低工程成本；提供了相对完善的周边工具链，通过后台操作自由控制patch发布，最大化保证用户体验。
在安全方面，泽胤也做了说明：第一，阿里会提供一个私有RSA加密的功能，开发者在本地打出包以后用自己的RSA密钥对中的私钥加密，然后上传百川平台，再在SDK中放置自己的公钥作为解码用，这样上传的内容完全加密确保绝对的信息安全，且不会被阿里看到；第二，传输层面，在设计上采用两级的加密，动态密钥和静态密钥相结合，因此网络拦截无法窃取到包内容。
从商业价值上来讲，开发者目前非常需要热修复技术，所以有一定的价值，但是未来，如果官方提供相应的功能，或者说React Native 等技术减弱了开发者对热修复技术的依赖，则会对热修复的技术产品造成冲击。
对于这样的情况，泽胤认为，作为技术人员，要不断学习进步。一项技术如果没有了被使用的价值，那么它是应该被淘汰掉的，例如历史上很多编程语言或者技术的消亡。泽胤表示，产品的迭代和消亡也是很正常的。很乐意看到有新的，满足开发者需求的技术可以代替老的技术。
步川认为，从方案讲，热修复和动态部署不是互相排斥的，在特定的场景下两者都可以做到最优，配合使用更佳。手淘同时使用这两项技术，用热修复解决Bug，用动态部署来迭代业务，相互配合好则会达到很完美的状态。
刘昭提出，Android Studio 2.0之后，提供了Instant Run这样的功能，从思想上来讲是非常好地解决了热修复patch的问题，之后的热修复有没有可能借鉴其思想？对于这个问题，步川认为，Instant Run的更新力度比较大，同时又在代码中增加了预埋逻辑，侵入性比较大。若基于Class Loader来开发一个工具，或许会更简单。
泽胤提到，市场上缺少阿里百川HotFix这样的产品，虽然热修复原理解析很多，但是真正难的是把这项技术做成熟、做稳定。基于手淘App这个大平台，由工程实践出来的阿里百川HotFix产品，可以推出独立的服务来满足市场上的需求。泽胤提到，阿里百川会有专门的团队持续跟进该产品，解决问题，吸纳用户意见。
戳阅读原文，立即使用！
![]()
