Android开发——Crash捕获SDK是如何捕获Application中onCreate的崩溃信息的

1. 前言

众所周知，很多第三方SDK是在Application中的onCreate()中去初始化的，形如：

@Override
public void onCreate() {
    super.onCreate();
    //...
    ThirdPartySDK.init(this);
}

那么为什么一些crash捕获SDK是如何更靠前的进行初始化，从而捕获Application中onCreate()的崩溃信息的呢？这就是本文要讨论的内容，使用ContentProvider初始化你的Library。

2. 优点

• 不需要在Application中的onCreate()中去初始化SDK，接入方无需写一行初始化代码，使用ContentProvider初始化你的Library是自动初始化而无需额外代码的最可靠方法。
• 像Firebase这种Crash捕获SDK中，可以捕获Application中onCreate()的崩溃信息。

为什么会有这样的优点

• 因为Firebase等类似的第三方SDK，在自己Library的清单文件中声明一个ContentProvider，并将初始化操作放在这个ContentProvider的onCreate()中。在App启动时，这个初始化的调用时机介于Application的attachBaseContext()和onCreate()之间。
• 在build的过程中，Library中的清单文件会被merge进App的主清单文件。

3. 缺点

• 在极端的情况下会初始化失败。
• 会影响启动速度，虽然影响很小，但是肯定会影响。

为什么会有这样的缺点

• 当你的App中某个组件必须在非主进程中运行时，这个进程将不会创建任何ContentProvider，导致初始化失败，因为ContentProviders必须在主进程中运行。而使用传统的初始化方式就不会有这种问题，因为Application中的onCreate()会被调用N次。N=App进程数。
• 进程启动的时候，会启动ContentProvider，启动ContentProviders就牵扯AMS跟APP通信，比传统的初始化方式多了注册的环节。

4. 注意点

Manifest里设置ContentProvider的时候要设置一个authorities，这个authorities相当于ContentProvider的标识，是不能重复的。因此，如果你自己要编写Library，并打算使用ContentProvider进行初始化，因为你的Library可能会被很多App使用，如果authorities重复，会导致第二个使用你库的App安装失败。

因此建议使用applicationId进行唯一标识，ContentProvider的清单声明如下。

<provider
    android:authorities="${applicationId}.MyContentProvider"
    android:name=".MyLibRuntimeProvider"
    android:exported="false"/>

5. 参考文献

​​​​​​​How does Firebase initialize on Android?