热修复JSPatch之接口设计

  接上篇文章《iOS紧急发布实践心得》 中所说为了减少紧急发布的次数，同事也为了保证能够从容的解决我们的线上 bug，不造成重大的影响，拉低我们的KPI，我们可以建立属于我们自己的热修复机制。

准备：什么是JSpatch？

   这个网上已经有很多的介绍了，这里就不详细的说了。总而言之，JSpatch就是gitHub上的一个开源库，它利用了OC中的runtime机制，实现了利用javaScript脚本替换OC中的方法和代码。同时呢，通过后台下发js脚本，达到我们不迭代app版本修复在线bug 的目的。

兵马未动，粮草先行：JSPatch后台下发接口设计

  后台接口主要有两个，脚本上传API，脚本下发API。这两个接口主要满足的要求如下：
1，安全性

1) 因为脚本可以修改我们的app代码，要求我们必须限制脚本上传的API只能在公司内网访问，并且需要有管理员的密码或者动态授权码。这个一定要进行限制，防治被恶意攻击。（从源头控制保证代码的安全）
2) 为了防治脚本在网络传输过程中被篡改，我们必须对脚本进行验证签名，保证我们拿到的脚本是安全的，可靠的。通过验证的脚本才会被我们执行(保证脚本不被篡改)

2, 易用性

必须要保证，修复脚本上传后，加签名，加密 操作都在服务器端完成。防止脚本在网络传输的时候造成编码格式等问题的出现，或者公司网络限制带来不必要的麻烦。（我们公司后台老大是我们的行政领导，加签名，加密这一块是我在我们前端手动完成的。呜呜呜，用起来很是麻烦）另外还要有开关功能，能够及时的打开，关闭脚本热修复功能。

3，通用性

必须要保证我们的热修复脚本能够针对某一版本的app，某一版本的操作系统，不同的操作平台：iOS／andriod 进行热修复。js脚本也要有自己的版本号，保证修复脚本的独立性和唯一性。而且还要支持多个app的热修复功能。能够区分测试环境和生产环境。

4，健壮性，持久性

需要保证，上传的脚本不能被后台随意，私自删除修复脚本，修复脚本的删除必须经过评审，审批。另外要及时修复线上的bug，保证下一个版本不再出现同样的问题。

5，好的性能

接口的脚本不能每次都下发给前端，应该进行相关的判断，如果已经下载过脚本了，就不再下载。如果之前前端已经存储了一个js脚本，但是后续又要下发新的脚本。如何处理多个js脚本，不能直接删掉，而应该考虑几种情况，制订相关的处理策略。（目前我们这边是直接删除，后续如何处理多js脚本的情况，我这边会后期完善）

参考如上的要求我们对上传脚本的接口定义如下：

{
platform:iOS   //操作系统iOS或Android
appType: 123   //每个app的编号，具体根据实际情况命名，不能重复
appVersion:2.11.1 // app的版本号
sdkVersion:1.2.3  //操作系统的版本号，针对性的修复某一版本下的app的bug，默认为空。为空的情况下对所有的操作系统都下发脚本
hotfixVersion:1.0 //热修复脚本的版本号，区分不同的热修复脚本，保持其独立性和唯一性
isOnline:1       //热修复脚本的开关，是否开启或者关闭热修复功能。
}

另外热修复脚本我们在请求body中塞入，具体如下：

请求热修复脚本的接口定义如下：

{
platform: iOS,  // iOS/addroid 操作系统
appType: 123,   //对应app的编号
appVersion: 1.0, //app的版本号
sdkVersion: 9.0，//操作系统的版本号，应该以系统的为准，不可以在app端写死。
}

接口返回数据如下：

{

    "signature" : "1111111111"  //在线修复js脚本字符串sha加密后得到的字符串
    "script"    : ""            //iOS 需要的js脚本或者android 需要的修复脚本
    "timeStamp" : ""            //本次服务器端提交脚本的时间戳
    "on-off"    : "1"           //1 或 0 代表在线开关的开启
  }

  注意：此处是需要提示后台小伙伴去做的，后台小伙伴获取到热修复脚本后需要对脚本内容执行sha256，或者sha512操作，获取相应的字符串str，然后用私钥对str进行加密生成签名。（不要再使用MD5,或者别的加密算法，具体原因点击查看）
  前端小伙伴获取到热修复的js脚本后获取脚本内容，然后执行相应的sha操作，生成相对应的str1字符串，同时我们用公钥对获取到的签名串进行解密，得到str2；比较str1和str2是否相等，如果相等那么签名验证成功，说明我们的热修复脚本，没有被修改，是安全的，可考的，我们可以执行后续的修复操作。iOS具体修复教程我会在下一篇博客《热修复JSPatch之实战教程》

更多优质文章，可以微信扫码关注：