崩溃场景复现：搭建Demo项目模拟初始化顺序崩溃

说实话，我在做SDK集成的时候，最怕的就是这种初始化顺序的问题。你想想看，三个SDK各自跑得好好的，放一起就崩，而且崩得莫名其妙。我曾经在一个电商项目中，就因为支付SDK初始化比地图SDK早了那么几百毫秒，线上直接炸了——用户一打开支付页面就闪退，当时排查到凌晨三点才定位到是初始化顺序的问题。

所以这一章，咱们亲手搭一个Demo项目，把崩溃场景原样复现出来。只有亲眼看到它崩，你才能真正记住这个坑。

1. 项目结构与SDK模拟

先创建一个最简单的Android项目，Application里做初始化。为了聚焦问题本身，我们不引入真实SDK，而是用三个模拟类来复现依赖关系。

项目结构就三部分：

• MapSDK —— 模拟地图SDK，依赖网络环境和定位权限
• PushSDK —— 模拟推送SDK，内部依赖MapSDK的定位服务
• PaySDK —— 模拟支付SDK，内部依赖PushSDK的长连接通道

每个SDK的初始化方法都会检查前置条件，如果不满足直接抛出RuntimeException。这样就能精准模拟真实场景下的连锁崩溃。

2. 模拟SDK的初始化逻辑

先看MapSDK。它负责检查网络和定位权限，这是最基础的服务。

public class MapSDK {
    private static boolean locationReady = false;

    public static void init(Context context) {
        // 模拟网络检查
        if (!checkNetwork(context)) {
            throw new RuntimeException("MapSDK 初始化失败：网络环境未就绪");
        }
        // 模拟定位初始化
        initLocationModule();
        locationReady = true;
        android.util.Log.d("MapSDK", "✅ 初始化成功");
    }

    public static boolean isLocationReady() {
        return locationReady;
    }

    private static boolean checkNetwork(Context context) {
        // 模拟检查，真实场景会查ConnectivityManager
        return true;
    }

    private static void initLocationModule() {
        // 模拟定位模块启动
        android.util.Log.d("MapSDK", "定位模块已启动");
    }
}

接着是PushSDK。它初始化之前必须确认MapSDK的定位服务已经就绪。

public class PushSDK {
    private static boolean channelReady = false;

    public static void init(Context context) {
        // 检查前置依赖：MapSDK的定位服务
        if (!MapSDK.isLocationReady()) {
            throw new RuntimeException("PushSDK 初始化失败：定位服务未就绪，请先初始化 MapSDK");
        }
        // 建立长连接通道
        initPushChannel();
        channelReady = true;
        android.util.Log.d("PushSDK", "✅ 初始化成功");
    }

    public static boolean isChannelReady() {
        return channelReady;
    }

    private static void initPushChannel() {
        // 模拟长连接建立
        android.util.Log.d("PushSDK", "推送通道已建立");
    }
}

最后是PaySDK。它依赖PushSDK的长连接通道来做支付回调。

public class PaySDK {
    public static void init(Context context) {
        // 检查前置依赖：PushSDK的长连接
        if (!PushSDK.isChannelReady()) {
            throw new RuntimeException("PaySDK 初始化失败：推送通道未就绪，请先初始化 PushSDK");
        }
        // 初始化支付模块
        initPayModule();
        android.util.Log.d("PaySDK", "✅ 初始化成功");
    }

    private static void initPayModule() {
        // 模拟支付模块启动
        android.util.Log.d("PaySDK", "支付模块已启动");
    }
}

3. 两种初始化顺序的对比实验

现在我们在Application的onCreate里分别测试两种顺序。

正确顺序：地图 → 推送 → 支付

public class DemoApp extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        MapSDK.init(this);   // 第1步：地图
        PushSDK.init(this);  // 第2步：推送
        PaySDK.init(this);   // 第3步：支付
        android.util.Log.d("DemoApp", "🎉 启动成功");
    }
}

错误顺序：支付 → 推送 → 地图

public class DemoApp extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        PaySDK.init(this);   // 第1步：支付 → 直接崩溃！
        PushSDK.init(this);  // 永远不会执行到这里
        MapSDK.init(this);   // 永远不会执行到这里
    }
}

4. 崩溃原因深度分析

为什么支付SDK放在第一位就直接崩了？其实逻辑很简单。你看看支付SDK的init方法第一行做了什么——它调用了PushSDK.isChannelReady()。而PushSDK的长连接通道只有在它自己的init方法执行后才会建立。顺序颠倒后，通道还没创建，检查自然失败。

这就是典型的链式依赖未满足导致的崩溃。三个SDK形成了完整的依赖链：

1. 地图SDK 初始化 → 开启定位服务
2. 推送SDK 初始化 → 建立长连接通道（依赖定位服务）
3. 支付SDK 初始化 → 注册支付回调（依赖长连接通道）

一旦这个链条断裂，比如跳过了第1步或第2步直接执行第3步，崩溃就是必然的。

本章小结与行动清单

好了，现在你已经亲手复现了SDK初始化顺序导致的崩溃。下一章我们聊一聊——如何在项目里通过工具手段自动拦截这种问题，而不是等到线上崩了再排查。