基于JSPatch的iOS在线hotfix实例一则
2016-01-28 本文已影响705人
xi_lin
背景
昨天新版上线后fabric上冒出了一批crash,调查后发现与这个issue相关。
作者已经在这个commit中修复了。原因是新版中利用了UITableViewCell
的私有实例变量_separatorHeight
,但在iOS 7.0.x中并没有这个变量,造成了valueForUndefinedKey
抛出的NSUnknownKeyException
。
线上出这个坑有两个原因:
- 测试时我们最低只测到了iOS 7.1.0,所以没发现这个问题= =
- 我的
Podfile
中依赖声明是pod 'UITableView+FDTemplateLayoutCell', '~> 1.4.beta'
。这样声明会在同样的第二位版本号内自动升级依赖。
翻看Podfile.lock
发现我在1月7日时执行过一次pod update
升级到了1.4。作者是1月9日fix的,不过没有再升级版本号。虽然我发布新版前有重新执行过pod update
,但是CocoaPods
的机制似乎是同版本不检查HEAD commit,并没有更新文件。
还好应用内已经建立了JSPatch的hotfix机制。现在的问题就是如何打这个patch了。
方案
JSPatch的原理在此不再加以说明,可能参考bang神的说明。通常crash都是发生在特定的方法调用中的,通过JSPatch打hotfix的方案一般也是通过覆盖该方法的实现来完成。
针对这次的问题,OC代码实现中的修改只有两行,将出问题的方法换了另一种实现。但对于patch来说,能做到的最直接的方案就是重写整个fd_heightForCellWithIdentifier:configuration:
方法。不过这个方法有60行左右,改写一遍的成本比较大。
换一个角度来看,出错的根本原因是valueForKey
访问到了不存在的property。此时其实会调用receiver的valueForUndefinedKey
再给我们一次挽救的机会。所以直接重写UITableViewCell
的valueForUndefinedKey
方法就可以了!
Patch代码如下:
defineClass("UITableViewCell", {
valueForUndefinedKey: function (key) {
if (key.isEqualToString("_separatorHeight")) {
return 1.0 / require('UIScreen').mainScreen().scale();
}
return self.ORIGvalueForUndefinedKey(key);
}
}, {});
发布上线后再也没有crash上报了。
总结:
- Podfile中以固定版本为宜,虽然在一般CocoaPods的版本约定中,形如x.y.z的版本号只变动z时接口不变,也是有可能引入新bug的。回归测试的成本还是比较大的。
- 程序本身的代码应该尽量控制单个方法的长度,尽量拆分,既方便后期的维护,也方便hotfix时的修改。
- 覆盖方法时有几种场景:
- 调用原有的方法实现,对原方法的返回结果进行额外的处理
- 对方法的传入参数进行处理后再传递给原方法
- 直接重写整个方法实现
虽然JSPatch的功能比较强大,但是重写大段逻辑的成本也是比较高的。所以在进行hotfix时应尽量寻找简单的处理文案。在定位到相关的位置后,不一定要局限在当前造成crash的方法上,应该充分利用OC runtime的特性,寻找合适的方法以最小的代价进行重写。这也是本文所举实例的目的。