一、背景

先看一下Android系统架构图

在Android设备中，设备先通电（PowerManager），然后加载内核层，内核走完，开始检查硬件，以及为硬件提供的公开接口，然后进入到库的加载。库挂载后开始Init进程初始化，调用init.rc。紧接着就是Android系统的核心模块Zygote进程的初始化，这些开始走到了Framework层，Zygote会fork各种进程，AMS，WMS，Handler等，并且AMS和WMS以及其他的service都会被SystemService存储起来，通过SystemServiceManager来管理，同样MainThread主进程也会在Zygote进程中创建。在创建各种service的时候，同样也会这些服务提供了binder，这样就可以和这些service进行通讯。

为什么要通过这张图来分析Andtroid系统？那是因为我们熟悉了整个启动流程才会更好的使用这个框架，简单、高效的完成组件加载。

二、常见的Application中加载机制

在正常开发过程中，模块为了长期存活在应用中，都会提前抢占application的入口。在application中，比较常见的都是直接在oncreate方法中执行。因为APP启动，是有AMS或者ATMS来完成application的创建(这就是为什么在上面介绍Android系统架构)。第一次启动正确的耗时应该从attachBaseContext()到第一个第一个Activity的onResume()的完成。这样加载机制，运行在主线程中，又会引起另外一个问题，那就是卡顿和启动时间过长。

针对这个问题，google提供了一个startup库，实现一种在应用启动时初始化组件的简单而高效的方法。

三、StartUp组件

startup库，实现一种在应用启动时初始化组件的简单而高效的方法。借助 App Startup 库，可在应用启动时简单、高效地初始化组件。库开发者和应用开发者都可以使用 App Startup 来简化启动序列并显式设置初始化顺序。

依赖库

implementation 'androidx.startup:startup-runtime:1.1.1'

代码库：

核心的如上面包里的类所示。任何需要初始化的节点，都需要实现Initializer的接口。

public interface Initializer<T> {

    /**
     * Initializes and a component given the application {@link Context}
     *
     * @param context The application context.
     */
    @NonNull
    T create(@NonNull Context context);

    /**
     * @return A list of dependencies that this {@link Initializer} depends on. This is
     * used to determine initialization order of {@link Initializer}s.
     * <br/>
     * For e.g. if a {@link Initializer} `B` defines another
     * {@link Initializer} `A` as its dependency, then `A` gets initialized before `B`.
     */
    @NonNull
    List<Class<? extends Initializer<?>>> dependencies();
}

oncreate：初始化组件所需的所有操作，并返回T的实例。
dependencies：依赖项，如果当前的组件在初始化的时候，依赖其他组件，将其他初始化项添加进来即可。（即需赖的Initializer初始化后，才会创建自己）

案例：

class MyInitializer(): Initializer<Boolean> {

    override fun create(context: Context): Boolean {


        Log.e("init","create-A")
       

        return true
    }

    override fun dependencies(): MutableList<Class<out Initializer<*>>> {

        Log.e("init","dependencies-A")
        return mutableListOf()
    }
}

启动StartUp

启动startUp，分为两种情况，一种是自动，还有一种是手动。

自动：

        <provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="merge">
            <meta-data
                android:name="com.example.wiik.testdemo.startup.MyInitializer"
                android:value="androidx.startup" />

        </provider>

provider：添加startUp的provider。

执行如下：

自动完成其实是调用了

AppInitializer.getInstance(context).discoverAndInitialize();


    void discoverAndInitialize() {
        try {
            Trace.beginSection(SECTION_NAME);
            ComponentName provider = new ComponentName(mContext.getPackageName(),
                    InitializationProvider.class.getName());
            ProviderInfo providerInfo = mContext.getPackageManager()
                    .getProviderInfo(provider, GET_META_DATA);
            Bundle metadata = providerInfo.metaData;
            discoverAndInitialize(metadata);
        } catch (PackageManager.NameNotFoundException exception) {
            throw new StartupException(exception);
        } finally {
            Trace.endSection();
        }
    }

手动调用：

手动调用也是需要注册provider，新增meta-data元素，但是手动调用需要新增一个节点，

tools:node="remove"

申请1：在meta-data节点下申请，那只有这一个meta-data的init对象是手动，其他还是自动完成

申请2：在provider节点下申请，那provider节点下所有的节点都是需要时手动创建

        <provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="merge">
            <meta-data
                android:name="com.example.wiik.testdemo.startup.MyInitializer"
                android:value="androidx.startup" />
            <meta-data
                android:name="com.example.wiik.testdemo.startup.HandInitializer"
                android:value="androidx.startup"
                tools:node="remove" />


        </provider>

手动调用：

boolean flag = AppInitializer.getInstance(this).initializeComponent(HandInitializer.class);
Log.e("init","hand return value="+flag);

日志如下：

1、在启动过程中，如果有自动和手动，那么先启动自动，再启动手动。

2、如果你的应用在init阶段有返回值，那么自动初始化无法完成，只有手动才能接收。

3、依赖dependencies

依赖是一种前置条件，这种前置一般需要提前初始化，如下。

先定义一个前置的Init对象

class ProposeInitializer(): Initializer<Boolean> {

    override fun create(context: Context): Boolean {


        Log.e("init","create-A-ProposeInitializer")
        WorkManager.initialize(context.applicationContext,Configuration.Builder().build());

        return true
    }

    override fun dependencies(): MutableList<Class<out Initializer<*>>> {

        Log.e("init","dependencies-C-ProposeInitializer")
        return mutableListOf()
    }
}

引用前置Initer的类

class MyInitializer(): Initializer<Boolean> {

    override fun create(context: Context): Boolean {


        Log.e("init","create-A-AUTO")

        return true
    }

    override fun dependencies(): MutableList<Class<out Initializer<*>>> {
        return mutableListOf(ProposeInitializer::class.java)
    }
}

分析：

执行顺序，A依赖了C，先执行A的依赖，在执行C的依赖，在执行C的创建，在执行A的创建

这个时候即使C是手动模式，也会变成自动。

如果C还依赖其他，将会遍历其他的。

是否是自动始化：isEagerlyInitialized

判断一个对象是否是自动，

  public boolean isEagerlyInitialized(@NonNull Class<? extends Initializer<?>> component) {
        // If discoverAndInitialize() was never called, then nothing was eagerly initialized.
        return mDiscovered.contains(component);
    }

这个类的方法在provider会被提前执行。

四、总结

这样，我们就完成了startUp的基本架构分析与使用，如果你需要使用该框架，可以将自己的类管里起来。

注意：

如果发现启动失败，看下前置条件，是否满足

Android JetPack之启动优化StartUp初始化组件的详解和使用

一、背景

先看一下Android系统架构图

二、常见的Application中加载机制

三、StartUp组件

依赖库

代码库：

案例：

启动StartUp

自动：

手动调用：

手动调用：

日志如下：

3、依赖dependencies

引用前置Initer的类

分析：

是否是自动始化：isEagerlyInitialized

四、总结

注意：

猜你喜欢