Android热修复技术选型——三大流派解析

  • 时间:
  • 浏览:12
  • 来源:幸运快3_快3下载app送28_幸运快3下载app送28

2015年以来,Android开发领域里对热修复技术的讨论和分享太多,同时也总出 了某些不同的防止方案,如QQ空间补丁方案、阿里AndFix以 及微信Tinker,它们在原理各有不同,适用场景各异,到底采用哪种方案,是开发者比较头疼的问题图片图片。本文希望通过介绍QQ空间补丁、Tinker以及基于AndFix的阿里百川HotFix技术的原理分析和横向比较,帮助开发者更深入了解热修复方案。

技术背景

一、正常开发流程

从流程来看,传统的开发流程发生所以 弊端:

· 重新发布版本代价太多

· 用户下载安装成本太高

· BUG修复不及时,用户体验太差

二、热修复开发流程

而热修复的开发流程显得更加灵活,优势所以 :

· 不必重新发版,实时高效热修复

· 用户无感知修复,不必下载新的应用,代价小

· 修复成功率高,把损失降到最低

业界热门的热修复技术

热修复作为当下热门的技术,在业界内比较著名的有阿里巴巴的AndFix、Dexposed,腾讯QQ空间的超级补丁和微信的Tinker。最近阿里百川推出的HotFix热修复服务就基于AndFix技术,定发生线上紧急BUG的即时修复,所以 AndFix技术这块大家重点分析阿里百川HotFix。下面,大家就分别介绍QQ空间超级热补丁技术和微信Tinker以及阿里百川的HotFix技术。

一、QQ空间超级补丁技术

超级补丁技术基于DEX分包方案,使用了多DEX加载的原理,大致的过程要怎样让:把BUG最好的最好的办法修复已经 ,装入去有俩个 单独的DEX里,插入到dexElements数组的最前面,让虚拟机去加载修复已经 的最好的最好的办法。

当patch.dex中涵盖Test.class时就会优先加载,在后续的DEX中遇到Test.class得话就会直接返回而不去加载,要怎样让就达到了修复的目的。

要怎样让有有俩个 问题图片图片是,当有俩个 调用关系的类没了同有俩个 DEX时,就会产生异常报错。大家知道,在APK安装时,虚拟机都要将classes.dex优化成odex文件,要怎样让才会执行。在这人过程中,会进行类的verify操作,已经 调用关系的类都是同有俩个 DEX中得话就会被打上`CLASS_ISPREVERIFIED`的标志,要怎样让才会写入odex文件。

所以 ,为了都都要正常地进行打补丁修复,都要防止类被打上`CLASS_ISPREVERIFIED`标志,具体的做法要怎样让单独放有俩个 类在另外DEX中,让某些类调用。

大家来逆向手机QQ空间APK看一下具体的实现:

先进入守护进程入口`QZoneRealApplication`,在`attachBaseContext`中进行了两步操作:修复`CLASS_ISPREVERIFIED`标志由于的unexpected DEX problem异常、加载修复的DEX。

 1. 修复Unexpected DEX Problem异常

先看代码,

都都要看后,这里是要加载有俩个 libs目录下的dalvikhack.jar。在项目的assets/libs找到该文件,解压得到’classes.dex’文件,逆向打开该DEX文件,

通过不同的DEX加载进来,要怎样让在每有俩个 类的构造最好的最好的办法中引用某些DEX中的唯一类AnitLazyLoad,防止类被打上CLASS_ISPREVERIFIED标志。

在无修复的清况 下,将DO_VERIFY_CLASSES设置为false,以提高性能。都还可以 要能 在都要修复的已经 ,才设置为true。

至于要怎样加载进来,与下面第俩个步骤基本相同。

2. 加载修复的DEX

从loadPatchDex()最好的最好的办法进入,经过几个跳转,到达核心的代码段,`SystemClassLoaderInjector.c()`。已经 进行了混淆和多次最好的最好的办法的跳转,于是将核心代码段做了如下整理:

修复的步骤为:

1. 都都要看出是通过获取到当前应用的Classloader,即为BaseDexClassloader

2. 通过反射获取到他的DexPathList属性对象pathList

3. 通过反射调用pathList的dexElements最好的最好的办法把patch.dex转化为Element[]

4. 有俩个 Element[]进行合并,把patch.dex装入去最前面去

5. 加载Element[],达到修复目的

整体的流程图如下:

从流程图来看,都都要很明显的找到这人最好的最好的办法的特点:

优势:

1.  这样合成整包(和微信Tinker比起来),产物比较小,比较灵活

2.  都都要实现类替换,兼容性高。(某些三星手机不起作用)

过低:

1. 不支持即时生效,都要通过重启要能生效。

2. 为了实现修复这人过程,都要在应用中加入有俩个 dex!dalvikhack.dex中都还可以 要能 有俩个 类,对性能影响不大,要怎样让对于patch.dex来说,修复的类到了一定数量,就都要花不少的时间加载。对手淘这人航母级应用来说,启动耗时增加2s以上是都还可以 够接受的事。

3. 在ART模式下,已经 类修改了价值形式,就会总出 内存错乱的问题图片图片。为了防止这人问题图片图片,就都要把所有相关的调用类、父类子类等等完全加载到patch.dex中,由于补丁包异常的大,进一步增加应用启动加载的已经 ,耗时更加严重。

二、微信Tinker

微信针对QQ空间超级补丁技术的过低提出了有俩个 提供DEX差量包,整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同,区别在于不再将patch.dex增加到elements数组中,要怎样让差量的最好的最好的办法给出patch.dex,要怎样让将patch.dex与应用的classes.dex合并,要怎样让整体替换掉旧的DEX文件,以达到修复的目的。

大家来逆向微信的APK看一下具体的实现:

先找到应用入口`TinkerApplication`,在`onBaseContextAttached()`调用了`loadTinker()`,

进入TinkerLoader的tryLoad()最好的最好的办法中,

从最好的最好的办法名都都要预见,在tryLoadPatchFilesInternal()中尝试加载本地的补丁,再经过跳转进入核心修复功能类SystemClassLoaderAdder.class中。

代码中都都要看出,根据Android版本的不同,分别采取具体的修复操作,不过原理都是一样的。大家以V19为例,

从代码中都都要看后,通过反射操作得到PathClassLoader的DexPatchList,反射调用patchlist的makeDexElements()最好的最好的办法吧本地的dex文件直接替换到Element[]数组中去,达到修复的目的。

对于要怎样进行patch.dex与classes.dex的合并操作,这里微信开启了有俩个 新的守护进程,开启新守护进程的服务TinkerPatchService进行合并。

整体的流程如下:

从流程图来看,同样都都要很明显的找到这人最好的最好的办法的特点:

优势:

1.  合成整包,不必在构造函数插入代码,防止verify,verify和opt在编译期间就已经 完成,不必在运行期间进行。

2.  性能提高。兼容性和稳定性比较高。

3.  开发者透明,不都要对包进行额外防止。

过低:

1. 与超级补丁技术一样,不支持即时生效,都要通过重启应用的最好的最好的办法要能生效。

2. 都要给应用开启新的守护进程要能进行合并,要怎样让很容易已经 内存消耗等由于合并失败。

3. 合并时占用额外磁盘空间,对于多DEX的应用来说,已经 修改了多个DEX文件,就都要整理多个patch.dex与对应的classes.dex进行合并操作时这人清况 会更严重,要怎样让合并过程的失败率也会更高。

三、阿里百川HotFix

阿里百川推出的热修复HotFix服务,相对于QQ空间超级补丁技术和微信Tinker来说,定发生紧急BUG修复的场景下,要能最及时的修复BUG,下拉补丁立即生效不必等待图片。

1、AndFix实现原理

AndFix不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案,提供了这人运行时在Native修改Filed指针的最好的最好的办法,实现最好的最好的办法的替换,达到即时生效不必重启,对应用无性能消耗的目的。

原理图如下:

2、AndFix实现过程

对于实现最好的最好的办法的替换,都要在Native层操作,经过有俩个 步骤:

接下来以Dalvik设备为例,来分析具体的实现过程:

1、setup()

对于Dalvik来说,遵循JIT即时编译机制,都要在运行时装载libdvm.so动态库,获取以下内部内部结构函数:

1) dvmThreadSelf( ):查询当前的守护进程;

2)dvmDecodeIndirectRef( ):根据当前守护进程获得ClassObject对象。

2、setFieldFlag

该操作的目的:把 private、protected的最好的最好的办法和字段都改为public,要怎样让才可被动态库看见并识别,已经 动态库会忽略非public属性的字段和最好的最好的办法。

3、replaceMethod

该步骤是最好的最好的办法替换的核心,替换的流程如下:

AndFix对ART设备同样支持,具体的过程与Dalvik这类,这里不再赘述。

从技术原理,不能自己看出阿里百川HotFix的几个特点:

优势:

1.  BUG修复的即时性

2.  补丁包同样采用差量技术,生成的PATCH体积小

3.  对应用无侵入,几乎无性能损耗

过低:

1.  不支持新增字段,以及修改<init>最好的最好的办法,要怎样让支持对资源的替换。

2.  已经 厂商的自定义ROM,对少数机型暂不支持。

综合分析如下:

热修复技术的坑与解

大家都都要看后,QQ空间超级补丁技术和微信Tinker的修复原理都基于类加载,在功能上已经 支持类、资源的替换和新增,功能非常强大。既已经 来有了这样强大的热修复技术,为那些阿里百川都要推出自己的热修复方案HotFix呢?

一、多DEX带来的性能影响

大家知道,多DEX方案要怎样让是用于防止应用最好的最好的办法数65k的问题图片图片,现在google也官方支持了MultiDex的实现方案。超级补丁技术和Tinker却作为这人热修复的方案,平生给应用增加了多个DEX,而多DEX技术最大的问题图片图片在于性能上的坑,要怎样让基于这人方案的补丁技术影响应用的性能是无疑的。

1. 启动加载时间过长

大家都都要看后,超级补丁技术和Tinker都取舍在Application的attachBaseContext()进行补丁dex的加载,即时这是加载dex的最佳时机,要怎样让依然会带来很大的性能问题图片图片,首当其冲的要怎样让启动时间太长。

对于补丁DEX来说,应用启动时虚拟已经 进行dexopt操作,将patch.dex文件转添加odex文件,这人过程这人非常耗时。而这人过程又要求在主守护进程中,以同步的最好的最好的办法执行,要怎样让无法成功进行修复。就DEX的加载时间,最少做了以下的时间测试。

通过上表都都要看后,随着patch.dex的尺寸增加,在不做任何优化的清况 下,启动时间也直线增长。对于有俩个 应用来说,这居然是灾难性的。

2. 易造成应用的ANR和Crash

已经 多DEX加载由于了启动时间变长,要怎样让更容易引发应用的ANR。大家知道当应用在主守护进程等待图片超过5s已经 ,就会直接由于长时间无响应而退出。超级补丁技术为保证ART不总出 地址错乱问题图片图片,都要将所有关联的类完全加入到补丁中,而微信Tinker采取这人差量包合并加载的最好的最好的办法,都还可以 使要加载的DEX体积变得很大。这也很大程度上容易由于ANR清况 的总出 。

除了应用ANR以外,多DEX模式也同样很容易由于Crash清况 的总出 。在ART设备中为了保证不总出 地址错乱,都要把修改类的所有相关类完全加入到补丁中,这里会总出 有俩个 问题图片图片,为了保证补丁包的体积最小,都都要保证引入完全的关联类而不引入无关的类呢?一旦这样引入关联的类,就会总出 以下的异常:

· NoClassDefFoundError

· Could Not Find Class

· Could Not Find Method

总出 那些异常,就会直接由于应用的Crash退出。

所以 ,不能自己看出已经 大家都要修复有俩个 都是Crash的BUG,要怎样让已经 未加入相关类而由于了更严重的Crash,就更加的得不偿失。

总的来说,热修复本质的目的是为了保证应用更加稳定,而都是为了更强大的功能引入更大的风险和不稳定性。

二、 热修复 or 插件化?

大家老会 提到热修复和插件化,这都是当下热门的新兴技术。在讲述已经 ,都要对这有俩个 概念进行一下解释。

· 热修复:当线上应用总出 紧急BUG,为了防止重新发版,要怎样让保证修复的及时性而进行的一项在线推送补丁的修复方案。

· 插件化:有俩个 守护进程划分为不同的部分,以插件的形式加载到应用中去,本质上它使用的技术还是热修复技术,要怎样让加入了更多工程实践,让它支持大规模的代码更新以及资源和SO包的更新。

显然,从概念上大家都都要看后,插件化使用场景更多是功能上的,热修复强调微小的修复。从这人层面来说,插件化必然功能更加强大,能做的事情也更多。QQ空间超级补丁技术和微信Tinker从类、资源的替换和更新上来看,与其说是热修复,不如说是插件化技术的实践。

QQ空间超级补丁技术和微信Tinker提供了更加强大的功能,要怎样让对应用的性能和稳定有较大的影响,就BUG修复的这人使用场景上还过低明确,要怎样让显得过重。

针对应用的性能损耗,大家都都要举例做有俩个 对比:

某APP的启动载入时间为3s左右,这人要怎样让基于多DEX模式的实现。

分别接入这人热修复服务,根据腾讯提供超级补丁技术和Tinker的数据,这样会变成以下的场景:

1. 阿里百川HotFix:启动时间几乎无增加,不增加运行期额外的磁盘消耗。

2. QQ空间超级补丁技术:已经 应用有700个类,启动耗时增加超过2.5s,达到5.5s以上。

3. 微信Tinker:假设应用有俩个DEX文件,分别修改了这人个DEX,产生俩个patch.dex文件,就要进行5次的patch合并动作,假设每个补丁1M,这样就要多占用7.5M的磁盘空间。

显然对于修复紧急BUG这人场景,阿里百川HotFix的更为最少,它更加轻量,都都要在不重启的清况 下生效,且对性能几乎这样影响。

所以 阿里百川针对修复紧急BUG的场景,推出了HotFix这项在线热修复的轻服务。尽心提供最快捷的修复,让用户做到真正无感知,即时生效。 相比较微信Tinker、QQ空间超级补丁技术更多地把场景定位在发布新功能上,采用ClassLoader的模式,以牺牲少量性能为代价去实现类、资源新增或替换的功能,阿里百川HotFix对应用这人做到无侵入,几乎无性能损耗。

总结

QQ空间超级补丁技术和微信Tinker 支持新增类和资源的替换,在某些功能化的更新上更为强大,但对应用的性能和稳定会有的一定的影响;阿里百川HotFix觉得 暂时不支持新增类和资源的替换,对新功能的发布都是所限制,要怎样让作为一项定位为线上紧急BUG的热修复的服务来说,要能真正做到BUG即时修复用户无感知,同时保证对应用性能不产生不都要的损耗,在热修复方面不失为有俩个 好的取舍。

阿里百川HotFix公测正在进行中,申请地址:http://baichuan.taobao.com/product/hotfix.htm?channel=1111

本文由站长之家用户投稿,未经站长之家同意,严禁转载。如广大用户大家,发现稿件发生不实报道,欢迎读者反馈、纠正、举报问题图片图片(反馈入口)。

免责声明:本文为用户投稿的文章,站长之家发布此文仅为传递信息,不代表站长之家赞同其观点,不对对内容真实性负责,仅供用户参考之用,不构成任何投资、使用建议。请读者自行核实真实性,以及已经 发生的风险,任何后果均由读者自行承担。