1. 问题概述：什么是多SDK初始化顺序混乱？

先问一个最直接的问题：SDK 初始化顺序，真的那么重要吗？

我以前也觉得无所谓，反正每个 SDK 各管各的。直到有一次线上崩溃率突然飙升到 3%，用户点击支付按钮直接闪退。查了三天，最后发现是推送 SDK 在初始化时调用了网络库，而网络库还没准备好。嗯，从那天起，我再也不敢小瞧顺序了。

1.1 本质是什么？

说白了，多 SDK 初始化顺序混乱 就是指在 App 启动阶段，多个第三方或内部 SDK 之间的依赖关系没有被正确满足。你想想看，A 依赖 B 提供的服务，结果你先把 A 启动了，那 A 去调用 B 的接口时，B 还是个空壳子，自然就崩溃了。

我习惯把这种情况归类为：

• 直接依赖型：SDK A 的 init 方法里直接调用了 SDK B 的某个静态方法。
• 间接依赖型：SDK A 在子线程异步初始化，正好抢在 SDK B 之前占用了某个共享资源（比如数据库连接池）。
• 时序竞态型：两个 SDK 都用了同一个全局回调，谁先注册谁就覆盖了另一个。

1.2 为什么会导致崩溃？

我把底层原因拆成三个维度，用一张表说明白：

1.3 真实项目中的典型案例

举一个我亲手修过的例子。那是个电商 App，集成了：

• 推送 SDK（个推 / 极光）
• 统计分析 SDK（友盟 / 神策）
• 支付 SDK（微信 / 支付宝）
• 地图 SDK（百度 / 高德）
• 用户行为埋点 SDK（自研）

启动流程本来是这样写的：

// AppDelegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // 1. 先初始化推送
    [PushSDK startWithAppKey:@"xxxx"];
    // 2. 再初始化统计
    [AnalyticsSDK startWithAppKey:@"yyyy"];
    // 3. 然后初始化支付（这里面会异步加载微信SDK）
    [PaymentSDK registerAppId:@"zzzz"];
    // 4. 地图初始化
    [MapSDK setApiKey:@"aaaa"];
    // 5. 最后自研埋点
    [TrackSDK setup];
    return YES;
}

这段代码跑在 iOS 12 上没问题，但到了 iOS 15+ 就随机崩溃。为什么呢？我加了一些日志后发现：

1. PushSDK startWithAppKey: 内部会异步注册远程推送，并且会在主线程回调一个 + (void)pushDidRegisterDeviceToken:。
2. AnalyticsSDK startWithAppKey: 内部立即读取本地缓存文件，但如果 PushSDK 的回调正好在此时触发，推送回调会尝试写入同一个文件（都是写 sessionId），两个线程同时写同一个 plist 文件，导致文件格式损坏。
3. 文件损坏后，AnalyticsSDK 在下次启动时读取到乱码，直接断言崩溃。

崩溃栈完全看不出来和顺序有关，只看得出“属性列表解析错误”。但本质就是两个 SDK 没有约定文件写入的临界区，而初始化顺序让它们撞车了。

1.4 从结构上看依赖关系

下面这张图把常见 SDK 之间的依赖关系画了出来。箭头指向“被依赖方”，如果箭头顺序反了就会崩：

1.5 我总结的「初始化顺序检查清单」

后来团队定了个规矩，每个 SDK 接入前必须过这张表：

1. 读文档：SDK 官方有没有写“请在其他 SDK 之前/之后初始化”？
2. 看源码：如果条件允许，grep 一下这个 SDK 的 +load、+initialize 方法，看它是不是做了 swizzling 或插桩。
3. 打埋点：在 application:didFinishLaunching 里每个 SDK init 前后加时间戳和线程 ID，跑几次自动化测试看是否有时序竞态。
4. 加监控：在线上收集 NSException 和 SIGABRT 堆栈，过滤出“初始化期崩溃”。我遇到过有的 SDK 只在 5% 的设备上崩溃，但用户量大时就是灾难。