常见SDK依赖关系分析

依赖关系这事，说白了就是「你初始化之前，得先保证你的上游已经准备好了」。你想想看，一个地图SDK连定位服务都没跑起来，它拿什么给你显示位置？推送SDK不知道当前有没有网，它怎么决定用长连接还是短轮询？支付SDK连加密环境都没建好，谁敢把银行卡号交出去？

我这些年看过不少崩溃日志，十有八九的初始化顺序问题，都出在依赖链没理清。不要觉得这是小事，线上环境稍微一乱，就是闪退事故。这一章我们就来把三个最常见的SDK依赖关系拆开看看。

1. 地图SDK → 定位模块

地图SDK表面上是个渲染引擎，实际上它最核心的一个前提是——知道你在哪。没有定位数据，地图连初始视角都定不了。

我在项目中遇到过一个问题：App启动时同时调了地图SDK和定位SDK的初始化，结果地图在定位还没返回有效坐标时就调了setCenterCoordinate，传入了一个空值，直接抛了NSInvalidArgumentException。嗯，iOS上就是野指针，Android上就是空指针，殊途同归。

这里的关键依赖链是：

• 地图SDK 强依赖 定位SDK 的初始化完成
• 定位SDK 又依赖 系统定位服务（GPS/WiFi扫描）就绪
• 定位SDK本身还需要 权限回调 完成后才能返回有效数据

所以初始化顺序必须是：系统定位服务可用 → 定位SDK初始化 → 地图SDK初始化。跳一步都不行。

2. 推送SDK → 网络状态模块

推送SDK看起来是个「收消息」的东西，但它背后做的事情很重：建立长连接、心跳保活、根据网络切换通道。这些操作全都依赖一个前提——知道当前网络是什么状态。

我记得有一次排查一个问题：推送在WiFi环境下正常，切到4G就收不到消息。查了两天才发现，推送SDK初始化时网络监听还没注册，它默认用了WiFi通道的参数去连4G的网络，结果连接被运营商拦截了。说白了，网络状态没拿到，通道选错了。

它的依赖链是：

• 推送SDK 依赖 网络状态模块 提供实时网络类型
• 网络状态模块 依赖 系统网络接口（Android的ConnectivityManager / iOS的Reachability）
• 网络状态模块还需要 权限（ACCESS_NETWORK_STATE）就绪

我个人的习惯是：在Application.onCreate()里先初始化网络监听，再初始化推送SDK。这样能保证推送启动的第一时间就能拿到正确的网络环境。

3. 支付SDK → 安全模块

支付SDK的依赖是最容易被忽视的。很多人以为支付就是一个调起页面输密码的事儿，其实它底层依赖的东西很重——加密、签名、证书校验、密钥管理。这些东西统称为安全模块。

我曾经在一个金融类App里踩过这个坑：支付SDK初始化时，安全模块的密钥池还没建立，结果在生成签名时抛了一个NullPointerException。用户还没看到支付页面呢，App就闪退了。你想想看，这种问题在线上有多致命。

它的依赖链是：

• 支付SDK 依赖 安全模块 提供加密/签名能力
• 安全模块 依赖 系统安全服务（KeyStore / TEE / 安全芯片）
• 安全模块自身还需要 种子数据 初始化密钥池

支付SDK的初始化必须放在安全模块初始化之后。而且安全模块的初始化往往是异步的，不能简单地调个init()就以为完事了，得等它的回调确认「密钥池已就绪」才行。

4. 依赖链全景图

三条依赖链放在一起看，层次感就出来了。我画了个图，把这种「底层 → 中间层 → 业务层」的结构展示清楚：

5. 依赖关系一览表

我把三条链的依赖关系整理成了表格，方便你对照排查：

6. 从依赖链推导初始化顺序

有了上面的依赖关系，初始化顺序就很好推了。核心原则就一句话：从底层到上层，层层就绪。

具体来说：

1. 系统服务层最先启动：传感器服务、网络接口、安全存储这些系统级能力必须在App启动后的第一时间可用。它们通常由系统自动管理，但你要确认权限已经授予。
2. 中间件层第二个就绪：定位SDK、网络状态模块、安全模块。这三个模块各自依赖系统服务，它们的初始化是并行的，但每一路都必须等自己的底层就绪。
3. 业务SDK最后初始化：地图、推送、支付。这三个SDK必须等各自的中间件依赖完成后才能启动。

你可能会问：「这三条链是独立的，还是相互有交叉？」答案是独立的。地图不依赖网络状态，推送不依赖安全模块，支付不依赖定位。所以它们可以在各自的依赖就绪后并行初始化。但要注意——如果两个SDK用到了同一个底层资源（比如都用了网络接口），那就需要加锁或者排队，防止资源竞争。

7. 避坑指南：三条链的常见误区

我把这些年见过的典型问题列出来，你对照看看自己的项目有没有类似情况：

• 地图SDK：不要在onCreate里直接调地图初始化，然后紧接着调定位。要等定位SDK的onLocationReady回调。
• 推送SDK：不要在没网的时候初始化推送。虽然推送SDK内部可能有重试机制，但我见过很多厂商通道在没网初始化后就不重试了。
• 支付SDK：安全模块的初始化往往涉及异步加载密钥，不要用sleep等，要用回调或CompletableFuture串起来。