Android热更新,到底是更新啥?

正常开发流程:

新版本上线,发现问题或用户反馈bug,紧急修复,上线版本,用户重新安装。

热修复流程:

新版本上线,发现问题或用户反馈,紧急修复,上线补丁,自动修复

Thinker解决思路?

在android5.0之前,每个android应用只含有一个dex文件,dex的方法数量被限制在了65535之内,导致apk引入大量第三方sdk后方法数量超过限制无法编译通过。为了解决这个问题,Google推出多dex文件的解决方案multidex,一个apk可以包含多个dex文件。通过Multidex.install(this)完成dex文件的加载。

Tinker方案参考multidex实现原理,在编译时通过新旧两个Dex生成差异patch.dex。在运行时,将差异patch.dex重新和原始安装包的旧Dex合并还原为新的Dex。这个过程可能比较耗费时间与内存,所以tinker单独放在一个后台进程:patch中处理。为了补丁包尽量的小,微信自研了DexDiff算法,它深度利用Dex的格式来减少差异的大小。由于采用ClassLoader机制,所以需要app重启。

Tinker基于基版本利用自研的DexDiff算法生成差分包,放在后台。App启动时下载差分包,与原dex重新合并,解压缩,并参考MultiDex.install()流程,重新安装app。

由于类加载实现原理涉及dex文件的重新解压缩合并等处理,消耗内存大,耗时长,在系统低内存时容易导致热更新失败,腾讯测试成功率大概为95%。实际热部署时,差分包应文件大小最小。

综上没有完美的热更新方案,没有100%的热更新成功率。目前,腾讯tinker基本可以满足app的热更新需求,但随着app用户规模不断增大,业务需求日益复杂,可考虑阿里的sophix商业方案,sophix同时应用类加载和底层替换两种方案,具有底层替换的修改及时性,和类加载方案的兼容性等优点。而且sophix采用非侵入打包,图形化的生成补丁,用阿里的原话说就是“傻瓜式接入”,点一点鼠标就能生成补丁文件,而且阿里提供了后台补丁管理系统,帮助开发者在生成补丁后直接上传至阿里的后台,无需开发者在自己的app和服务端做任何的操作。

热部署” – 方法内的简单修改,无需重启app和Activity。 “暖部署” – app无需重启,但是activity需要重启,比如资源的修改。 “冷部署” – app需要重启,比如继承关系的改变或方法的签名变化等。 

热更新究竟是什么?

有一些这样的情况, 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。有时候仅仅是为了修改了一行代码,也要付出巨大的成本进行换包和重新发布。

这种需要替换运行时新的类和资源文件的加载,就可以认为是热操作了。而在热更新出现之前,通过反射注解、反射调用和反射注入等方式已经可以实现类的动态加载了。而热更新框架的出现就是为了解决这样一个问题的。从某种意义上来说,热更新就是要做一件事,替换。当替换的东西属于大块内容的时候,就是模块化了,当你去替换方法的时候,叫热更新,当你替换类的时候,加热插件,而且重某种意义上讲,所有的热更新方案,都是一种热插件,因为热更新方案就是在app之外去干这个事。就这么简单的理解。无论是替换一个类,还是一个方法,都是在干替换这件事请。。这里的替换,也算是几种hook操作,无论在什么代码等级上,都是一种侵入性的操作。

所以总结一句话简单理解热更新 HotFix 就是改变app运行行为的技术!(或者说就是对已发布app进行bug修复的技术)

目前存在的主流框架?

先后出现了Dexposed、AndFix,Qzone超级补丁的类Nuwa方式,微信的Tinker, 大众点评的nuwa、百度金融的rocooFix, 饿了么的amigo以及美团的robust.以及阿里的Sophix.腾讯的内部方案KKFix.

框架横向对比?

 
Android热更新,到底是更新啥?

 

 

实现套路?

 
Android热更新,到底是更新啥?

 

 

 

对比点评?

AndFix作为native解决方案,首先面临的是稳定性与兼容性问题,更重要的是它无法实现类替换,它是需要大量额外的开发成本的;

Robust兼容性与成功率较高,但是它与AndFix一样,无法新增变量与类只能用做的bugFix方案;

Qzone方案可以做到发布产品功能,但是它主要问题是插桩带来Dalvik的性能问题,以及为了解决Art下内存地址问题而导致补丁包急速增大的。

特别是在Android N之后,由于混合编译的inline策略修改,对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换,它还是2.X-8.X(1.9.0以上支持8.X)的全平台支持。利用Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布

类加载机制?

我们知道Android系统也是仿照java搞了一个虚拟机,不过它不叫JVM,它叫Dalvik/ART VM他们还是有很大区别的(这是不是我们的重点, 点开是个拓展阅读)。我们只需要知道,Dalvik/ART VM 虚拟机加载类和资源也是要用到ClassLoader,不过Jvm通过ClassLoader加载的class字节码,而Dalvik/ART VM通过ClassLoader加载则是dex。

Android的类加载器分为两种,PathClassLoader和DexClassLoader,两者都继承自BaseDexClassLoader

PathClassLoader代码位于libcore\dalvik\src\main\Java\dalvik\system\PathClassLoader.java 

DexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\DexClassLoader.java 

BaseDexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\BaseDexClassLoader.java

PathClassLoader

用来加载系统类和应用类

DexClassLoader

用来加载jar、apk、dex文件.加载jar、apk也是最终抽取里面的Dex文件进行加载.

 
Android热更新,到底是更新啥?

 

 

归纳一下就是:ClassLoader会遍历这个数组,然后加载这个数组中的dex文件. 

而ClassLoader在加载到正确的类之后,就不会再去加载有Bug的那个类了,我们把这个正确的类放在Dex文件中,让这个Dex文件排在dexElements数组前面即可.

 
Android热更新,到底是更新啥?

 

 

为什么推荐Sophix?

为了提升产品在敏捷开发下的最佳发布体验,分别尝试了备受关注的阿里和微信两大派系的热更新方案(支付宝的Andfix和微信的Tinker),但在探索的过程中,发现两种方案都存在弊端,如使用场景有限,修复成功率低,存在兼容问题。加之各方案还在内部快速迭代,均未能达到商业化的标准,所以热修复在项目中的应用被暂时搁置了。

       直到最近,看到阿里推出了非侵入式热修复框架Sophix。Sophix对其前辈Andfix,阿里百川Hotfix等方案进行了升级改造,打破了旧方案诸多限制,涵盖了代码修复,资源修复,So库修复。加上阿里云平台的支持,经过简单的配置就可接入使用,目之所及,Sophix已经成为目前成熟度最高的热修复框架。这也让我重新燃起了对热更新及底层技术探索的热情。所以我想以此为契机,用系列文章的形式,围绕热点技术所涉猎的知识进行由浅入深的持续挖掘。

 
Android热更新,到底是更新啥?

 

 

修复立即生效,是热修复所追求的,底层替换方案通过在运行时利用hook操作native指针实现“热”的特性。但这里有一个关键点,底层替换所操作的指针,实际上是ArtMethod,在类被加载,类中的每个方法都会有对应的ArtMethod,它记录了方法包括所属类和内存地址信息,Andfix正是通过篡改ArtMethod,将补丁方法ArtMethod的成员值逐一赋给旧方法,实现替换。问题就出现在这个逐一上。因为Andfix的ArtMethod方法结构是根据Android开源代码写死的,面对国内厂商的定制,经常会导致两者ArtMethod方法结构不一致,这也是兼容问题产生的根本原因。

       为了解决这个问题,Sophix采用了对旧ArtMethod进行完整替换,通过动态测量ArtMethod的size(通过c层的mempy(dest ,src ,size)方法),进行全量拷贝。这样做无论ArtMethod被修改成什么样,只需要统一执行拷贝,就可以完成替换,完全无视修改虚拟机导致的ArtMethod结构差异.

 底层替换虽能使修复即时生效,但由于类加载后,方法结构已固定,这就造成使用上会有诸多限制。相反类加载方案的使用场景更为广泛。Sophix使用类加载作为兜底方案。在热部署无法使用的情况下,自动降级为冷部署方案。

       无论是冷部署还是热部署,都需要通过同一套补丁兼顾,在Art虚拟机下,默认支持多dex加载,虚拟机会优先加载命名为classes.dex的文件。Sophix利用了这一点,将补丁文件命名为classes.dex,并对原有dex文件进行排序。这样一来,art虚拟机就会先加载补丁文件,后续加载的同类名的类会被忽略,最后将加载得到的dexFile把dexElements整体替换。

 
Android热更新,到底是更新啥?

 

 

 

      Dalvik虚拟机下情况则有些不同,Dalvik默认只加载classes.dex,其他dex则被忽略。那么,Sophix就需要一个全量dex,前面提到tinker采用自主研发的dexDiff技术,从方法和指令的维度进行dex合成,但Dex合成过程发生在虚拟机堆内存上,修复的成功率极大的受到性能问题的影响。为了解决这个问题,Sophix换了一种思路,从类的维度,对照补丁包中出现的类,在原有包中做删除操作,如图。

 
Android热更新,到底是更新啥?

 

 

   为了避免删除整个类信息而导致dex结构发生偏移,所以只对旧包中类的入口进行删除,实际上类的信息还在dex包中。这样一来,冷启动后,原有的类就不会被加载,相比Tinker的合成方案,Sophix的思路更为轻量化。

       至此,对Sophix对类文件修复的基本原理描述完毕。可以说Sophix吸取了百家之长,对问题的解决之法堪称巧妙。但在惊叹阿里技术底蕴的同时,也展现出底层技术的重要性,若没有对虚拟机等底层技术的深耕探索,在系统框架的纷繁规则面前,也只能至于庭前止步。

 
 



作者:哥哥是欧巴Vitory
链接:https://www.jianshu.com/p/e6fd2adafaac
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Android热更新,到底是更新啥?

上一篇:10、Python与设计模式--享元模式


下一篇:android开发图片放在drawable-xx下的区别以及加载bitmap内存分析