冷启动优化掉ContentProvider

多ContentProvider的问题：

Android 的启动流程是这样的，首先调用Application的attachBaseContext()方法，然后调用ContentProvider的onCreate()方法，接下来调用Application的onCreate()方法。

而Jetpack的组件 App Startup 设计的初衷，正是为了收拢 ContentProvider。有不少第三方的 SDk，为了使用者不必手动调用 SDK#init 方法，使用了 ContentProvider 这一个骚操作。

在 AndroidManifest 里面注册了自己的 xxSDkProvider，然后在 xxSDkProvider 的 onCreate 方面里面进行初始化，确实调用者不需要自己初始化了，可却增加了启动耗时，如果要作优化，还得自己剔除 ContentProvider 的初始化，值不值得，我是感觉没必要，这操作是真的骚。

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

</application>

 class XXSDKProvider : ContentProvider() {
     override fun onCreate(): Boolean {
         Log.d(TAG, "XXSDKProvider create()")
         XXSDK.init()
         return true
     }
    .....
}

 同时，这里给做启动优化的同学提供了一种思路。打开你的 Apk，看一下 AndroidManiest 里面有多少 provider，看一下是否有这样的骚操作。如果有，改一下，说不定启动优化，一下子就减少了 100 多 毫秒。

ContentProvider 初始化的这个思想，目前有挺多 SDK 这么做的，像 FaceBook 广告 SDK，友盟 SDk 等。我们在启动优化的时候，是不是可以去掉相应的 ContentProvider，减少创建 Provider 的时间

实际项目中 启动优化，大多数啊都会使用多线程异步加载，这时候 App start up 就显得很鸡肋了，没用

上述：https://mp.weixin.qq.com/s/i5BAW7hFcOXN-fh4qYC4cg

下面：https://blog.csdn.net/guolin_blog/article/details/108026357

在一台搭载Android 10系统的Pixel2手机上测试的情况。可以看到，一个空的ContentProvider大约会占用2ms的耗时，随着ContentProvider的增加，耗时也会跟着一起增加。如果你的应用程序中使用了50个ContentProvider，那么将会占用接近20ms的耗时。

注意这还只是空ContentProvider的耗时，并没有算上你在ContentProvider中执行逻辑的耗时。

这个测试结果告诉我们，虽然刚才所介绍的使用ContentProvider来进行初始化的设计方式很巧妙，但是如果每个第三方库都自己创建了一个ContentProvider，那么最终我们App的启动速度就会受到比较大的影响。
 

解决方案，APP Startup：

https://blog.csdn.net/guolin_blog/article/details/108026357

总结：

总结一下的话，这个库的整体用法非常简单，但是可能并不适合所有人去使用。如果你是一个库开发者，并且使用了ContentProvider的方式来进行初始化操作，那么你应该接入App Startup，这样可以让接入你的库的App降低启动耗时。而如果你是一个App开发者，我认为使用ContentProvider来进行初始化操作的概率很低，所以可能App Startup对你来说用处并不大。