react native开发工作当仓央嘉措遇上纳兰性德

使用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,下图展示大概流程,后面讲详细描述:


热修复发布流程

主要有三大阶段:

第一阶段:确定问题阶段

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

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

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

第三阶段:善后

  1. 虽然平台有历史补丁可以浏览每次发布的补丁,但我们也要做好热修复脚本的代码管理,将其纳入svn或git记录中。
  2. 针对热修复的问题,我们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编码)放在项目工程目录下,并添加到项目中。
注意:

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

......

上一篇下一篇

猜你喜欢

热点阅读