点进来的同学应该是对JSPatch有初步的了解了,主要在此介绍一下我的学习总结:
- 首先要了解OC代码如何转换为JS代码,语法层面
- 如何实现动态,即如何通过服务器进行脚本下发
- 与后台协调如何更好解决多个版本下发的问题
- JSPatch安全问题,如果没有对JSPatch脚本加密,攻击者就会通过网络传输的中间人攻击手段下发恶意脚本到用户APP.接入JSPatch时请做好加密传输,只要做RSA非对称加密传输就不会有问题.
- 充分测试问题,灰度测试
- 防止连续crash
- 实现原理(OC与JS的调用,OC黑科技runtime)
一丶OC转换为JS代码
1.1 require
在使用OC类之前需要调用require('className'):
require('UIView')
var view = UIView.alloc().init()
或者在使用时去调用
require('UIView').alloc().init()
1.2 调用OC方法
调用类方法: var redColor = UIColor.redColor
获取Property就等于调用这个Property的getter方法:view.setBackgroundColor(redColor);
修改这个值就等于调用了setter方法:view.setBackgroundColor(redColor);
方法名转换,多参数要用_分割:`var indexPath = require('NSIndexPath').indexPathForRow_inSection(0,1);
这里只是简单介绍一下转换方法,其它的具体转换方法,请参考
JSPath作者,bang的文档
在平常使用过程中,作者提供了一个OC转JS代码的工具,点击这里查看:
JSPatch Conver,可以先写好要改动的OC代码,然后用工具进行转换,然后检查转换后的代码是否有误,确认无误之后,进入下一步测试阶段.
二丶下发JS脚本
2.1 版本管理
因为不同的版本存在的bug不同,而且新的版本已经把旧版本已知的bug修复,所以在下发版本的时候,一定要做版本的区分.同一版本也可对应多个修复文件,对应同一APP版本的新版本补丁覆盖旧版本补丁,如下图:
2.2 下载使用策略
这里本来是计划把下载和使用都放在didFinishLaunchingWithOptions：这个方法里,这里参考了一位同行的做法,使用js文件的代码放在didFinishLaunchingWithOptions： 而下载js文件的代码放在applicationDidBecomeActive: 因为这个方法在程序启动和后台回到前台时都会调用。然后设置一个间隔时间，根据一些�数据和权衡之后我们采用的是间隔时间设为1小时。 也就是说每次来到这个方法时，先要检测是距离上次发请求的时间间隔是否超过1小时，超过则发请求，否则跳过。如下图:
2.3 仓库设置
仓库设置也要有个规范的流程,不能乱来,要不然后期可维护性比较差.对于一个APP来说,有多个版本即分为多个文件夹,然后在文件夹里放入JS文件,供客户端下载,同时也可以在JS文件同层放入json文件来自定义这个流程.
三丶安全问题
使用JSPatch主要有两个安全问题,传输安全:JS脚本可以调用任意OC方法,权限非常大,若被中间人攻击替换代码,会造成较大的危害;执行安全:下发的JS脚本灵活度大,相当于一次小型更新,若未进行充分测试,可能出现crash等情况.
传输安全
我们的目的是防止传输过程中数据被篡改,然后做了一些危害程序的操作,而我们还傻乎乎的去执行这个文件- -,所以这里选择作者倾情推荐的安全性高,部署简单,门槛低的方案:RSA校验.这种方式属于数字签名,用了跟HTTPS一样的非对称加密,把非对称加密只用于校验文件,不解决传输过程中数据内容泄露的问题.整个校验过程如下:
- 服务端计算出脚本文件的MD5值,作为这个文字的数字签名.
- 服务端通过私钥加密第1步算出的MD5值,得到一个加密后的MD5值.
- 把脚本文件和加密后的MD5值一起下发给客户端.
- 把客户端拿到的已经加密过的MD5值,通过保存在客户端的公钥解密.
- 客户端计算脚本文件的MD5值.
- 比对第4步和第5步的两个MD5值(分别是客户端和服务端计算出来的MD5值),如果相等则通过校验.
只要通过校验,就可以确保脚本在传输过程中没有被篡改,因为第三方若要篡改脚本文件,必须要计算出新的脚本文件MD5并用私钥加密,客户端公钥才能解密出这个MD5值,而在服务器未泄露的情况下第三方是拿不到私钥的.
执行安全
因为一旦下发JS脚本,就代表客户端就会根据脚本文件执行方法(如果JS脚本替换类的方法写错了,当我没说...),如果某个地方的代码写的不够严谨,就可能导致大量crash,或者是一些奇怪的问题.需要有一些机制来避免这种情况发生.若要做的完整,可以分为:事发前(灰度),事发中(监控),事发后(回退).
灰度
首先需要在事发前把出现问题的影响面降到最低，对于中大型 APP，不能一次把脚本下发给所有用户，需要有灰度机制，也就是一开始只下发给其中一部分用户，看看会不会出现异常情况，再逐步覆盖到所有用户。有条件的话灰度的用户最好按机型/系统/地域等属性随机分配，尽量让最少的人覆盖到大部分情况。
监控
接着是事发了我们需要知道脚本有问题，需要对 APP 有一些监控机制，像 crash 监控，这个一般所有 APP 都有接入，再按需求自行加入其他监控指标。
回退
最后是事发后回退代码。一般为了避免不可预料的情况出现，JSPatch 脚本建议在启动时执行，APP 运行过程中不去除，所以这个回退建议的实现方式是后台下发命令，让 APP 在下次启动时不执行 JSPatch 脚本即可。
但这里能回退的前提是 APP 可以接收到后台下发的回退命令，若因为下发的脚本导致 APP 启动即时 crash，这个回退命令也会接收不到。所以建议再加一层防启动 crash 的机制，APP 在连续启动即 crash 后，下次启动不再执行脚本文件。
这里需要补充一下,JS脚本引起的crash按崩溃的阶段可分为:
- 调用到JS脚本里修改后的方法引起崩溃,这种可以通过下发新的JS脚本来解决.
- APP启动即崩溃,这种情况已经不能通过下发脚本解决.要有专门的防止连续crash的解决方案.
连续crash解决方案
(.........)等我专门研究清楚了重开一篇~~~
在文末帮偶像bang推荐一下他的JSPatch平台,大家如果由于某些原因不通过自家服务器下发脚本,可以通过这个平台来进行脚本的下发:JSPatch平台.
有问题欢迎联系我沟通交流,QQ:364385155.顺便给俺点个喜欢更好~
