iOS自定义键盘扩展崩溃：CoreFoundation中doesNotRecognizeSelector报错

这种无业务代码痕迹的系统层崩溃确实让人头疼，我之前帮好几个开发者排查过类似的键盘扩展崩溃问题，给你梳理几个针对性的排查方向：

• 排查系统对象的意外修改
  虽然你没重写willPerformHostCallback相关方法，但要警惕第三方库或自己的代码是否通过分类、关联对象、KVO偷偷修改了NSExtensionContext的行为。比如有些埋点、日志框架会给系统类注入方法，如果方法名和系统私有方法（比如_willPerformHostCallback）冲突，就会触发doesNotRecognizeSelector。你可以全局搜索项目里对NSExtensionContext的分类或关联操作，也可以临时移除所有第三方库，看崩溃是否消失，逐个排查嫌疑库。

• 检查扩展的配置与权限
  键盘扩展的Info.plist配置异常也可能导致系统回调时上下文状态错乱：

  • 确认NSExtensionActivationRule的规则是否合理，有没有过度限制或错误配置；
  • 检查RequestsOpenAccess权限是否正确设置，有些场景下权限缺失会让系统上下文对象处于异常状态；
  • 验证扩展的部署目标是否和主App一致，跨版本的API兼容问题也可能触发这类崩溃。

• 用调试工具深挖崩溃场景
  即使调用栈没有业务代码，也能通过工具找到线索：

  • 开启Xcode的Zombie Objects调试，虽然崩溃对象是系统类，但有时候能抓到是哪个对象被误发了不存在的selector；
  • 用Console.app抓取崩溃前的系统日志，看有没有Extension invalidated、Context mismatch这类异常提示；
  • 用Memory Graph Debugger查看崩溃瞬间的内存状态，排查是否有野指针指向了NSExtensionContext对象。

• 验证内存管理与生命周期异常
  键盘扩展的生命周期比主App更敏感，容易被系统回收：

  • 检查扩展中是否有弱引用对象被提前释放，导致系统回调时出现野指针，误触发错误的selector；
  • 测试在不同场景下的崩溃触发条件，比如切换键盘、回到主App、后台停留后再激活，看是否有固定的复现路径。

• 考虑系统bug的可能性
  如果以上排查都没有结果，大概率是系统层面的bug。可以整理详细的崩溃报告、复现步骤，通过苹果的Feedback Assistant提交雷达。我之前碰到过iOS14某个版本中，键盘扩展在快速切换时触发NSExtensionContext私有方法崩溃的问题，后来系统更新就修复了。

内容的提问来源于stack exchange，提问作者Mike