4、异步初始化与同步初始化归纳总结

4.1 两种初始化方式，到底差在哪儿？

SDK 初始化这件事，说白了就两种路子：同步和异步。我当初刚接手这个改造项目时，觉得同步简单粗暴，异步花里胡哨，能跑就行。直到遇到一个线上 crash——用户网络抖动，同步初始化卡死了主线程，整个 App 白屏三秒。嗯，从那以后我再也不敢轻视这个选择。

咱们先把两种方式的流程理清楚：

• 同步初始化：调用初始化方法后，线程一直等，直到 SDK 完全就绪才返回。期间不能做别的事。
• 异步初始化：调用后马上返回，SDK 在后台线程干活。通过回调、Promise 或 delegate 通知调用方“我准备好了”。

你看，一个像排队买票必须站着等，一个像取号后去喝杯咖啡，叫到号再回来。本质上就是阻塞 vs 非阻塞的经典选择题。

4.2 代码风格对比

直接上代码，你感受一下差异。先看同步：

// 同步初始化（iOS 示例）
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    MySDKConfig *config = [[MySDKConfig alloc] initWithAppKey:@"xxx"];
    [[MySDK shared] syncInitWithConfig:config];  // 这里阻塞，直到SDK初始化完成
    // 继续做其他事
    return YES;
}

再看异步：

// 异步初始化
[[MySDK shared] asyncInitWithConfig:config completion:^{
    // 回调线程，此时SDK已就绪
    dispatch_async(dispatch_get_main_queue(), ^{
        // 回到主线程更新UI或触发后续逻辑
    });
}];
// 返回后主线程立即执行下一行，不会卡住

代码量差距不大，但背后的调度逻辑天差地别。我建议你关注回调执行的线程——很多崩坏案例都是因为回调跑在子线程，直接更新了 UI 导致的。

4.3 一张图看懂两种初始化流程

下面这张流程图是我自己捋的，把同步和异步的关键节点标了出来。每次团队有新人问初始化方案，我都直接甩这张图。

4.4 何时选同步？何时选异步？

说实话，并不是所有场景都适合异步。我见过有人把网络请求依赖的初始化做成同步，结果线上翻车；也见过一个纯本地内存计算的初始化硬要搞异步，反而增加了代码复杂度。

下面这张表是我在实际项目中踩坑后的总结：

场景	推荐方式	我的实战经验
本地缓存读取、内存数据加载（预计 < 10ms）	同步	没必要异步，加个回调反而让逻辑断裂。我直接在主线程同步搞，简单。
网络请求、文件下载（延迟不确定）	异步	必须异步。我曾经因为同步阻塞导致 App 启动超时被系统 kill。
UI 强依赖初始化结果（例如首页渲染）	异步 + 占位图	先给用户一个 loading 框，不要白屏。回调后再渲染。
单线程环境（如部分嵌入式 RTOS）	同步	没有线程池，异步反而要自己实现状态机，不如同步稳妥。
加密握手阶段（网络 + 证书校验）	异步	本课程的主题。加密握手每一步都可能超时，必须异步 + 超时重试。

4.5 避坑指南——我曾经踩过的坑

这里列出三个我亲手踩过的坑，希望你看了能绕开：

• 回调线程未指定：异步初始化回调默认跑在哪个线程？很多 SDK 文档不写。我曾经默认在主线程处理，结果回调里做了大量计算，又把主线程卡死了。现在我的习惯是：明确回调线程，并在文档里用粗体标出来。
• 重复初始化：异步初始化多次调用，结果创建了多个实例。我给团队定的规则是：initOnce 加锁，回调只触发一次。你想想看，如果用户快速切换页面，初始化被调两次，轻则浪费资源，重则崩溃。
• 超时未处理：异步初始化没有超时机制，网络环境差时一直等。我曾经一个项目因此被差评刷爆——用户等了十秒还是白屏。后来加了超时兜底，5 秒没回调就弹“网络异常”页面。

4.6 改造策略：从同步到异步的典型步骤

如果你手头有个同步初始化的 SDK，想改成异步，可以按这个步骤走。我在第一个版本改造时就是这么干的：

1. 封装原同步函数：把 syncInit 包在一个后台线程的 Block 里，不要改原逻辑。
2. 添加回调参数：定义 completionBlock，参数带上 error 和 result。
3. 状态标记：用 atomic 或锁标记 isInitializing，防止并发调用。
4. 线程安全处理：回调内如果用到 UI，记得 dispatch_async(dispatch_get_main_queue())。
5. 加超时：用 dispatch_after 或 NSTimer，超时后回调一个 timeOut 错误。
6. 单元测试：模拟慢网络和异常响应，确保回调只触发一次。

// 改造模板（伪代码，结合了回调、超时、线程安全）
- (void)asyncInitWithConfig:(Config *)config completion:(void(^)(NSError *error))completion {
    if (self.isInitializing) { completion([NSError error...]); return; }
    self.isInitializing = YES;
    
    dispatch_async(self.initQueue, ^{
        // 原来的同步逻辑
        NSError *err = [self syncInitWithConfig:config];
        dispatch_async(dispatch_get_main_queue(), ^{
            self.isInitializing = NO;
            if (completion) completion(err);
        });
    });
    
    // 超时处理
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), self.initQueue, ^{
        if (self.isInitializing) {
            self.isInitializing = NO;
            dispatch_async(dispatch_get_main_queue(), ^{
                if (completion) completion([NSError errorWithDomain:@"TimeOut" ...]);
            });
        }
    });
}

好了，本章把同步和异步的对比、选择依据、改造步骤都讲清楚了。你可以在自己的项目里试着画一张类似的流程图，把每一个分支的线程和等待时间标出来，一目了然。