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"/>