目录
背景
之前我不想用注解来写启动框架，因为启动框架需要的参数太多了。将参数都定义在注解内和写一个task就没有本质上的差别，所以一直觉得没必要用注解来搞。
但是之前和另外一个同事聊了下，如果注解也可以进行排列组合，那么貌似就可以用注解来解决这个问题咯，感觉这样用起来就会很好玩了。
开卷开卷
首先要做的事情就是定义出我们想要的注解，可以基于我们之前对于task的定义来进行注解的定义，比如是不是主线程，是否需要等待完成，task的依赖任务，是否是锚点任务等等。
// 是否异步
@Async
// 是否等待
@Await
// 锚点任务
@MustAfter
// 依赖关系
@DependOn(
dependOn = [AsyncTask1Provider::class, SimpleTask2Provider::class],
dependOnTag = ["taskB"]
)
注解呢上面的这些就是我定义出来的新增的注解的，我后续会通过这些注解来组合出我所想要的启动的Task。
Ksp解析注解
这里我定义了一个Startup的注解，这个注解的目的就是标识当前的类是一个启动的Task。因为在ksp或者apt的compiler环节上，都会先尝试获取到当前语法树的所有注解的类。
package com.kronos.startup.annotation.startup
import com.kronos.startup.annotation.Process
/**
*
* @Author LiABao
* @Since 2021/12/31
*
*/
@Target(
AnnotationTarget.ANNOTATION_CLASS,
AnnotationTarget.CLASS
)
@Retention
annotation class Startup(
// 进程策略
val strategy: Process = Process.ALL,
//进程名
val processName: Array<String> = []
)
从demo开始逐步推导我打算咋写这些东西。下面是我定义的一个简单的启动任务，Task具体内容应该有apt来生成。
@Async
@Await
@MustAfter
@DependOn(
dependOn = [AsyncTask1Provider::class, SimpleTask2Provider::class],
dependOnTag = ["taskB"]
)
// 执行的进程名
@Startup(strategy = Process.MAIN)
class SampleGenerate1Task : TaskRunner {
override fun run(context: Context) {
info("SampleGenerate1Task")
}
}
还是我一开始的说法，我们的第一个切入点是Startup注解，然后获取到SampleGenerate1Task的抽象语法树信息，之后再进行下一步操作。
private fun addStartUp(type: KSAnnotated) {
logger.check(type is KSClassDeclaration && type.origin == Origin.KOTLIN, type) {
"@JsonClass can't be applied to $type: must be a Kotlin class"
}
if (type !is KSClassDeclaration) return
val startupAnnotation = type.findAnnotationWithType(startupType) ?: return
taskMap.add(StartupTaskBuilder(type, startupAnnotation))
}
基于KSClassDeclaration语法树的信息，我们可以获取到当前类上的注解，然后在收集完成之后再来生成对应的启动任务。首先我们先要获取到类上的所有的注解，然后进行遍历，当当前注解符合我们所需要的类型情况下，调整数据结构信息就可以了。
class StartupTaskBuilder(type: KSClassDeclaration, startupAnnotation: KSAnnotation?) {
val className = type.toClassName()
var isAsync = false
var isAwait = false
var strategy: String
var processList: ArrayList<String> = arrayListOf()
val dependOnClassList = mutableListOf<ClassName>()
val dependOnStringList = mutableListOf<String>()
var mustAfter: Boolean = false
var lifecycle: Lifecycle = Lifecycle.OnApplicationCrate
init {
type.annotations.forEach {
val annotation = it.annotationType.resolve().toClassName()
if (annotation.canonicalName == "com.kronos.startup.annotation.startup.Async") {
isAsync = true
}
if (annotation.canonicalName == "com.kronos.startup.annotation.startup.Await") {
isAwait = true
}
if (annotation.canonicalName == "com.kronos.startup.annotation.startup.MustAfter") {
mustAfter = true
}
if (annotation.canonicalName == "com.kronos.startup.annotation.startup.DependOn") {
val value = it.getMember<ArrayList<ClassName>>("dependOn")
dependOnClassList.addAll(value)
val dependOnTag = it.getMember<ArrayList<String>>("dependOnTag")
dependOnStringList.addAll(dependOnTag)
}
if (annotation.canonicalName == "com.kronos.startup.annotation.Step") {
val value = it.arguments.firstOrNull {
it.name?.asString() == "lifecycle"
}?.value.toString().nameToLifeCycle()
lifecycle = value
mLogger?.warn("stage:$value")
}
}
type.getAllSuperTypes().forEach {
it.toClassName()
}
strategy = startupAnnotation?.arguments?.firstOrNull {
it.name?.asString() == "strategy"
}?.value.toString().toValue()
val list = startupAnnotation?.getMember<ArrayList<String>>("processName")
list?.let { processList.addAll(it) }
}
xxxxxxx
}
接下来我们用了一个数据结构来收集这些注解信息，然后和上篇文章说的一样。我们会在注解信息收集完毕之后在finish方法进行代码的生成逻辑。有兴趣的同学可以自己看下GenerateTaskKt，逻辑相对来说比较简单，基于数据结构插入不同的kt代码逻辑。
//SymbolProcessor
override fun finish() {
super.finish()
try {
val taskGenerate = GenerateTaskKt(taskMap, codeGenerator)
taskGenerate.procTaskGroupMap.forEach {
val list = procTaskGroupMap.getValueByDefault(it.key) {
mutableListOf()
}
list.addAll(it.value)
}
}
}
Task生成还需要结合TaskGroup概念
因为我们之前的设想是回生成一个任务的分组StartupTaskProcessGroup，所以这部分代码上传的Task也需要保持一致。
我们需要做的就是将这些由ksp生成的Task类信息也带到TaskGroup的生成逻辑中去。
由于我们之前的底子比较好，所以我们只要在将这些类生成的信息插入到原来的list中去则就可以完成这个操作了。
private val procTaskGroupMap =
hashMapOf<Lifecycle, MutableList<TaskBuilder>>()
val taskGenerate = GenerateTaskKt(taskMap, codeGenerator)
taskGenerate.procTaskGroupMap.forEach {
val list = procTaskGroupMap.getValueByDefault(it.key) {
mutableListOf()
}
list.addAll(it.value)
}
其实我们在上面的Task遍历的时候就已经对于这个list进行了代码插入的操作了。这样就能做到后续的插入逻辑了。
拆分启动步骤
接下来我想说的就是另外一个概念了， 因为现在有很多隐私合规的诉求，所以大部分的公司都需要做一件事，就是把隐私前的初始化逻辑和隐私后的初始化逻辑进行拆分。
这也就有了我想说的分步骤的事情了，所以我们需要在重新定义一个新的注解出来。
@Target(
AnnotationTarget.ANNOTATION_CLASS,
AnnotationTarget.CLASS
)
@Retention
annotation class Step(val lifecycle: Lifecycle = Lifecycle.OnApplicationCrate)
enum class Lifecycle(val value: String) {
AttachApplication("AttachApplication"), OnApplicationCrate("OnApplicationCrate"),
AfterUserPrivacy("AfterUserPrivacy")
}
这个就是我设想的分阶段分步骤的概念，我在demo中设置了三个不同的阶段，分别对应application的attach和create，还有隐私同意之后的代码。
这次呢，我在上述task的基础上又再次加了点东西进去，我希望一个module对外输出的是一个包含了所有阶段的StartupTaskProcessGroup的数组,我把它叫做StepTaskBuilder。
之后我们只要将所有模块的StepTaskBuilder收集到一起，则就可以完成自动的初始化任务，这样做的一个好处就是后续这种依赖关系就可以在编译打包阶段都完成了，代码内只需要加入调用就可以了。
val stageGenerator = StageGenerateKt(
"${moduleName.upCaseKeyFirstChar()}StepBuilder",
nameList,
codeGenerator
)
stageGenerator.generateKt()
我在finish方法的最后面加入了这段，就是拿来生成StepTaskBuilder用的。逻辑也相对比较简单，大家自取看看就好了。
依赖注入
看到这个小标题，我知道各位都会有迷惑。为什么一个破启动框架还需要依赖注入的逻辑？
正常情况下，我们在写sdk的时候，会有很多的初始化参数都需要使用方来定义的，比如okhttp的超时时间，缓存路径，线程大小这类的变更的参数。
那么同样的情况也会出现在启动框架内，我们想做的是一个能自动的初始化框架，那么这部分变更的参数就需要被注入。
demo中使用koin来完成的依赖注入，将依赖翻转到最外层，将变化的部分由app来设置，基本就能满足我的诉求了。
application内的实现类设置具体的实现如下。
val appModule = module {
single<ReportInitDelegate> {
ReportInitDelegateImp()
}
}
private class ReportInitDelegateImp : ReportInitDelegate {
override fun getAppName(): String {
return "123444556"
}
}
在sdk模块初始化的时候通过依赖注入抽象接口的实现，这样就可以再SDK直接进行初始化代码的编写了。可以规避掉一些sdk的初始化顺序问题。
@Async
@Await
@DependOn(dependOn = [NetworkSdkTaskProvider::class])
@Startup
class ReportSdkTask : KoinComponent, TaskRunner {
private val initDelegate: ReportInitDelegate by inject()
override fun run(context: Context) {
info("ReportSdkTask appName is:${initDelegate.getAppName()}")
}
}
TODO
还有个收集所有module内的StepTaskBuilder功能没写，这部分需要增加一个Plugin，在编译阶段收集好所有，基本就可以完成对应的功能了。
总结
这部分我觉得还是挺有意思的，我们原来的设计上就是通过这种自动化的启动框架，后续来完成所有壳工程的建设，让开发同学尽量少感知到启动流程相关的逻辑。
以上就是Android开发注解排列组合出启动任务ksp的详细内容，更多关于Android注解排列组合启动任务ksp的资料请关注其它相关文章！
