动态框架中使用Crashlytics时日志记录异常的原因咨询

嘿，这个场景我在多模块iOS项目里踩过坑，咱们来拆解下背后的逻辑：

为什么会出现这个警告？ #

这个问题本质是框架加载时序 + Crashlytics内部机制共同导致的：

• Crashlytics的CLSLog（包括你封装的日志器）依赖内部初始化完成的日志记录实例。在Crashlytics调用[Crashlytics startWithAPIKey:]（或新版的[FirebaseCrashlytics configure]）之前，这个实例是未就绪的。如果此时调用日志方法，就会触发那个警告，而且日志/崩溃信息根本无法被捕获上传。
• 你的日志器和Crashlytics初始化分属两个不同框架时，iOS的框架加载顺序可能让日志器所在框架先被加载。比如应用目标先导入了日志器框架，导致日志器的代码在Crashlytics初始化代码之前就被执行——哪怕你是在didFinishLaunching里调用日志，也可能因为框架初始化的先后，让日志器的类提前触发了某些内部逻辑（比如静态初始化块），间接调用了CLSLog。
• 跨框架的情况下，日志器所在框架无法感知Crashlytics的初始化状态，很容易出现“调用早于初始化”的时序问题。

为什么移到同一框架就解决了？ #

把日志器和Crashlytics初始化放在同一框架里，相当于把两者的生命周期绑定了：

• 同一框架内的代码加载顺序是可控的，你可以明确保证Crashlytics初始化完成后，才让日志器的方法被外部调用。比如你可以在框架内部先完成Crashlytics初始化，再暴露日志器的单例或接口。
• 同一框架内的符号访问更直接，Crashlytics的内部实例可以被日志器正确获取，不会出现跨框架的初始化延迟或未就绪问题。
• 避免了不同框架加载时序不可控的问题——毕竟iOS系统对多个独立框架的加载顺序，有时候会依赖导入顺序、框架的依赖关系等，这些都是你很难完全掌控的。

额外提个小建议：如果不想把日志器和初始化代码放一起，也可以在日志器里加个“初始化完成标记”，只有在Crashlytics初始化完成后才允许调用日志方法，或者把日志缓存起来，等初始化完成后再批量提交。不过这个方案的复杂度比移到同一框架高很多，还是后者更简单可靠。

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