为何 SDK 初始化顺序如此重要
说实话，我第一次被 SDK 初始化顺序坑的时候，项目已经上线了。用户反馈说支付功能有时能用有时不能用，定位服务随机失败。我排查了两天才发现 — 原来是一个地图 SDK 在支付 SDK 之前注册，而地图 SDK 内部居然偷偷改了某个单例的初始化状态。那之后我养成了一个习惯：先画清楚依赖图，再写一行初始化代码。
这一章我们先聊聊一个基础问题：为什么顺序这么关键？
核心原因：模块间存在隐式依赖
你想想看，多数 SDK 都不是完全独立的。一个广告 SDK 可能依赖网络库，而网络库又依赖日志模块。如果日志模块还没初始化，网络库就开始发请求 — 日志丢了还是小事，搞不好还引起野指针崩溃。
我总结了最常见的几类依赖关系：
| 依赖类型 | 典型场景 | 后果 |
|---|---|---|
| 配置依赖 | SDK-A 需要在 SDK-B 之后读取它的配置 | 配置为空白，功能异常 |
| 生命周期依赖 | SDK-C 必须在 UI 线程初始化前注册回调 | 回调丢失，无法监听关键事件 |
| 资源依赖 | SDK-D 需要先加载共享库 .so 文件 | native 层崩溃，App 闪退 |
| 数据依赖 | 推送 SDK 需要先拿到用户标识 | 推送消息错发或漏发 |
你真的知道 SDK 的初始化方法做了什么吗？
很多同学以为 SDK.init() 就是“启个后台线程，搞搞内部状态”。其实没那么简单。我拆过几个主流 SDK 的源码，发现初始化方法往往包含：
- 静态变量写入 — 如果被重复赋值，后注册的 SDK 可能覆盖前面的。
- 动态代理注册 — 多个 SDK 争同一个代理接口，后注册的会替换前面的。
- 线程池启动 — 某些 SDK 初始化后立刻往线程池丢任务，还没完成依赖初始化就执行了。
- 文件锁操作 — 多个 SDK 同时写同一个文件，容易产生脏数据。
举个真实例子：
// 错误的顺序
ShareSDK.init(context); // 会修改全局织入机制
BuglySDK.init(context); // 依赖 ShareSDK 的日志钩子
// Bugly 收到的日志全是后半段，前半段因为织入机制还没生效而丢了。我当时解这个 Bug 花了整整一个下午。后来我建议团队做一个 初始化序列表，每个 SDK 都标注自己的前置依赖，然后按拓扑排序执行。这才彻底解决。
重复注册：比你想的更可怕
“重复注册”不只是同一个 SDK 注册两次的问题。很多时候是：
- 两个功能相似的 SDK 都注册了同一个全局监听器，后注册的会把前一个的句柄顶掉。
- 在 Application 的 onCreate 和 Activity 的 onCreate 里各初始化了一次，导致回调被触发两次。
- 热修复框架重复注入相同类，导致方法被多次替换，调用时死循环。
我的建议是：在 SDK 初始化入口加一个 isInitialized 标记，一旦初始化过就直接 return。同时打印一条 LOG 方便排查。
一张图看懂初始化顺序的核心问题
下面这张图梳理了从 App 启动到 SDK 初始化结束的典型路径，以及每个节点可能出问题的地方：
一个实用的初始化检查清单
我在项目里会强制团队成员过这道 checklist，效果不错：
- 是否已阅读每个 SDK 的初始化说明？ 绝大多数坑都写在文档里，只是没人看。
- 是否存在循环依赖？ 比如 SDK-A 说必须等 B，B 又说必须等 A — 这种情况需要重构或引入延迟初始化。
- 是否使用了统一的初始化管理器？ 我建议封装一个 SdkInitializer 类，按优先级排序注册，而不是散落在各个地方。
- 是否加了超时保护？ 某些 SDK 初始化可能阻塞主线程，超过 5 秒就应该主动降级。
- 日志是否完整？ 每个 SDK 初始化成功或失败都应当打印一条 LOG，带上耗时。
总结：顺序 + 防重复 = 稳
简单来说，SDK 初始化顺序就是 App 基础架构的地基。地基没打好，上面盖的楼越漂亮越容易塌。我个人习惯在项目的 init 模块里单独建一个 SdkOrderConfig 类，把每个 SDK 的前置依赖、初始化优先级、是否允许重复注册都写清楚。后期排查问题时，直接看这个配置文件就能定位到原因。
记住一句话：先把依赖梳理明白，再写代码，永远不要靠运气跑初始化。