使用JSPatch热修复指南

2017-01-06 本文已影响378人杭研融合通信iOS

JSPatch 是腾讯微信团队牛人bang开源的一种通过JavaScript调用iOS原生代码来实现热修复或者动态添加功能模块的开源项目，代码中的逻辑主要是如何通过JavaScript调用iOS原生代码。

对于开发者来说，如果想使用它，有两种方式:
一是使用腾讯对应JSPatch平台和相应sdk，
二是在源码上添加与自己平台（需要自己实现）交互的逻辑，实现脚本的下发功能。

最简便的方式自然是第一种方案，这样可以最快的接入这个功能，开发量最小。因为第二种方案涉及到平台的的代码逻辑和客户端的代码逻辑，需要处理脚本的版本管理、安全传输、CS的鉴权等多方面内容才能保证客户端的脚本是安全的。本文也将主要是以第一种方案为例进行介绍:

平台和SDK怎么用？

JSPatch平台需要首先注册用户app信息，然后会得到对应的appkey。可以看到这些配置成功后的页面（企业飞信是我们部门的产品，欢迎试用并吐槽), 可以看到appstore上的产品和appkey关联起来（其实JSPatch的平台不关注是否将脚本下发到了这个app，只是下发到这个appkey的请求源上），平台左侧边栏的几个功能方便跟踪热修复的动态和历史，右边排列着每个热修复的版本，点进去可以针对这个版本下发新的脚本。

JSPatch平台
下载sdk，配置到自己app工程中, 根据平台的wiki说明，将相关使用的代码逻辑添加到其中，要添加新的类来专门管理JSPatch sdk的接口调用逻辑，下面是调用实例，其中包含了本地调试、脚本下发和配置log、灰度下发等相关逻辑：

//  QFHotfixManager.m
//  热修复
//
//  Created by 陈明明 on 2016/11/7.
//  Copyright © 2016年 中移（杭州）信息技术有限公司. All rights reserved.
//

#import "QFHotfixManager.h"
#import <JSPatchPlatform/JSPatch.h>
static const NSString *HotfixAppkey = @"63bdb20dcce4f4fb";

// 是否使用本地脚本
#define TestScriptInBundle (1)

@implementation QFHotfixManager

+ (void)runHotfixScript
{
    
    [JSPatch setupLogger:^(NSString *msg) {
        //msg 是 JSPatch log 字符串，用你自定义的logger打出
        NSLog(@"JSPatch %@", msg);
    }];
    
#ifdef TestScriptInBundle
    [JSPatch testScriptInBundle];
#else
    // 条件下发
    [JSPatch setupUserData:@{@"userId": USER_PHONENUM}];
    
    [JSPatch startWithAppKey:HotfixAppkey];
    
    [JSPatch sync];
    
    [JSPatch setupCallback:^(JPCallbackType type, NSDictionary *data, NSError *error) {
        ;
    }];
#endif
    
#ifdef DEBUG
    [JSPatch setupDevelopment];
#endif
    
}
@end

基础设施建立完毕，我们可以通过一个简单的脚本验证下平台下发到脚本部署全过程：
本地建立一个main.js，内容为空，然后上传到平台，建立一个版本号，并将xcode中的版本号改为这个版本号，然后启动工程，setupLogger方法打印log来跟踪脚本下发和配置，log中会显示下发的版本号等信息。

热修复代码如何写？

流程没问题了，真的发生线上故障，我们该如何写热修复代码？（如果有JavaScript基础的话，会更轻松点。）其实相关信息在github上基本都有，

首先把基础语法学好：
https://github.com/bang590/JSPatch/wiki/JSPatch-%E5%9F%BA%E7%A1%80%E7%94%A8%E6%B3%95#1-require
日常调试时如果有问题，可以在看看有没有相关信息：
https://github.com/bang590/JSPatch/wiki/JSPatch-%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98
还有问题可以在issue问题集中搜索一下：
https://github.com/bang590/JSPatch/wiki/%E5%A6%82%E4%BD%95%E6%8E%92%E6%9F%A5%E9%97%AE%E9%A2%98
https://www.google.com.hk/search?q=私有变量%20site%3Agithub.com%2Fbang590%2FJSPatch
把其中的关键字 {私有变量} 替换成你想问的问题就可以了。

最后还是无法解决可以到qq群 207283178 中试试。
结合个人实践，总结了从写脚本到脚本发布到验证的流程将在下节一并展示。

相对完善的调试和发布流程是怎么样的？

一般来说，使用热修复来解决的线上故障是频率较高的crash或严重影响业务的bug，而且热修复面对的是最终用户，我们要保证热修复的准确性，既包含可以确定地解决问题，也包含不会导致其他问题，不能通过下发多次脚本才最终解决，这样对产品的信任度产生很大影响。所以这就需要一个相对完善的调试和发布流程，需要认真对待这类bug，下图展示大概流程，后面讲详细描述：

热修复发布流程

主要有三大阶段：

第一阶段：确定问题阶段

定位问题复杂度，如果代码改动量巨大设计类多，这种修改可能会引入其他问题，需要慎重考虑是否热修复？是否下个版本修复？
确定问题解决方式，尽量用相对简单，改动代码方式较少的方式，这样可以避免影响面过大。但也要注意下个发布版本中的代码要通过最好的改动方式来解决。
这里也建议做好类中方法的封装，尽量避免超长方法的出现，一方面不方便维护，另一方面热修复碰到这种超长方法心里就骂那个方法的作者吧。
评估代码改动影响面并同步给测试，这一步一定要尽量细致，这样测试才能通过更多的case全面的测试这个问题，及是否影响其他方面。

第二阶段：通过热修复解决问题

编写脚本：我们首先通过JSPatch提供的mac工具JSPatchConvertor, 对要热修复的代码快速转化一下；
这个工具还不完善，所以需要根据基础语法review一遍，修改一遍；
再用在线工具验证语法准确性；
开发人员需要经过本地调试，先验证热修复脚本正确性及是否带来其他问题，
确定没问题，再通过SDK的开发模式, 再一次来验证下发到客户端的脚本正确性；
让测试人员测试条件发布（按人）的版本：条件使用测试的账号，测试通过；
（更稳妥可以先灰度下发（按比例））全量下发，测试人员再次验证其他账号，并看用户的实际使用情况是否已经修复。
全量下发时，标注好描述，便于后期在历史补丁中快速定位发布的脚本。

第三阶段：善后

虽然平台有历史补丁可以浏览每次发布的补丁，但我们也要做好热修复脚本的代码管理，将其纳入svn或git记录中。
针对热修复的问题，我们native上也需要彻底用更好维护的方式解决，app的下个发布store版本测试人员验证这个问题在native层面是否也完全修复。

热修复要有节操

热修复启用前后，app的展现形式也许会让用户困惑，怎么app一下就好了，所以涉及到我们该如何提示给用户热修复？这只是用户体验的一方面，可能还会有流量方面对用户的困扰（大多数情况下代码少的话脚本是KB为单位还好），所以app需要更有节操的使用热修复：

最粗糙的方式就是不提示，也是最开始集成最常见的形式，将热修复的启动放在 didFinishLaunchingWithOptions：方法中，只要每次app（crash后或杀掉进程）重新启动便自动与平台沟通是否有热修复脚本，只要有下发便立刻执行热修复；

为了更及时修复问题，每次回到前台 applicationDidBecomeActive：根据一定时间策略去检查是否要热修复，并且给出热修复的提示，具体可以参考这个博客；
为了给用户更好的体验，我们可能需要更加人性化的热修复，比如可以参考12306这个方式：

12306热更新

另外，我们还可以根据热修复情况分两种：强制热修复，选择性热修复。当前强制性热修复时，通过toast提示正在热修复，用户无法进一步操作app（即使重启app）；选择性热修复主要是考虑热修复可能占用一定流量，或者当前问题可能不影响某些用户的正常使用，这时我们可以提示热修复脚本大概占用的流量，及热修复可以解决的问题，用户可以点击确定使用，或者不使用，当用户点击不使用，不再提示这个版本的热修复。

踩过的小坑

本地调试时，JSPatch的配置的.js文件名字必须是main.js。将main.js文件（注意一定要utf-8编码）放在项目工程目录下，并添加到项目中。
注意：

本地调试目前是没有log打印的，所以需要自己在浏览器中看是否已经加载，打断点看执行情况；
main.js文件一定要utf-8编码；

......