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

一、背景

 先看一下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.*/@NonNullT 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`.*/@NonNullList<Class<? extends Initializer<?>>> dependencies();
}

1. oncreate：初始化组件所需的所有操作，并返回T的实例。
2. 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，分为两种情况，一种是自动，还有一种是手动。

1. 自动：

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

provider：添加startUp的provider。

<meta-data>：就是我们初始化的对象类

执行如下：

 自动完成其实是调用了

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();}}

1. 手动调用：

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

tools:node="remove"

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

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

        <providerandroid:name="androidx.startup.InitializationProvider"android:authorities="${applicationId}.androidx-startup"android:exported="false"tools:node="merge"><meta-dataandroid:name="com.example.wiik.testdemo.startup.MyInitializer"android:value="androidx.startup" /><meta-dataandroid: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的基本架构分析与使用，如果你需要使用该框架，可以将自己的类管里起来。   

 注意：

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