动态部署之JSPatch

一、课题背景

在APP发布到AppStore之后,发现有bug需要修复,按正常的流程是,在修复bug之后,重新发布版本,等待漫长的苹果审核。

二、解决方案

为了频繁发布版本,以及等待苹果的审核,我们需要使用动态部署来做动态更新,不仅可以修复在线bug,还可以按需发布功能,替换主题等。

(1)做到动态部署,至少要满足以下需求:

         1、View和事件都要能够动态部署

         2、功能完整

         3、便于维护

(2)我们来看看行业内使用的各种动态部署技术以及优缺点:

1、web APP

实现方案

其实所谓的web app,就是通过手机上的浏览器进行访问的H5页面。这个H5页面是针对移动场景特别优化的,比如UI交互等。

优点

无需走苹果流程,所有苹果流程带来的成本都能避免,包括审核周期、证书成本等。

版本更新跟网页一样,随时生效。

不需要Native App工程师的参与,而且市面上已经有很多针对这种场景的框架。

缺点

由于每一页都需要从服务器下载,因此web app重度依赖网络环境。

同样的UI效果使用web app来实现的话,流畅度不如Native,比较影响用户体验。

本地持久化的部分很难做好,绕过本地持久化的部分的办法就是提供账户体系,对应账户的持久化数据全部存在服务端。

即时响应方案、远程通知实现方案、移动端传感器的使用方案复杂,维护难度大。

安全问题,H5页面等于是所有东西都暴露给了用户,如果对安全要求比较高的,很多额外的安全机制都需要在服务端实现。

总结

web app一般是创业初期会重点考虑的方案,因为迭代非常快,而且创业初期的主要目标是需要验证模式的正确性,并不在于提供非常好的用户体验,只需要完成闭环 即可。早年facebook曾经尝试过这种方案,最后因为用户体验的问题而宣布放弃。所以这个方案只能作为过渡方案,或者当App不可用时,作为降级方案 使用。

2、hybrid APP

通过市面上各种Hybrid框架,来做H5和Native的混合应用,或者通过JS Bridge来做到H5和Native之间的数据互通。

优点

除了要承担苹果流程导致的成本以外,具备所有web app的优势

能够访问本地数据、设备传感器等

缺点

跟web app一样存在过度依赖网络环境的问题

用户体验也很难做到很好

安全性问题依旧存在

大规模的数据交互很难实现,例如图片在本地处理后,将图片传递给H5

总结

Hybrid方案更加适合跟本地资源交互不是很多,然后主要以内容展示为主的App。在天猫App中,大量地采用了JS Bridge的方式来让H5跟Native做交互,因为天猫App是一个以内容展示为主的App,且营销活动多,周期短,比较适合Hybrid。

3、React-Native

React-Native这个框架比较特殊,它展示View的方式依然是Native的View,然后也是可以通过URL的方式来动态生成 View。而且,React-Native也提供了一个Bridge通道来做Javascript和Objective-C之间的交流,还是很贴心的。

然 而研究了一下发现有一个比较坑的地方在于,解析JS要生成View时所需要的View,是要本地能够提供的。举个例子,比如你要有一个特定的 Mapview,并且要响应对应的delegate方法,在React-Native的环境下,你需要先在Native提供这个Mapview,并且自己 实现这些delegate方法,在实现完方法之后通过Bridge把数据回传给JS端,然后重新渲染。

在这种情况下我们就能发现,其实 React-Native在使用View的时候,这些View是要经过本地定制的,并且将相关方法通过RCT_EXPORT_METHOD暴露给 js,js端才能正常使用。在我看来,这里在一定程度上限制了动态部署时的灵活性,比如我们需要在某个点击事件中展示一个动画或者一个全新的view,由 于本地没有实现这个事件或没有这个view,React-Native就显得捉襟见肘。

优点

响应速度很快,只比Native慢一点,比webview快很多。

能够做到一定程度上的动态部署

缺点

组装页面的元素需要Native提供支持,一定程度上限制了动态部署的灵活性。

总结

由 于React-Native框架中,因为View的展示和View的事件响应分属于不同的端,展示部分的描述在JS端,响应事件的监听和描述都在 Native端,通过Native转发给JS端。所以,从做动态部署的角度上讲,React-Native只能动态部署新View,不能动态部署新 View对应的事件。当然,React-Native本身提供了很多基础组件,然而这个问题仍然还是会限制动态部署的灵活性。因为我们在动态部署的时候, 大部分情况下是希望View和事件响应一起改变的。

另外一个问题就在于,View的原型需要从Native中取,这个问题相较于上面一个问题倒是显得不那么严重,只是以后某个页面需要添加某个复杂的view的时候,需要从现有的组件中拼装罢了。

所以,React-Native事实上解决的是如何不使用Objc/Swift来写iOS App的View的问题,对于如何通过不发版来给已发版的App更新功能这样的问题,帮助有限。

4、Lua Patch

大众点评的屠毅敏同学在基于wax的基础上写了waxPatch,这个工具的主要原理是通过lua来针对objc的方法进行替换,由于lua本身是解释型语言,可以通过动态下载得到,因此具备了一定的动态部署能力。然而iOS系统原生并不提供lua的解释库,所以需要在打包时把lua的解释库编译进app。

优点

能够通过下载脚本替换方法的方式,修改本地App的行为。

执行效率较高

缺点

对于替换功能来说,lua是很不错的选择。但如果要添加新内容,实际操作会很复杂

很容易改错,小问题变成大问题

总结

lua的解决方案在一定程度上解决了动态部署的问题。实际操作时,一般不使用它来做新功能的动态部署,主要还是用于修复bug时代码的动态部署。实际操作时需要注意的另外一点是,真的很容易改错,尤其是你那个方法特别长的时候,所以改了之后要彻底回归测试一次。

5、JSPatch

这个工作原理其实跟上面说的lua那套方案的工作原理一样,只不过是用javascript实现。而且最近新出了一个JSPatch这个库,相当好用。

优点

同Lua方案的优点

打包时不用将解释器也编译进去,iOS自带JavaScript的解释器,只不过要从iOS7.0以后才支持。

缺点

同Lua方案的缺点

总结

在对app打补丁的方案中,目前我更倾向于使用JSPatch的方案,在能够完成Lua做到的所有事情的同时,还不用编一个JS解释器进去,而且会javascript的人比会lua的人多,技术储备比较好做。

6、JSON Descripted View

其实这个方案的原理是这样的:使用JSON来描述一个View应该有哪些元素,以及元素的位置,以及相关的属性,比如背景色,圆角等等。然后本地有一个解释器来把JSON描述的View生成出来。

这 跟React-Native有点儿像,一个是JS转Native,一个是JSON转Native。但是同样有的问题就是事件处理的问题,在事件处理 上,React-Native做得相对更好。因为JSON不能够描述事件逻辑,所以JSON生成的View所需要的事件处理都必须要本地事先挂好。

优点

能够自由生成View并动态部署

缺点

天猫实际使用下来,发现还是存在一定的性能问题,不够快

事件需要本地事先写好,无法动态部署事件

总结

其实JSON描述的View比React-Native的View有个好处就在于对于这个View而言,不需要本地也有一套对应的View,它可以依据 JSON的描述来自己生成。然而对于事件的处理是它的硬伤,所以JSON描述View的方案,一般比较适用于换肤,或者固定事件不同样式的View,比如 贴纸。

三、JSPatch的使用

1、JSPatch的基础原理

JSPatch 能做到通过 JS 调用和改写 OC 方法最根本的原因是 Objective-C 是动态语言,OC 上所有方法的调用/类的生成都通过 Objective-C Runtime 在运行时进行,我们可以通过类名/方法名反射得到相应的类和方法。

理论上你可以在运行时通过类名/方法名调用到任何 OC 方法,替换任何类的实现以及新增任意类。所以 JSPatch 的基本原理就是:JS 传递字符串给 OC,OC 通过 Runtime 接口调用和替换 OC 方法。

2、JSPatch的用法

a、使用办法参照官方文档:http://www.jspatch.com/Docs/intro 

b、JSPatch的相关知识请参考github上的开源项目,这里能满足绝大部分知识的学习

https://github.com/bang590/JSPatch

你可能感兴趣的:(动态部署之JSPatch)