Android 启动优化杂谈 | 另辟蹊径

Posted 2022-01-31 涂程

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Android 启动优化杂谈 | 另辟蹊径相关的知识，希望对你有一定的参考价值。

作者：究极逮虾户

开篇

先介绍下徐公大佬的文章，如果有前置需要的话建议看下这个系列。

启动优化这个系列都可以好好看看，感谢徐公大佬。

本文将不发表任何关于 有向无环图（DAG） 相关，会更细致的说一些我自己的奇怪的观点，以及从一些问题出发，介绍如何做一些有意思的调整。

当前仓库还处于一个迭代状态中，并不是一个特别稳定的状态，所以文章更多的是给大家打开一些小思路。

有想法的同学可以留言啊，我个人感觉一个迭代库才是可以持续演进的啊。

demo 地址 AndroidStartup

demo中很多代码参考了android-startup，感谢这位大佬，u1s1这位大佬很强啊。

Task粒度

这一点其实蛮重要的，相信很多人在接入启动框架之后，更多的事情是把原来可以用的代码，直接用几个Task的把之前的代码包裹起来，之后然后这样就相当于完成了简单的启动框架接入了。

其实这个基本算是违背了启动框架设计的初衷了。我先抛出一个观点，启动框架并不会真实帮你加快多少启动速度，他解决的场景只是让你的sdk的初始化更加的有序，让你可以在长时间的迭代过程中，可以更加稳妥的添加一些新的sdk。

举个栗子，当你的埋点框架依赖了网络库，abtest配置中心也依赖了网络库，然后网络库则依赖了dns等等，之后所有的业务依赖了埋点配置中心图片库等等sdk的初始化完成之后。

当然还是有极限情况下会出现依赖成环问题，这个时候可能就需要开发同学手动的把这个依赖问题给解决了比如特殊情况网络库需要唯一id，上报库依赖了网络库，而上报库又依赖了唯一id，唯一id又需要进行数据上报

所以我个人的看法启动框架的粒度应该细化到每个sdk的初始化，如果粒度可以越细致当然就越好了。其实一般的启动框架都会对每个task的耗时进行统计的，这样我们后续在跟进对应的问题也会变的更简便，比如查看某些的任务耗时是否增加了啊之类的。

当前我们在设计的时候可能会把一个sdk的初始化拆分成三个部分去做，就是为了去解决这种依赖成环的问题。

子线程间的等待

之前发现项目内的启动框架只保证了放入线程的时候的顺序是按照dag执行的。如果只有主线程和池子大小为1线程池的情况下，这种是ok的。但是如果多线程并发的情况下，这个就变成了一个危险操作了。

所以我们需要在并发场景下加上一个等待的情况下，一定要等到依赖的任务完成了之后，才能继续向下执行初始化代码。

机制的话还是使用CountDownLatch，当依赖的任务都执行完成之后，await会被释放，继续向下执行。而设计上我还是采取了装饰者，不需要使用方更改原始的逻辑就能继续使用了。

代码如下，主要就是一次任务完成的分发，之后发现当前的依赖是有该任务的则latch-1. 当latch到0的情况下就会释放当前线程了。

class StartupAwaitTask(val task: StartupTask) : StartupTask 

    private var dependencies = task.dependencies()
    private lateinit var countDownLatch: CountDownLatch
    private lateinit var rightDependencies: List<String>
    var awaitDuration: Long = 0

    override fun run(context: Context) 
        val timeUsage = SystemClock.elapsedRealtime()
        countDownLatch.await()
        awaitDuration = (SystemClock.elapsedRealtime() - timeUsage) / 1000
        KLogger.i(
            TAG, "taskName:$task.tag()  await costa:$awaitDuration "
        )
        task.run(context)
    

    override fun dependencies(): MutableList<String> 
        return dependencies
    

    fun allTaskTag(tags: HashSet<String>) 
        rightDependencies = dependencies.filter  tags.contains(it) 
        countDownLatch = CountDownLatch(rightDependencies.size)
    

    fun dispatcher(taskName: String) 
        if (rightDependencies.contains(taskName)) 
            countDownLatch.countDown()
        
    

    override fun mainThread(): Boolean 
        return task.mainThread()
    

    override fun await(): Boolean 
        return task.await()
    

    override fun tag(): String 
        return task.tag()
    

    override fun onTaskStart() 
        task.onTaskStart()
    

    override fun onTaskCompleted() 
        task.onTaskCompleted()
    

    override fun toString(): String 
        return task.toString()
    

    companion object 
        const val TAG = "StartupAwaitTask"

这个算是一个能力的补充完整，也算是多线程依赖必须要完成的一部分。

同时将依赖模式从class变更成tag的形式，但是这个地方还没完成最后的设计，当前还是有点没想好的。主要是解决组件化情况下，可以更随意一点。

线程池关闭

这里是我个人考虑哦，当整个启动流程结束之后，默认情况下是不是应该考虑把线程池关闭了呢。我发现很多都没有写这些的，会造成一些线程使用的泄漏问题。

fun dispatcherEnd() 
    if (executor != mExecutor) 
        KLogger.i(TAG, "auto shutdown default executor")
        mExecutor.shutdown()

代码如上，如果当前线程池并不是传入的线程池的情况下，考虑执行完毕之后关闭线程池。

dsl + 锚点

因为我既是开发人员，同时也是框架的使用方。所以我自己在使用的过程中发现原来的设计上问题还是很多的，我自己想要插入一个在所有sdk完成之后的任务非常不方便。

然后我就考虑这部分通过dsl的方式去写了动态添加task。kotlin是真的很香，如果后续开发没糖我估计就是个废人了。

我就是死从这里跳下去，卧槽语法糖真香。

fun Application.createStartup(): Startup.Builder = run 
    startUp(this) 
        addTask 
            simpleTask("taskA") 
                info("taskA")
            
        
        addTask 
            simpleTask("taskB") 
                info("taskB")
            
        
        addTask 
            simpleTask("taskC") 
                info("taskC")
            
        
        addTask 
            simpleTaskBuilder("taskD") 
                info("taskD")
            .apply 
                dependOn("taskC")
            .build()
        
        addTask("taskC") 
            info("taskC")
        
        setAnchorTask 
            MyAnchorTask()
        
        addTask 
            asyncTask("asyncTaskA", 
                info("asyncTaskA")
            , 
                dependOn("asyncTaskD")
            )
        
        addAnchorTask 
            asyncTask("asyncTaskB", 
                info("asyncTaskB")
            , 
                dependOn("asyncTaskA")
                await = true
            )
        
        addAnchorTask 
            asyncTaskBuilder("asyncTaskC") 
                info("asyncTaskC")
                sleep(1000)
            .apply 
                await = true
                dependOn("asyncTaskE")
            .build()
        
        addTaskGroup  taskGroup() 
        addTaskGroup  StartupTaskGroupApplicationKspMain() 
        addMainProcTaskGroup  StartupTaskGroupApplicationKspAll() 
        addProcTaskGroup  StartupProcTaskGroupApplicationKsp()

这种DSL写法适用于插入一些简单的任务，可以是一些没有依赖的任务，也可以是你就是偷懒想这么写。好处就是可以避免自己用继承等的形式去写过多冗余的代码，然后在这个启动流程内能看到自己做了些什么事情。

一般等到项目稳定之后，会设立几个锚点任务。他们的作用是后续任务只要挂载到锚点任务之后执行即可，定下一些标准，让后续的同学可以更快速的接入。

我们会把这些设置成一些任务组设置成基准，比如说是网络库，图片库，埋点框架,abtest等等，等到这些任务完成之后，别的业务代码就可以在这里进行初始化了。这样就不需要所有人都写一些基础的依赖关系，也可以让开发同学舒服一点点。

怎么又成环了

在之前的排序阶段，存在一个非常鬼畜的问题，如果你依赖的任务并不在当前的图中存在，就会报出依赖成环问题，但是你并不知道是因为什么原因成环的。

这个就非常不方便开发同学调试问题了，所以我增加了前置任务有效性判断，如果不存在的则会直接打印Log日志，也增加了debugmode，如果测试情况下可以直接已任务不存在的崩溃结束。

ksp

我想偷懒所以用ksp生成了一些代码，同时我希望我的启动框架也可以应用于项目的组件化和插件化中，这样反正就是牛逼啦。

启动任务分组

当前完成的一个功能就是通过注解+ksp生成一个启动任务的分组，这次ksp的版本我们采用的是1.5.30的版本，同时api也有了一些变更。

之前在ksp的文章说过process死循环的问题，最近和米忽悠乌蝇哥交流（吹牛）的时候发现，系统提供一个finish方法，因为process的时候只要有类生成就会重新出发process方法，导致stackoverflow，所以后续代码生成可以考虑迁移到新方法内。

class StartupProcessor(
    val codeGenerator: CodeGenerator,
    private val logger: KSPLogger,
    val moduleName: String
) : SymbolProcessor 
    private lateinit var startupType: KSType
    private var isload = false
    private val taskGroupMap = hashMapOf<String, MutableList<ClassName>>()
    private val procTaskGroupMap =
        hashMapOf<String, MutableList<Pair<ClassName, ArrayList<String>>>>()

    override fun process(resolver: Resolver): List<KSAnnotated> 
        logger.info("StartupProcessor start")

        val symbols = resolver.getSymbolsWithAnnotation(StartupGroup::class.java.name)
        startupType = resolver.getClassDeclarationByName(
            resolver.getKSNameFromString(StartupGroup::class.java.name)
        )?.asType() ?: kotlin.run 
            logger.error("JsonClass type not found on the classpath.")
            return emptyList()
        
        symbols.asSequence().forEach 
            add(it)
        
        return emptyList()
    

    private fun add(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

        //class type

        val routerAnnotation = type.findAnnotationWithType(startupType) ?: return
        val groupName = routerAnnotation.getMember<String>("group")
        val strategy = routerAnnotation.arguments.firstOrNull 
            it.name?.asString() == "strategy"
        ?.value.toString().toValue() ?: return
        if (strategy.equals("other", true)) 
            val key = groupName
            if (procTaskGroupMap[key] == null) 
                procTaskGroupMap[key] = mutableListOf()
            
            val list = procTaskGroupMap[key] ?: return
            list.add(type.toClassName() to (routerAnnotation.getMember("processName")))
         else 
            val key = "$groupName$strategy"
            if (taskGroupMap[key] == null) 
                taskGroupMap[key] = mutableListOf()
            
            val list = taskGroupMap[key] ?: return
            list.add(type.toClassName())
        
    

    private fun String.toValue(): String 
        var lastIndex = lastIndexOf(".") + 1
        if (lastIndex <= 0) 
            lastIndex = 0
        
        return subSequence(lastIndex, length).toString().lowercase().upCaseKeyFirstChar()
    
       // 开始代码生成逻辑
    override fun finish() 
        super.finish()
        // logger.error("className:$moduleName")
        try 
            taskGroupMap.forEach  it ->
                val generateKt = GenerateGroupKt(
                    "$moduleName.upCaseKeyFirstChar()$it.key.upCaseKeyFirstChar()",
                    codeGenerator
                )
                it.value.forEach  className ->
                    generateKt.addStatement(className)
                
                generateKt.generateKt()
            
            procTaskGroupMap.forEach 
                val generateKt = GenerateProcGroupKt(
                    "$moduleName.upCaseKeyFirstChar()$it.key.upCaseKeyFirstChar()",
                    codeGenerator
                )
                it.value.forEach  pair ->
                    generateKt.addStatement(pair.first, pair.second)
                
                generateKt.generateKt()
            
         catch (e: Exception) 
            logger.error(
                "Error preparing :" + " $e.stackTrace.joinToString("\\n")"
            )
        
    


class StartupProcessorProvider : SymbolProcessorProvider 
    override fun create(
        environment: SymbolProcessorEnvironment
    ): SymbolProcessor 
        return StartupProcessor(
            environment.codeGenerator,
            environment.logger,
            environment.options[KEY_MODULE_NAME] ?: "application"
        )
    


fun String.upCaseKeyFirstChar(): String 
    return if (Character.isUpperCase(this[0])) 
        this
     else 
        StringBuilder().append(Character.toUpperCase(this[0])).append(this.substring(1)).toString()
    


const val KEY_MODULE_NAME = "MODULE_NAME"