第三章：初始化流程概览
好，咱们今天聊聊SDK一启动，到底发生了什么。你拿到一个SDK，调个 init() 方法，背后其实是一整套流程在跑。很多新手觉得初始化就是“调个接口”，结果线上出了各种诡异问题——资源没加载完就调用业务接口、回调没注册上、多线程环境里状态乱跳……说白了，都是没把初始化流程摸透。
我个人习惯把初始化拆解成三个维度看：步骤、生命周期、启动顺序。你只要把这三点吃透，大部分初始化坑都能提前避开。
一、初始化三大阶段
SDK启动，大致分三步走：准备、加载、就绪。我给你列个清单，你看看是不是这个逻辑。
| 阶段 | 核心动作 | 关键产出 |
|---|---|---|
| 准备 | 配置读取、环境检查、权限校验 | 校验通过标识、配置对象 |
| 加载 | 模块注册、依赖解析、资源加载 | 模块列表、资源句柄 |
| 就绪 | 状态置位、回调触发、对外通知 | 初始化完成事件 |
你看，每阶段都有明确产出。我曾遇到过团队把“检查网络权限”扔到加载阶段才做，结果资源下载前才报错。嗯，这就是阶段错位。
二、生命周期：状态机视角
初始化绝不能是“一把梭”。它是个状态机，每个状态都有明确的输入和输出。我一般这么定义：
- UNINITIALIZED（未初始化）：刚创建，啥都没做。
- INITIALIZING（初始化中）：正在跑流程，此时对外暴露接口必须等待。
- INITIALIZED（已初始化）：流程跑完，可以正常使用。
- ERROR（错误）：流程中断，需要外部介入或重试。
为什么会这样设计？因为多线程环境下，你要防止重复初始化。你想想看，两个线程同时调 init()，如果没有状态互斥，资源就加载两次了。我记得有一次线上排查问题，发现用户反馈“登录后数据丢失”，查了半天，就是初始化阶段回调被重复触发了两次——状态机没锁住。
核心原则：状态机必须有原子性切换。推荐用 AtomicReference 或 CAS 做状态更新，别用 synchronized 包整个方法，那样性能扛不住。
三、启动顺序：依赖决定顺序
初始化顺序不是拍脑门定的。它由依赖关系决定。先加载无依赖的模块，再加载有依赖的模块。 我把常见依赖类型列出来：
- 强依赖：模块B必须等模块A加载完才能启动。例如网络模块必须先于数据上报模块。
- 弱依赖：模块B可以等模块A，但不等也能工作，只是功能受限。例如日志模块和统计模块。
- 无依赖：独立模块，各跑各的。例如UI组件库和存储工具库。
我建议你把模块依赖画成有向无环图（DAG），然后按拓扑序加载。这是我最喜欢用的方式，清晰、可回溯、还方便做并行加载优化。
四、一个真实的初始化错误案例
我曾经在交付一个推送SDK时，出了这样一个问题：
- SDK初始化时，先加载了配置模块。
- 然后立即调用了上报模块做埋点。
- 结果配置模块还没完全解析完，上报模块就报“配置缺失”错误。
原因很简单：配置模块的状态机只设了“加载中”就开始对外暴露接口。说白了——生命周期还没走完。修复方式也不难，让上报模块在 INITIALIZED 事件触发后再注册。你看，一个状态机的问题。
警告：不要在初始化完成前触发任何外部回调。我曾遇到一个SDK，在模块加载阶段就调了 onReady，下游开发者直接开始展示UI，结果数据还没到位，页面白屏了。那个bug修了一周……
五、SVG：初始化流程全貌
画了一张图，把上面的逻辑串起来。你扫一眼就能记住。
六、关于异步初始化的一点经验
现在很多SDK走异步初始化。这种设计有个好处——不阻塞主线程。但坑也不少。我分享三个原则：
- 给调用方一个明确的状态查询接口，比如
isReady()，别让开发者凭感觉“等几秒”。 - 异步回调里不要做耗时操作。我见过有人在
onInitSuccess里直接下载大文件，UI线程直接卡住。 - 超时处理不能少。网络慢或配置错，初始化可能永远完成不了。设个30秒超时，超时后进入ERROR状态，开放重试。
小技巧：你可以在初始化流程中加一个“健康检查”步骤。说白了就是跑一个小接口，确认核心资源都到位了再对外通知。我曾经用这个方式，把一个间歇性崩溃的SDK彻底修好——因为资源加载不全这个情况，光靠回调根本发现不了。
七、总结一下
初始化流程这件事，说白了就三句话：
- 把步骤切清楚——准备、加载、就绪，每一步做什么，提前定好。
- 用状态机管生命周期——别让未初始化和初始化中的状态混在一起。
- 按依赖排顺序——强依赖先走，弱依赖可以等，无依赖并行。
做到这三点，你的SDK初始化基本就稳了。下次你写SDK初始化时，不妨把这页笔记拿出来翻翻——挺好用的。