本文共 1162 字，大约阅读时间需要 3 分钟。
1. 前言
众所周知，很多第三方SDK是在Application中的onCreate()中去初始化的，形如：
@Overridepublic 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的清单声明如下。
转载地址：http://ghwci.baihongyu.com/