前言
在 2020.07.10 18:30 左右 iOS APP 崩溃率上升到 1%+ 了。
问题
经过查看控制台得到如下错误信息:
[NSNull count]: unrecognized selector sent to instance
断点停留在 Facebook SDK 里面,错误信息跟控制台一样。接着发现 Github Issues 里面已经有人讨论这个问题了。评论数每分钟都在增加。有人甚至把 SDK 接口的响应 JSON 数据贴了上来,发现是接口问题,跟 SDK 版本没有关系。
然后看到有人已经贴出了 Facebook 已经在调查的公告,表示已经知道发生的问题,已经在调查中。但是这个时候已经过去了半个小时。崩溃率上升到 2.0%+。
最后崩溃率上升到 4.0%+,大概在 20:20 后崩溃率开始下降。
原因
Facebook 更新了服务端接口,接口返回数据里面字段 restrictive_data_filter_params
为 null,但是 FBSDKCoreKit 在使用这个字段的时候没有做安全判定,直接当做 NSDictionary 来处理,调用 count 方法从而导致崩溃。
反思
- Facebook 在技术流程上有很大的问题,两个月内出现两次类似的生产事故,最后仅仅以一句 “We apologize for any inconvenience.” 收尾;
- Facebook 的时效性存在延迟,问题在 20点+ 已经修复,但是公告状态 22点 才将状态转换为 “Resolved”。导致很多人保持 working 状态,不停地在留言发问 “Seems Facebook fixed it. Can anyone confirm?”;
- 崩溃可能会造成崩溃率不准确,比如 Firebase 因为收集崩溃日志太多造成的服务器压力而不得不限流;
- 收获到一个很好用的站点:Real-time problem & outage monitoring,如果你不确定问题是否已经修复,可以参考热门的 APP 的趋势;
- 第三方 SDK 开关是个可以考虑的功能,虽然做不到像系统 Framework 一样动态加载,但是起码能保住业务流程;
- 这两次的问题都可以用
NSObjectSafe
这个类可以很好的规避这个问题。给 NSNull 类扩展 count 方法是饮鸩止渴; - Swift 的类型安全真的真的很重要;
- Facebook 的 APP 为什么没有崩溃,因为它们用的是 React native,无需用到这些 SDK;
最后
作为开发者需要对自己写的和引用的每一行代码负责,但是在业务功能要求下除了依赖其 SDK 往往别无选择。NSObjectSafe
也无法规避将来要发生的未知的问题。但是将来相信会出现新的解决办法!
本文由 Bill 创作。
最后编辑时间为: 2020.07.11 at 08:33 am
kkk
If you have any questions, please let me know.