移动端热更新方案(iOS+Android)

    xiaoxiao2021-03-25  210

    PPT资源包含iOS+Android 各种方案分析:https://github.com/qiyer/Share/blob/master/热更新分享PPT.pptx

    一 、热更新(热修复)产品背景

    这里谈到的热更新都是指APP(不包含网页)。APP按大类别可以粗略分为 应用 和 游戏。 APP的开发周期是极其快速的,在实际开发流程中,我们总会有一些需求迫使我们短时间内快速上线,比如需求流程出错,程序员主观导致的一些bug(闪退、主要功能无法使用),节日活动小版本改动。早期APP Store 的审核速度可以用龟速形容,一旦你app出问题了,想修复重新上一个新版本可能2周或是更长,对于app公司方是无法接受的。(现在App Store审核速度正常情况下大概1-3天) 虽然一些大公司有绿色通道,可以第一时间联系到 App Store 或是 其它一些安卓渠道 帮忙测试上线。但对于绝大部分公司来说没有这个特权。(即使走绿色通道,也需要一定的时间,另外并不是所有用户都愿意更新整个客户端) 热更新技术呼之欲出。 其实热更新早就存在,只是很多方案在一开始并不成熟,一方面没有持续的更新维护,导致很多热更新方案最终夭折。

    二、iOS APP 热更新方案出现的机遇

    为什么从14年开始一些成熟的热更方案开始爆发?

    在2013WWCD上苹果已经正式发布了iOS7 beta版并发布了下载,同年9月18日iOS7正式版发布了下载。 作为本次iOS的升级带来了iOS热更方案的关键,JavaScriptCore。 在iOS7之前,原生应用和Web应用之间很难通信。如果你想在iOS设备上渲染HTML或者运行JavaScript,你不得不使用UIWebView。iOS7引入了JavaScriptCore,功能更强大,使用更简单。然而现在可以利用JavaScriptCore的先进功能了,它可以: 1.运行JavaScript脚本而不需要依赖UIWebView; 2.使用现代Objective-C的语法(例如Blocks和下标); 3.在Objective-C和JavaScript之间无缝的传递值或者对象; 4.创建混合对象(原生对象可以将JavaScript值或函数作为一个属性)。

    iOS7刚出来并不是所有iphone用户都选择升级,意味很多用户还是iOS7 之前的版本,那么他们就没法使用JavaScriptCore。苹果于2014年WWDC(苹果开发者大会)发布的新开发语言Swift,最低支持iOS7(苹果建议)。苹果在强推用户升级这方面一直够霸道(经常不小心就升级了),很快iOS7以及以上用户占据了主流,逐渐的各大厂小厂APP最低版本支持变成了iOS7,现在的话大部分是最低支持iOS8 。

    三、各方案优缺点对比

    1、 Rollout.io 、 JSpatch、 DynamicCocoa比较

    为什么把标题3个方案放一起比较?因为他们都是适合小更新,都是针对iOS平台的非跨平台热更方案, 原理和部署方案比较接近。 其中 Rollout 不仅仅支持OC ,还支持Swift,脚本语言是javascript,已经平台化了,若干个产品使用。(建议大家可以研究一下Swift的热更原理,OC大家基本比较理解了) JSpatch 跟 Rollout 很像(除了不支持Swift),已经平台化,而且部署 发布流程 几乎和 rollout一样,国内各大产品都在用。 DynamicCocoa是滴滴搞出来的,我有看到sunnyxx 在 16年8月份 博客上在研究这块。目前还没有开源,滴滴自己的产品流 在使用,预计17年上半年开源。它也是只支持OC,不过有一个很大的进步是,不用我们再去写蹩脚的js脚本了,因为他们提供了工具可以用OC写,然后自动生成js。另外它还支持xib,storyboard,图片等资源的更新。(青出于蓝胜于蓝)

    2、React Native、 Weex比较

    React Native 和 Weex 都是跨平台的热更方案,Weex出来的晚,功能相对强大一点,具体表现为不仅支持iOS、Android,还支持H5. RN 在实现原理 和 Weex 还是 有很多共性的,不过Weex 做得更好点,一次编写可生成三平台代码。RN重视平台独立性,不能做到100%代码共用。

    RN是facebook开源的,说实话刚出来时候那性能确实不咋的,加上一开始还不支持Android,还得去学习jsx规范,于是出现了看好、看衰派。不过随着RN的不断优化、安卓的支持、文档的规范、框架的稳定,越来越多公司开始采用了,包括天猫和手机淘宝部分模块,腾讯的QQ、 QQ空间、QQ音乐、全名K歌 等。然后一度出现原生iOS 和 Android 开发要GG的段子,同时也出现了滥用RN,很多小公司跟风搞,结果是RN实现的模块出了不少bug,原因我不想分析了。(比如平安某医生)

    Weex是阿里推出的,目前阿里系产品都已经开始使用,16年双11,页面99.6%是Weex实现的,说明其已经经得起实战验证。阿里系之前也有试用RN,为什么没有继续试用?RN的JSX写法很别扭这是其一,其二就是没办法实现100%代码共用,其三就是RN某些地方也有性能问题(iOS的UITableview就是个槽点),另外RN自身的bug以及性能优化 太被动。然后才有了Weex 横空出世的机会。最近Weex 官网也出了,平台化了,支持中英文,我就想说两个字:“不仅仅是开源,阿里野心不小”!未来一波weex学习潮。。。

    由于使用RN的成功产品太多,我就懒得截图了,脸书系、腾讯系、京东系、手机百度、若干国外app。

    3、Wax 、Hybrid介绍

    先谈谈Hybrid App开发,现阶段主流的平台包括PhoneGap,AppCan,appMobi,Titanium等,它们基于webkit开源内核,使用HTML5 标准开发,适配机型简单,支持开发者自定义插件,并能很好的应用于商业,教育,娱乐等行业,成为移动开发者的首选开发平台。但是么,性能确实有点差,基本上产品前期会采用这种方式,公司稍有起色,基本上招兵买马原生重构之。加上现阶段RN 和 Weex 的成熟稳定, Hybrid App已经不适合那种强频次、高性能需求的APP 开发方案了。(这里补充个案例,facebook当年信心满满的宣布要用h5作为移动端产品方案,并且号称不会使用原生,但经过一阶段时间,改成原生开发了,直接打脸了,不过还好后来推出了React Native,挽回了一点面子)

    Wax需要特别说一下,因为它的脚本语言不是javascript,而是lua,在应用开发里面算是异类。(PS:不过lua在游戏开发热更中可是男一号) 还记得大明湖畔的游戏《愤怒的小鸟》吗?它就是基于Wax框架编写的。但是,后来作者13年开始不维护了,这下急坏了阿里系,因为他们家产品有使用wax,后来阿里接手了wax的更新维护,虽然支付宝后来使用了JSpatch(坏笑)。

    这里简单说下为什么脚本语言有的是js,有的是lua,为什么应用开发大部分都是用js作为脚本语言? 答:个人观点,从脚本的性能来讲 lua是优于js,但lua是小众语言,相关类库不完善,文档论坛也不是非常成熟。js本就是web起家的,各种类库、文档、论坛成熟齐全。应用开发相比于游戏开发没有那么高的性能追求,js作为应用开发的脚本语言性能基本上没有多大问题。Cocos2d-X 和 Unity3d 热更大部分采用 lua,当然 cocos2d-X也有js版本,不过性能确实不如lua版本,不过js版本好处就是可以成h5游戏。

    4、补充说明

    何为GCC?

    什么是GCC?GCC是由GNU之父Stallman所开发的linux下的编译器,全称为GNU Compiler Collection, 目前可以编译的语言包括:C, C++, Objective-C, Fortran, Java, and Ada 等。 GCC包括前端和 后端: GCC目录下除去gcc/config目录外的其他文件是各个语言的编译器前端源文件,一般放在各自语言命名的目录下,例如cp(C++)、Java、fortran等。唯一例外的是C语言,它的前端源文件同GCC的通用文件(包括中间表示、中间优化等)一起,散放在gcc目录下。  gcc/config目录是gcc在各种硬件或操作系统平台下的后端源文件,负责把GCC生成的中间表示转换为各平台相关的机器码、字节码或其他目标语言。

    何为LLVM 、Clang ?

    LLVM是apple赞助支持的,励志取代GCC。OC早期是利用GCC,但由于和Apple合作出了问题,然后Apple支持了LLVM,取代GCC,目前Xcode编译都是利用LLVM。目前只支持C、C++、OC。 Clang是LLVM的前端,负责将OC编译成语法树(AST)。

    说了这么多,就是滴滴这次逼格有点高,直接利用Clang生成的语法树进行解析,然后转译成js。 这样就避免了iOS程序员去写ios风格的js操蛋脚本。

    四、iOS拓展资源

    http://mp.weixin.qq.com/s/qRW_akbU3TSd0SxpF3iQmQ http://blog.csdn.net/Tencent_Bugly/article/details/51878361 http://www.open-open.com/lib/view/1481701561391 http://www.cnblogs.com/alibaichuan/p/5475143.html https://github.com/bang590/JSPatch/wiki/JSPatch-实现原理详解 http://www.tuicool.com/articles/rQ77J3q http://blog.cnbang.net/tech/2698/

    五、Android APP 热修复方案

    1、百川Hotfix 不仅仅只基于AndFix,而是灵活切换热部署和冷部署的方案;实现了资源、SO文件、类修复的实时生效,同时采用了傻瓜式接入方案,完全不侵入打包过程,对用户提供了可视化的UI界面打补丁。(阿里)

    2、美团Robust 在整个打Patch过程中,该方案正常的使用DexClassLoader,兼容性高;未反射注入,能够实时生效。该方案的缺点在于:因为在每端函数前插入代码,需要侵入打包过程;原来能被ProGuard内联的函数不能被内联了,所以可能导致方法数的增加,可能会超过65536限制,同时也会导致APK体积增大;该方案不支持SO文件和资源文件的修复。

    3、手机QQ空间 该方案类似谷歌的Multidex ,在保障稳定性的前提下兼容性很高。缺点是:不支持实时生效;在Davilk下,类加载存在性能问题;Art下,补丁包涵有类、父类以及引用该类的所有类,因此补丁包较大;由于原DEX中的类需要引用额外的DEX类,需要侵入式打包。

    4、微信Tinker 该方案中通过自研DexDiff算法,深度利用Dex的格式来减少差异的大小,从而做到补丁包足够小。其缺点在于:不支持实时生效;由于补丁DEX需要和原DEX合并,需要占用额外内存和磁盘空间,并且很容易因为内存消耗等原因合并失败;与QQ空间补丁技术相同,同样需要侵入式打包。

    六、更多以及感谢以下链接

    https://yq.aliyun.com/articles/67136 http://www.cnblogs.com/alibaichuan/p/5863616.html http://www.tuicool.com/articles/rQ77J3q http://blog.csdn.net/u010963246/article/details/51995193

    转载自:http://www.cnblogs.com/qiyer/p/6399692.html

    转载请注明原文地址: https://ju.6miu.com/read-308.html

    最新回复(0)