AI人工智能 | 人工智能机器人【中国人工智能网】

滚动新闻

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

时间:2017-06-14 23:56来源:网络整理 作者:AI人工智能

阿里巴巴对Android热修复技能已经举办了长达多年的摸索。

最开始,是手淘基于Xposed举办了改造,发生了针对Android Dalvik虚拟机运行时的Java Method Hook技能,Dexposed。但这个方案由于对底层Dalvik布局过于依赖,最终无法继承兼容Android5.0今后ART虚拟机,因此作罢。

厥后付出宝提出了新的热修复方案Andfix。Andfix同样是一种底层布局替换的方案,也到达了运行时生效即时修复的结果,而且重要的是,做到了Dalvik和ART情况的全版本兼容。阿里百川团结手淘在实际工程中利用Andfix的履历,对相关业务逻辑解耦后,推出了阿里百川Hotfix方案,并获得了精采的回声。

此时的百川Hotfix已经是一个很不错的产物了,对付根基的代码修复需求都可以办理,安详性和易用性都做的较量好。然而,它所依赖的基石,Andfix自己,是有范围性的。且不说其底层牢靠布局的替换方案不变性欠好,其利用范畴也存在着诸多限制,固然可以通过改革代码绕过限制来到达沟通的修复目标,但这种方法既不优雅也不利便。而更大的问题是,Andfix只提供了代码层面的修复,对付资源和so的修复都还未能实现。

再看一下同期的其他热修复方案,此时的热修复技能可谓是百花齐放,很多产物都声称本身可以做到全方位全成果的热修复。不外他们各自有自身的范围性,可能不足不变,可能补丁过大,可能效率低下,可能利用起来过于繁琐,大部门技能上看起来好像可行,但实际体验并欠好。而在我们看来,有许多技能细节可以或许做得越发完美。

终于在2017年6月11日,手淘技能团队连系阿里云正式宣布了史上首个非侵入式移动热更新办理方案——Sophix。

Sophix进口https://www.aliyun.com/product/hotfix

Sophix的横空出世,将会冲破各家热修复技能纷争的排场。我们可以满怀信心地说,在Android热修复的三大规模:代码修复、资源修复、so修复方面,以及方案的安详性和易用性方面,Sophix都做到了业界领先。

设计理念

Sophix的焦点设计理念,就长短侵入性。

我们的打包进程不会侵入到apk的build流程中。我们所需要的,只有已经生成完毕的新旧apk,而至于apk是如何生成的——是Android Studio打包出来的、照旧Eclipse打包出来的、可能是自界说的打包流程,我们一律不体贴。在生成补丁的进程中间既不会改变任何打包组件,也不插入任何AOP代码,我们积极做到了——不添加任何超出开拓者预期的代码,以制止多余的热修复代码给开拓者带来困扰。

在Sophix中,独一需要的就是初始化和请求补丁两行代码,甚至连进口Application类我们都不做任何修改,这样就给了开拓者最大的透明度和自由度。我们甚至从头开拓了打包东西,使得补丁东西操纵图形界面化,这种所见即所得的补丁生成方法也是阿里热修复独家的。因此,Sophix的接入本钱也是今朝市面上所有方案里最低的。

这种非侵入式热更新理念,是我们在设计进程中从用户利用角度举办了深入思考而提炼出的焦点思想。

这里的用户,指的自然是宽大的开拓者。对付开拓者而言,热修复应该是一个与业务无关的SDK组件,在整个开拓进程中感知不到它的存在。最抱负的环境,就是开拓者拿过来两个apk,一个是已经安装在手机上的apk,另一个是将要宣布出去的apk。我们直接通过东西,就可以按照这两个apk生成补丁,然后把这个补丁下发给已经安装的旧app上,就可以直接加载,使旧app更生为新的app。而这个加载了补丁包新app,在成果和利用上,将会和直接安装新apk别无二致。

至于Sophix这个名字,是来历于Sophic(明智的)+ FIX,一个更明智的热修复方案。

具体较量

下面的这张表格,从几个热修复最重要的维度,把Sophix和别的两个主要贸易化热修复方案举办了较量。

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

可以看到,Sophix在各个指标上全面占优。而个中独一不支持的处所就是四大组件的修复,这是因为假如要修复四大组件,必需在AndroidManifest内里预先插入署理组件,而且尽大概声明所有权限,而这么做就会给原先的app添加许多臃肿的代码,对app运行流程的侵入性很强。

所以,本着对开拓者透明与代码极简的原则,我们没有做这种多余的处理惩罚。

直接看表格的话,个中有些技能细节大概还看不太清朗,那么接下来,我将从各个角度,深度解读Sophix的技能优势以及它与同类技能的不同。

技能阐明

Sophix的降生,起初是对原先的阿里百川Hotfix 1.X版本举办进级衍进。

原先百川Hotfix处事端的整套请求节制流程,以及安详查抄这部门,是与热修复成果相对疏散的,因此我们依旧保存了这部门的逻辑。

而原本的热修复方案,主要限制在于Andfix自己,我们最开始也是从打破原先修复限制入手,但愿可以或许基于原先的Andfix代码做一些须要的改造。然而最终发明,Andfix自身限制险些是无法绕过的,在运行时对原有类的布局是已经固化在内存中的,它的一些动态属性和很难举办扩展。而且由于Android系统的碎片化,厂商的虚拟机底层布局都不是确定的,因此直接基于原先机制举办扩展的风险很大。

所以我们绕开了详细的技能实现细节,直接从修复的道理入手,对原先的代码修复技能举办深挖和改善。

回首为期九个多月的摸索与开拓,这个中无处不浮现着我们对易用性和优雅性的极致追求,在技能先进性与易用性上我们到达了完美的均衡。所以,当我们再转头看今朝市面上的其他热修复技能,真的有一种“曾经沧海难为水”的感受。

代码修复

代码修复有两大主要方案,一种是阿里系的底层替换方案,另一种是腾讯系的类加载方案。

这两类方案各有黑白:

  • 底层替换方案限制颇多,但时效性最好,加载轻快,当即收效。

  •  类加载方案时效性差,需要从头冷启动才气收效,但修复范畴广,限制少。

底层替换方案

底层替换方案是在已经加载了的类中直接替换掉原有要领,是在本来类的基本长举办修改的。因而无法实现对与原有类举办要领和字段的增减,因为这样将粉碎原有类的布局。

一旦补丁类中呈现了要领的增加和淘汰,就会导致这个类以及整个Dex的要领数的变革。要领数的变革陪伴着要领索引的变革,这样在会见要领时就无法正常地索引到正确的要领了。

假如字段产生了增加和淘汰,和要领变革的环境一样,所有字段的索引城市产生变革。而且更严重的问题是,假如在措施运行中间某个类溘然增加了一个字段,那么对付原先已经发生的这个类的实例,它们照旧本来的布局,这是无法改变的。而新要领利用到这些老的实例工具时,会见新增字段就会发生不行预期的功效。

这是这类方案的固有限制,而底层替换方案最为人诟病的处所,在于底层替换的不不变性。

传统的底层替换方法,岂论是Dexposed、Andfix可能其他安详界的Hook方案,都是直接依赖修改虚拟秘密领实体的详细字段。譬喻,改Dalvik要领的jni函数指针、改类或要领的会见权限等等。这样就带来一个很严重的问题,由于Android是开源的,各个手机厂商都可以对代码举办改革,而Andfix里ArtMethod的布局是按照果真的Android源码中的布局写死的。假如某个厂商对这个ArtMethod布局体举办了修改,就和原先开源代码里的布局纷歧致,那么在这个修悔改了的设备上,通用性的替换机制就会出问题。这即是不不变的来源。

而我们也对代码的底层替换道理从头举办了深入思考,从降服其限制和兼容性入手,以一种越发优雅的替换思路,实现了即时生效的代码热修复。我们实现的是一种无视底层详细布局的替换方法,也就是把原先这样的逐一替换 :

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

酿成了这样的整体替换 :

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

这么一来,我们不只办理了兼容性问题,而且由于忽略了底层ArtMethod布局的差别,对付所有的Android版本都不再需要区分,代码量大大淘汰。纵然今后的Android版本不绝修改ArtMethod的成员,只要担保ArtMethod数组仍是以线性布局分列,就能直接合用于未来的Android 8.0、9.0等新版本,无需再针对新的系统版本举办适配了。

事实也证明晰实如此,当我们拿到Google刚发不久的Android O(8.0)开拓者预览版的系统时,hotfix demo直接就能顺利地加载补丁跑起来了,我们并没有做任何适配事情,不变性极好。

详细技能细节,可以看这篇文章:Android热修复进级摸索——追寻极致的代码热替换

类加载方案

类加载方案的道理是在app从头启动后让Classloader去加载新的类。因为在app运行到一半的时候,所有需要产生改观的类已经被加载过了,在Android上是无法对一个类举办卸载的。假如不重启,本来的类还在虚拟机中,就无法加载新类。因此,只有在下次重启的时候,在还没走到业务逻辑之前抢先加载补丁中的新类,这样后续会见这个类时,就会Resolve为新类。从而到达热修复的目标。

再来看看腾讯系三大类加载方案的实现道理。QQ空间方案会侵入打包流程,而且为了hack添加一些无用的信息,实现起来很不优雅。而QFix的方案,需要获取底层虚拟机的函数,不足不变靠得住,而且有个较量大的问题是无法新增public函数。

微信的Tinker方案是完整的全量dex加载,而且可谓是将补丁合成做到了极致,然而我们发明,紧密的兵器并非合用于所有疆场。Tinker的合成方案,是从dex的要领和指令维度举办全量合成,整个进程都是本身研发的。

固然可以很大地节减空间,但由于对dex内容的较量粒渡过细,实现较为巨大,机能耗损较量严重。实际上,dex的巨细占整个apk的比例是较量低的,一个app内里的dex文件巨细并不是主要部门,而占空间大的主要照旧资源文件。因此,Tinker方案的时空价钱转换的性价比不高。

其实,dex较量的最佳粒度,应该是在类的维度。它既不像要领和指令维度那样的细微,也不像bsbiff较量那般的粗拙。在类的维度,可以到达时间和空间均衡的最佳结果。基于这个准则,我们另辟门路,实现了一种完全差异的全量dex替换方案。

我们回收的也是全量合成dex的技能,这个技能是从手淘插件化框架Atlas罗致的。我们会直接操作Android原先的类查找和合成机制,快速合成新的全量dex。这么一来,我们既不需要处理惩罚合成时要领数高出的环境,对付dex的布局也不消举办粉碎性重构。

手淘插件化框架Atlas下载:

https://github.com/alibaba/atlas

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

从图中可以看到,我们从头编排了包中dex的顺序。这样,在虚拟机查找类的时候,会优先找到classes.dex中的类,然后才是classes2.dex、classes3.dex,也可以看做是dex文件级此外类插桩方案。这个方法十分巧妙,它对旧包与补丁包中classes.dex的顺序举办了冲破与重组,最终使得系统可以自然地识别到这个顺序,以实现类包围的目标。这将会大大淘汰合成补丁的开销。

双剑合璧

既然底层替换方案和类加载方案各有其利益,把他们连系起来不是最好的选择吗?Sophix的代码修复体系正是同时涵盖了这两种方案。两种方案的团结,可以实现优势互补,完全分身的浸染,可以机动地按照实际环境自动切换。

这两种方案我们都举办了重大的改造,而且从补丁生成到应用的各个环节都举办了研究,使得二者能很好地整合在一起。在补丁生成阶段,补丁东西会按照实际代码变换环境举办自动选择,针对小修改,在底层替换方案限制范畴内的,就直接回收底层替换修复吗,这样可以做到代码修复即时生效。而对付代码修改超出底层替换限制的,会利用类加载替换,这样固然实时性没那么好,但总归可以到达热修复的目标。

别的,运行时阶段,Sophix还会再判定所运行的机型是否支持热修复,这样纵然补丁支持热修复,但由于机型底层虚拟机结构不支持,照旧会走类加载修复,从而到达最好的兼容性。

资源修复

今朝市面上的许多资源热修复方案根基上都是参考了Instant Run的实现。实际上,Instant Run的推出正是敦促这次热修复海潮的主因,各家热修复方案,在代码、资源等方面的实现,很洪流平上地参考了Instant Run的代码,而资源修复方案正是被拿来用到最多的处所。

扼要说来,Instant Run中的资源热修复分为两步:

1. 结构一个新的AssetManager,并通过反射挪用addAssetPath,把这个完整的新资源包插手到AssetManager中。这样就获得了一个含有所有新资源的AssetManager。

2. 找到所有之前引用到原有AssetManager的处所,通过反射,把引用处替换为AssetManager。

我们发明,其实大量代码都是在处理惩罚兼容性问题和找到所有AssetManager的引用处,真正的替换的逻辑其实很简朴。

我们的方案没有直接利用Instant Run的技能,而是另辟门路,结构了一个package id为0x66的资源包,这个包里只包括改变了的资源项,然后直接在原有AssetManager中addAssetPath这个包就可以了。

由于补丁包的package id为0x66,不与今朝已经加载的0x7f斗嘴,因此直接插手到已有的AssetManager中就可以直接利用了。补丁包内里的资源,只包括原有包内里没有而新的包内里有的新增资源,以及原有内容产生了改变的资源。而且,我们回收了越发优雅的替换方法,直接在原有的AssetManager工具长举办析构和重构,这样所有原先对AssetManager工具的引用是没有产生改变的,所以就不需要像Instant Run那样举办繁琐的修改了。

可以说,我们的资源修复方案,优越性高出了Google官方的Instant Run方案。整个资源替换的方案优势在于:

1. 不修改AssetManager的引用处,替换更快更完全。(比拟Instanat Run以及所有copycat的实现)

2. 不必下发完整包,补丁包中只包括有变换的资源。(比拟Instanat Run、Amigo等方法的实现)

3. 不需要在运行时合成完整包。不占用运行时计较和内存资源。(比拟Tinker的实现)

所以,我们不要被所谓的“官方实现”束缚住手脚,其实Instant Run的开拓团队和Android framework的开拓团队并不是同一个团队,他们对付Android系统机制的领略未必十分深入。只要你当真研读系统代码,实现一个比官方更好的方案绝非难事。所以我想说的是,要想实现技能方案的打破,首先就需要废除所谓“权威”的见识。

资源修复的更多技能细节,可通过这篇文章一探毕竟:Android热修复进级摸索——资源更新之新思路

so库修复

so库的修复本质上是对native要领的修复和替换。

我们知道JNI编程中,native要领可以通过动态注册和静态注册两种方法举办。动态注册的native要领必需实现`JNI_OnLoad`要领,同时实现一个`JNINativeMethod[]`数组,静态注册的native要领必需是`Java+类完整路径+要领名`的名目。

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

动态注册的native要领映射通过加载so库进程中挪用JNI_OnLoad要领挪用完成,静态注册的native要领映射是在该native要领第一次执行的时候才完成映射,虽然前提是该so库已经load过。

我们回收的是雷同类修复反射注入方法。把补丁so库的路径插入到nativeLibraryDirectories数组的最前面,就可以或许到达加载so库的时候是补丁so库,而不是本来so库的目次,从而到达修复的目标。

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

回收这种方案,完全由Sophix在启动期间反射注入patch中的so库。对开拓者依然是透明的。不消像某些其他方案需要手动替换系统的System.load来实现替换目标。

将来展望

热修复的须要性

热修复是一个与业务完全无关的模块,开拓者假如要本身实现一套靠得住的热修复框架,将耗费大量时间和精神。固然市面上已经有许多开源的热修复实现,然而个中的许多坑,往往要踩过才知道,等你把这些坑一一踩过之后,大概大量的用户已经对你失去信心。所以,依靠一个不变靠得住、并且简朴实用的贸易版本,反而能使各方面的本钱降到最低。而且,热修复并不是简朴的客户端SDK,它还包括了安详机制和处事端的节制逻辑,这整条链路也不是短时间内可以快速完成的。

照旧那句老话,专业是事交给专业的人去做。开拓者应该把更多时间精神放到本身的焦点业务之中。

Sophix提供了一套越发完美的客户端处事端一体的热更新方案。做到了图形界面一键打包、加密传输、签名校验和处事端节制宣布与灰度成果,让你用最少的时间实现最强大靠得住的全方位热更新。而且在代码修复、资源修复、SO库修复方面,都做到了业界最佳。

对Android的生态的影响

许多人会把热修复技能跟其他海内厂商的“黑科技”等量齐观。有人说,你们海内开拓者就是瞎搞,就不能给我们Android用户一个越发纯净的情况吗?

这里我需要澄清一下。热修复技能差异于其他海内的Android“黑科技”。就好比,海内Android历程保活,是让app一连驻留在靠山制止被系统杀死,这既淹灭手机电量又占内存,挥霍了许多手机资源。再好比,app自行定制的推送处事,无节操地对用户举办信息轰炸。尚有更过度的全家桶,一个app同时拉起一票app,而且恒久占着内存,使到手机卡顿不堪。总归,这些技能都是为了app厂商的好处而损害手机利用者的实际体验。

而热修复技能是完全差异的,它到达的是一个手机用户和开拓者双赢的目标。不只厂商可以快速迭代更新app,使得成果能最快上线。而且由于热更新进程是毫无感知的,手机用户也淘汰了繁琐的更新步调,节减了大量期待更新的时间。这实际上是改进了Android的生态情况。只是这个中最重要的,是要担保热修复成果的不变性。而Sophix的不变性,是颠末尾无数开拓者检讨的,而且尚有手淘多年深厚的技能沉淀作为保障。

Android与iOS热修复的差异

前段时间,苹果封杀了iOS的热修复成果,这给iOS的开拓者带来了很大困扰。

热修复成果被克制,会使得许多app不得不靠直接发版举办更新,这样一旦新版本出了问题,整个更新迭代进程变得十分漫长。而且一些试验性成果无法举办灰度,这就使得一个重要成果的更新将直接全量发版,假如成果不足不变,波及范畴就变得很是广。并且,用户需要从头下载整个app,不只流程漫长,原本不到1MB的补丁就能办理的事,此刻不得不下载几十甚至上百MB的完整包才气更新。

苹果这一政策的推出,使得许多人也因此不看好Android的热修复技能了。在这里,我们可以撤销这种错误的见识。因为Android的环境和iOS是有极大差异的。主要有两个方面:

1. 谷歌和苹果在中国的职位差异

2. Android和iOS的开放性差异

谷歌在中国没有像苹果那样的节制力,纵然它想要封杀也不行能,海内是有各个安卓应用市场的,没有统一的app安装渠道。别的,Android是开源的,各个厂商都可以做定制,想统一各家的安装渠道险些是不行能的。

将来,无限大概

我们对付将来是很乐观的,Android的热修复规模不只不会受到封杀,反而尚有很大的成长空间。我们正在实验支持各大加固厂商,今朝阿里聚安详修复已经支持了Sophix,热修复团结安详加固,将会使得app的不变性和安详性大大提高,越发坚不行摧。甚至后续还可以与系统厂商相助,对系统app以致系统组件举办修复,这样就可以制止频繁OTA进级。

因此,热修复所能发挥是代价将是十分庞大的。热修复还可以与其他规模举办碰撞,激发无限的大概性。在这里,我们很是等候联袂宽大应用厂商以及ROM厂商,配合敦促Android的生态越发完善。

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

推荐阅读

点击下方图片即可阅读

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

西溪TV开播啦 | 阿里Java手册焦点成员首次表态

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

如何像阿里工程师一样高效办公?

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

存眷「阿里技能」 

掌握前沿技能脉搏

转载 l 相助 l 投稿

[email protected]

    标签: