在之前的文章中，我介绍了自研的 Android 启动任务调度工具 AndroidStartup。近期，因为在组件化项目中运用该项目的需要，我对这个库做了一番升级。在最新的 2.2 版本中，我新增了一些特性。相比于目前市面上其他的启动任务调度库，使其具备了更多的优势。这里我只介绍下经过新的版本迭代之后该项目与其他项目的不同点。对于其基础的实现原理，可以参考我之前的文章 《异步、非阻塞式 Android 启动任务调度库》。
1、支持多种线程模型
这是相对于 Jetpack 的启动任务库的优势，在指定任务的时候，你可以通过 ISchedulerJob 的 threadMode() 方法指定该任务执行的线程，当前支持主线程（ThreadMode.MAIN）和非主线程（ThreadMode.BACKGROUND）两种情况。前者在主线程当中执行，后者在线程池当中执行，同时，该库还允许你自定义自己的线程池。关于这块的实现原理可以参考之前的文章或者项目源码。
2、非阻塞的任务调度方式
在之前的文章中也提到了，如果说采用 CountDownLatch 等阻塞的方式来实现任务调度，虽然不会占用主线程的 CPU，但是子线程会被阻塞，一样会导致 CPU 空转，影响程序执行的性能，尤其启动的时候大量任务执行时的情况。所以，在这个库的设计中，我们使用了通知唤醒的方式进行任务调度。也就是，
首先，它会将所有的需要执行的任务收集起来；然后，它会根据任务的依赖关系指定分发和调度任务的子任务；最后，当当前任务执行完毕，该任务会通知所有的子任务按照顺序执行。大致实现逻辑如下，
override fun execute() {
val realJob = {
// 1. Run the task if match given process.
if (matcher.match(job.targetProcesses())) {
job.run(context)
}
// 2. Then sort children task.
children.sortBy { child -> -child.order() }
// 3. No matter the task invoked in current process or not,
// its children will be notified after that.
children.forEach { it.notifyJobFinished(this) }
}
try {
if (job.threadMode() == ThreadMode.MAIN) {
// Cases for main thread.
if (Thread.currentThread() == Looper.getMainLooper().thread) {
realJob.invoke()
} else {
mainThreadHandler.post { realJob.invoke() }
}
} else {
// Cases for background thread.
executor.execute { realJob.invoke() }
}
} catch (e: Throwable) {
throw SchedulerException(e)
}
}
3、非 Class 的依赖方式
之前在本项目中，以及其他的项目中可能采用了基于 Class 的形式进行任务依赖。这种使用方式存在一些问题，即在组件化开发的时候，Class 之间需要直接进行引用。这导致各个组件之间的强耦合。这显然不是我们希望的。
所以，为了更好地支持组件化，在该库的新版本中，我们允许通过 name() 方法执行任务的名称，以及通过 dependencies() 方法指定该任务依赖的其他任务的名称。name() 默认使用任务 Class 的全限定名。这样，当多个组件之间进行相互依赖的时候，只需要通过字符串指定名称而无需引用具体的类。
比如，一个任务在一个组件中定义如下，
@StartupJob class BlockingBackgroundJob : ISchedulerJob {
override fun name(): String = "blocking"
override fun threadMode(): ThreadMode = ThreadMode.BACKGROUND
override fun dependencies(): List<String> = emptyList()
override fun run(context: Context) {
Thread.sleep(5_000L) // 5 seconds
L.d("BlockingBackgroundJob done! ${Thread.currentThread()}")
toast("BlockingBackgroundJob done!")
}
}
在另一个组件中的另一个任务需要依赖上述任务的时候，定义如下，
@StartupJob class SubModuleTask : ISchedulerJob {
override fun dependencies(): List<String> = listOf("blocking")
override fun run(context: Context) {
Log.d("SubModuleTask", "runed ")
}
}
这样我们就实现组件化场景中的依赖关系了。
4、支持任务的优先级
在实际开发中，我们可能会遇到需要为所有的根任务或者一个任务的所有的子任务指定执行的先后顺序的场景。或者在组件化中，存在依赖关系，但是我们希望某个根任务优先执行，但是不想为每个子任务都执行依赖关系的时候，我们可以通过指定这个任务的优先级为最高来使其最先被执行。你可以通过 priority() 方法传递一个 0 到 100 的整数来指定任务的优先级。
@StartupJob class TopPriorityJob : ISchedulerJob{
override fun priority(): Int = 100
override fun run(context: Context) {
L.d("Top level job done!")
}
}
优先级局限于依赖关系相同的任务，所以是依赖关系的补充，不会造成歧义。
5、支持指定任务执行的进程，可自定义进程匹配策略
如果我们的项目支持多进程，而我们希望某些启动任务只在某个进程中执行而其他进程不需要执行，以此避免没必要的任务来提升任务执行的性能的时候，我们可以通过指定任务执行的进程来进行优化。你可以通过 targetProcesses() 传递一个进程的列表来指定该任务执行的所有进程。默认列表为空，表示运行在所有的进程。
对于进程的匹配，我们提供了 IProcessMatcher 这个接口，
interface IProcessMatcher {
fun match(target: List<String>): Boolean
}
你可以通过指定这个接口来自定义线程的匹配策略。
6、支持注解形式的组件化调用
在之前的版本中，通过 ContentProvider 的形式我们一样可以实现所有组件内任务的收集和调用。但是使用 ContentProvider 存在一些不便之处，比如 ContentProvider 的初始化实际在 Application 的 attachBaseContext()，如果我们的任务中一些操作需要放到 Application 的 onCreate() 中执行的时候，通过 ContentProvider 默认装载任务的调度方式就存在问题。而通过基于注解 + APT的形式，我们可以随意指定任务收集、整理和执行的时机，灵活性更好。
为了支持组件化，我们在之前的项目上做了一些拓展。之前的项目虽然也是基于注解发现机制，但是在组件化的应用中存在问题。在新的版本中，我们只是处理了组件化应用场景中的问题，但是使用方式上面完全兼容，只不过你需要为每个组件在 gradle.build 中增加一个行信息来指定组件的名称（就像 ARouter 一样），
javaCompileOptions {
annotationProcessorOptions {
arguments = [STARTUP_MODULE_NAME: project.getName()]
}
}
也就是说你还是通过 @StartupJob 注解将任务标记为启动任务，然后通过
launchStartup(this) {
scanAnnotations()
}
这行代码启动扫描并执行任务。
在新的版本中，所有生产的代码会被统一放到包 me.shouheng.startup.hunter 下面，然后通过 JobHunter$$组件名 的形式为每个组件生成自己的类，然后在扫描任务的时候通过加载这个包名之下的所有的代码来找到所有要执行的任务。如果你对组件化感兴趣可以直接阅读这块的源码实现。
总结
启动任务调度库的设计不算复杂，但是我却在之前的面试中两次被问到如何设计。这种类型的问题能很好地考察代码设计能力。相信阅读这个库的代码之后，此类的问题再也难不倒你。如果你对 APT+注解 的组件化实现方式等感兴趣一样可以阅读这个库的代码。
以上介绍了这个库的一些特性和优势，没用过多地介绍其源码实现，感兴趣的同学可以直接阅读项目的源码，相信你能够从代码中学到一些东西。对于示例项目，除了阅读这个项目的示例，还可以参考 Android-VMLib 这个项目。该项目地址：https://github.com/Shouheng88/AndroidStartup。
