第一章：问题背景与重复注册崩溃的典型现象

先从一次线上事故说起

2019年，我还在某出行平台做移动端架构师。那天下午三点，线上突然涌入大量启动崩溃日志。用户刚打开App就闪退，连首页都看不到。排查下来，罪魁祸首居然是——某个第三方登录SDK在Application.onCreate()里被重复调用了两次注册API。

那次事故影响了几十万用户，修复后我花了一周时间复盘。说白了，重复注册这个坑，在SDK开发里太常见了。很多团队只关注功能能不能跑通，很少有人真正去处理“如果用户代码把我注册了两次怎么办”。

什么是重复注册崩溃？

当一个SDK的初始化或注册方法被多次调用时，通常会导致：

• Native层重复加载so库 —— 引发SIGSEGV或SIGABRT
• Java层重复注册BroadcastReceiver —— 抛出IllegalStateException
• JNI全局引用溢出 —— 直接卡死启动流程

嗯，这里要区分一下。有些崩溃是立刻发生的，比如重复调用System.loadLibrary()时，底层会输出一个Tombstone文件告诉你“so already loaded”。但更多情况是延迟崩溃——第二次注册把第一次注册的内部状态冲掉了，后续某个操作访问了野指针。

典型现象：启动即闪退

我个人习惯把这类崩溃归为“阴间Bug”。它在开发机上很难复现，因为你不会没事干在Application里把同一个初始化方法写两遍。但发生后就极其致命：

我遇到过最奇葩的一个案例：某IM SDK在init()里开了线程池，第二次注册时又创建了新线程池，导致两个线程池同时操控同一个长连接socket。结果就是连接状态错乱，用户发消息收不到。这不是崩溃，但比崩溃更可怕——数据丢失。

为什么重复注册通常不被重视

你想想看，写SDK的人觉得“用户不可能调我两次”，而用户觉得“我多调一次应该没事吧”。双方的信任链条就这样断裂了。我曾经在技术会议上做过一个小调查：参与投票的200多位开发者中，有83%的人表示从未在SDK内部做重复注册保护。这就埋下了隐患。

下面这张图展示了重复注册从触发到崩溃的完整路径：

重复注册的常见触发场景

我在项目中总结出几种最容易踩坑的写法：

场景	代码示例	风险等级
Application.onCreate() 中二次调用	SDK.init(this); SDK.init(this);	极高
多继承Application导致注册重复	super.onCreate() 中隐式调用	高
混淆后方法被内联，触发两次	ProGuard 优化引起	中
插件化/模块化热修复后重复初始化	宿主和插件各自调了一次	极高

从崩溃日志定位重复注册

如果你看到类似下面的堆栈，大概率是重复注册：

#00 pc 0001e4b0  /system/lib/libc.so (abort+4)
#01 pc 00021134  /system/lib/libc.so (sigprocmask+20)
#02 pc 0004a8ec  /vendor/lib/libc.so 
#03 pc 0004b4b8  /data/app/xxx/lib/arm64/libxxx_sdk.so (JNI_OnLoad+48)
#04 pc 0007c2e0  /system/lib/libart.so (art::JavaVMExt::LoadNativeLibrary+416)
----- 关键信息：同一个JNI_OnLoad被调用了两次 -----

为什么JNI_OnLoad会被调用两次？我的经验是：第一次加载时注册了native方法，第二次加载时系统发现so文件已被加载，但JNI_OnLoad仍会被执行一次（在部分Android版本中）。这时候native函数表中的指针可能被覆盖，或者出现重复注册全局引用。

重复注册的“温柔陷阱”

不是所有重复注册都会直接崩溃。有些SDK设计时做了简单判断——比如用boolean标记是否已初始化。但这就够了吗？远远不够。为什么？

我举个真实案例：某个地图SDK的onCreate()方法里有一个AsyncTask去加载离线地图。第二次注册时，boolean判断跳过了初始化流程，但一个新的AsyncTask还是被创建了出来。结果两个AsyncTask同时写同一个文件，文件直接损坏。用户打开地图后发现“街道名全变成了乱码”。

你看，这就是典型的“注册成功但逻辑重复”问题。所以我在后面章节里会重点讲：必须用双重检查锁 + 整体状态机来避免这种问题。

小测试：你能识别出下面的Bug吗？

来看看这段代码，试着找找问题：

// 某SDK内部实现
public class MySDK {
    private static boolean initialized = false;
    
    public static synchronized void init(Context context) {
        if (initialized) return;
        initialized = true;
        
        System.loadLibrary("native_core");
        nativeSetup();
        // 其他初始化...
    }
    
    private static native void nativeSetup();
}

这里有一个隐蔽的陷阱。因为System.loadLibrary("native_core")在Java层只会加载一次，但nativeSetup()这个函数很可能在native层会再次执行注册操作。如果nativeSetup()里调用了JNI_OnLoad或者RegisterNatives，那么第二次调用init()（实际上被拦在Java层之外）并不能阻止native层被重复注册。这就是我前面说的：boolean标记只能挡住表面，挡不住深层。

本章总结

重复注册崩溃的核心原因很简单：SDK被调用了两次或多次初始化入口。但后果复杂多样——从闪退到数据错乱，甚至用户无感知的静默失败。作为SDK开发者，你不能指望用户永远不犯错误。后面29个章节，我会逐一拆解每种场景的防护方案和实战代码。