背景
昨天新版上线后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的特性，寻找合适的方法以最小的代价进行重写。这也是本文所举实例的目的。
