背景

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