Application、ContentProvider、Activity执行顺序

再了解Google官方出品的Android Architecture Components过程中，发现组件库接入过程中并不需要做初始化工作。通过查看源码，且分析apk中的AndroidManifest.xml发现文件中包含如下配置：

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1"
    android:versionName="1.0"
    package="com.example.android.persistence">
    <application
        android:theme="@ref/0x7f0d0006"
        android:label="@ref/0x7f0c001f"
        android:icon="@ref/0x7f0b0000"
        android:debuggable="true"
        android:testOnly="true"
        android:allowBackup="false"
        android:supportsRtl="true">

        <provider
          android:name="android.arch.lifecycle.ProcessLifecycleOwnerInitializer"
            android:exported="false"
            android:multiprocess="true"
            android:authorities="com.example.android.persistence.lifecycle-trojan" />
    </application>
</manifest>

随之对ProcessLifecycleOwnerInitializer产生兴趣，其代码很简单，只是继承ContentProvider，并在onCreate方法中做了初始化。

@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
    @Override
    public boolean onCreate() {
        LifecycleDispatcher.init(getContext());
        ProcessLifecycleOwner.init(getContext());
        return true;
    }
    //省略部分代码
}

通过测试日志发现执行顺序如下：

Application->attachBaseContext()
ContentProvider->onCreate()
Application->onCreate()
Activity->onCreate()

可见在接入组件库后，打包过程中合并AndroidManifest.xml文件，注册了ContentProvider。利用其执行顺序这个特性，去初始化组件库。

很是巧妙的解耦方式。

Application, Activity, ContentProvider启动顺序
Android的Proxy/Delegate Application框架