iOS SDK集成Crashlytics与宿主App内置Crashlytics是否会冲突

直接说结论：只要你把Crashlytics打包进对外分发的SDK产物，不管怎么调整配置，只要宿主自己也集成了Crashlytics就一定会出问题，没有完全兼容的方案，具体表现和你的集成方式直接相关：

• 如果你是把Crashlytics源码、静态库直接编译进自己的SDK静态包输出，宿主集成时只要自己也带了Crashlytics，编译阶段直接报duplicate symbol符号重复错误，项目根本跑不起来。
• 如果你是用动态库方式内嵌Crashlytics，或者通过CocoaPods、SPM把Crashlytics声明为SDK的依赖而非直接打包进产物，编译阶段不会报错，但运行时会出两个严重问题：
  1. 崩溃捕获权抢占：Crashlytics在App进程内是全局单例，靠注册Mach异常端口、BSD信号监听抓崩溃，谁先跑完初始化流程，谁就独占崩溃捕获的权限，后初始化的实例根本拿不到崩溃信号，既抓不到崩溃，也不会往自己绑定的Firebase项目上报数据。
  2. 上报数据完全错乱：如果宿主的Crashlytics先初始化，你SDK里出的崩溃会被上报到宿主的Firebase后台，但宿主手里没有你SDK的dSYM符号表，所有和你SDK相关的堆栈都会显示成无意义的内存地址，两边都没法定位问题；要是你SDK里的Crashlytics先初始化，宿主自己业务代码出的崩溃会全量传到你绑定的Firebase项目里，不仅你这边会收到一堆和SDK无关的脏数据，宿主直接就拿不到自己的崩溃数据，严重影响人家的线上运维。

这里要特别提一句：Crashlytics从设计上就是给独立App用的监控工具，根本没做多实例隔离、上报链路隔离的能力，Firebase官方文档明确不支持第三方SDK内嵌Crashlytics做自身监控，这么用出任何问题官方都不会管。

如果你确实需要监控SDK自身的崩溃，建议走两个方向：

• 不要硬嵌Crashlytics，对外暴露SDK的异常回调接口，引导集成方在自己的Crashlytics初始化逻辑里，把和你SDK相关的崩溃堆栈、上下文信息按约定好的格式打自定义日志、自定义属性，后续需要排查问题时让集成方导出对应数据给你就行。
• 如果你想不依赖宿主、独立收集SDK侧的崩溃，就别用Crashlytics，换专门面向SDK场景做的、支持多实例隔离的崩溃监控SDK，这类SDK会做捕获逻辑的兼容处理，上报链路完全独立，不会和宿主自己的崩溃监控抢权限。

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