浅析热更新技术方案(Android),热更新技术有哪些

4747 2208 2022-12-05

本文讲了浅析热更新技术方案(Android),热更新技术有哪些。

在Android开发中,关于热修复的话题越来越多,同时随着技术的迭代,各种框架的发展更新,热修复的框架似乎已经日趋成熟,各大互联网公司基本都有研发热更新框架,方案实现及优缺点各有差异,但总的来说就是两大类

  • ClassLoader 加载方案

  • Native层替换方案

QZone的热修复方案

  • 基于Android Dex分包方案

  • 利用插桩绕开预校验问题

  • 只支持重启修复

  • 不支持资源修复

QZone方案推出比较早,对热修复技术的推进很有启发意义。它是基于Android dex分包方案,最关键的技术点在于利用字节码插桩的方式绕开了预校验问题。这种方案只支持App重启之后才能修复,也就是App在运行的时候加载到了补丁包也不能及时修复,需要App重新启动的时候才会修复,这是因为QZone方案是基于类加载区需要重新加载补丁类才能实现的,所以必须进行重启才能修复。此外,QZone方案只支持到类结构本身代码层面的修复,不支持资源的修复。

何为利用插桩绕开预校验问题?

1.在apk安装的时候系统会将dex文件优化成odex文件,在优化的过程中会涉及一个预校验的过程

2.如果一个类的static方法,private方法,override方法以及构造函数中引用了其他类,而且这些类都属于同一个dex文件,此时该类就会被打上CLASS_ISPREVERIFIED3.如果在运行时被打上CLASS_ISPREVERIFIED的类引用了其他dex的类,就会报错4.正常的分包方案会保证相关类被打入同一个dex文件5.想要使得patch可以被正常加载,就必须保证类不会被打上CLASS_ISPREVERIFIED标记。而要实现这个目的就必须要在分完包后的class中植入对其他dex文件中类的引用以上参考Android热修复技术——QQ空间补丁方案解析(2)

QZone方案在Dalvik与Art都会产生一些问题

  • Dalvik; 在dexopt过程,若class verify通过会写入pre-verify标志,在经过optimize之后再写入odex文件。这里的optimize主要包括inline以及quick指令优化等。若采用插桩导致所有类都非preverify,这导致verify与optimize操作会在加载类时触发,这会有一定的性能损耗.

  • Art采用了新的方式,插桩对代码的执行效率并没有什么影响。但是若补丁中的类出现修改类变量或者方法,可能会导致出现内存地址错乱的问题。为了解决这个问题我们需要将修改了变量、方法以及接口的类的父类以及调用这个类的所有类都加入到补丁包中。这可能会带来补丁包大小的急剧增加。

Tinker

tinker.png

Tinker的思路是这样的,在编译时通过新旧两个Dex生成差异path.dex。在运行时,将差异patch.dex重新跟原始安装包的旧Dex还原为新的Dex。这个过程可能比较耗费时间与内存,所以我们是单独放在一个后台进程:patch中。为了补丁包尽量的小,微信自研了DexDiff算法,它深度利用Dex的格式来减少差异的大小。它的粒度是Dex格式的每一项,可以充分利用原本Dex的信息,而BsDiff的粒度是文件,AndFix/QZone的粒度为class。

关于Tinker的文档及源代码,可参考Tinkergithub

Tiker方案详细分析可参考Android热补丁实践演进之路

一. AndFix

AndFix.png

AndFix采用native hook的方式,这套方案直接使用dalvik_replaceMethod替换class中方法的实现。由于它并没有整体替换class, 而field在class中的相对地址在class加载时已确定,所以AndFix无法支持新增或者删除filed的情况(通过替换init与clinit只可以修改field的数值)。

app更新的方式

app版本更新迭代分为整包更新和热更新。

整包更新是整个app安装包需要重新-安装,它通过应用市场来更新,整包的体积比较大,-速度慢。

热更新就是动态下发代码,当用户打开app时,通过网络-升级包来直接更新,不需要发布新版本到应用市场。升级包的体积比较小,-速度快。

发布一个app新版本,要上架到应用市场是需要审核的。ios应用市场审核很严格而且审核需要一定的时间,android市场也一样,遇到一些节假日会往后延期。

热更新的方式可以绕过应用市场的审核,所以对于紧急的bug修复以及实时性较强的功能发布(比如运营活动)比较适合。

那么,app所有功能的更新都可以使用热更新吗?

热更新的适用条件

因为应用市场比较多,下面就重点讲下苹果app store的热更新条款。

app store禁止滥用热更新机制。

因为当开发者提交代码到app store审核通过后,开发者可能会通过热更新方式修改app 原生代码导致安全隐患,这就违反了苹果的安全隐私政策。

比如2017年2月时,苹果就发现了某种热更新方式,存在安全漏洞,如果黑客发现并利用了这个后门,

他们就能够访问到设备中的照片、麦克风和剪贴板数据以及其他涉及个人隐私的功能。

为了应用生态的安全可控,一般来说,如果涉及到更改了app 原生代码的更新,苹果都要求审核。

app的开发框架非常多,下面举个例子来讲下。

假设开发app使用的是react native框架,如果只是修改了图片资源、js代码,是可以使用热更新机制更新代码的,但是如果更改了native原生的代码,就违反了苹果的审核条款。

上文就是小编为大家整理的浅析热更新技术方案(Android),热更新技术有哪些。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)Finclip软件分析、比较及推荐。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:前端跨平台方案,跨终端前端开发解决方案
下一篇:app混合开发是什么意思,混合app开发框架
相关文章

 发表评论

暂时没有评论,来抢沙发吧~