我要抄袭字节的Bytex了 | Transform 进阶教程

逮虾户

发布于 2021-03-03 16:17:22

1.4K0

发布于 2021-03-03 16:17:22

文章被收录于专栏：逮虾户逮虾户

我是小偷

Demo项目还是之前的Github地址，贴在项目的最前面，有兴趣的大佬求求你点个star吧。

ByteX是一个基于gradle transform api和ASM的字节码插件平台（或许，你可以把它当成一个有无限个插头的插座？）。
目前集成了若干个字节码插件，每个插件完全独立，既可以脱离ByteX这个宿主而独立存在，又可以自动集成到宿主和其它插件一起整合为一个单独的Transform。插件和插件之间，宿主和插件之间的代码是完全解耦的（有点像组件化），这使得ByteX在代码上拥有很好的可拓展性，新插件的开发将会变得更加简单高效。

bytex说白了就是一个插座，我去年就非常想自己也能有一个这玩意（偷鸡）。我会盘算一下如何用最简单的方式将多个插件优雅的组合到一起，形成自己的逮虾户x。但是我不是特别喜欢byteX，主要是因为我对他的api不熟悉啊，我还是自己折腾一下练练手好了。

总之说干就干，没理由你们行我就写不出来对吧。小菜虾加油！！！顺便让各位见识下我过年拼的零重力审判。

我想要啥

做事情之前一定要想好我想要什么，哪些是我一定需要的功能。

我想要那个插座的功能
但是单独的插件如果也能使用那么就更棒了
在当前的BaseTransform的基础上调整一下
我开始需要Task依赖了

开工了

读书人的事怎么能叫偷,具体的实现我参考了下滴滴的booster的一部分思路，booster还是写的非常不错的，其中将多个插件组合到一起就是用的AutoService。

但是动态化之后，你就缺失了能主动设置顺序的能力，这个时候如果插件之间有依赖关系，那么就需要另外一个东西来解决这个问题。

依赖顺序执行的这部分代码，我抄袭了下我大佬写的BRouter内的CachingDirectedGraphWalker,大佬则是参考了下Gradle编译时的依赖排序。

巧用AutoService

SPI （Service Provider Interface）是调用方来制定接口规范，提供给外部来实现，调用方在调用时则选择自己需要的外部实现。从使用人员上来说，SPI 被框架扩展人员使用。

如果你写过AbstractProcessor，我们会在上面打一个AutoService的注解。AutoService其实就是最简单粗暴的SPI(Service Provider Interface)。

而SPI机制可以帮助大家对于项目进行一定的解耦，因为是基于接口进行编程，而不是关心具体的实现类。举个例子如果AB两个业务之间相互依赖的情况下，你们一般会咋做呢？如果是我，肯定就会自己将其中ab互相调用的逻辑进行一次接口抽象，然后将实现类放在AB的模块内，因为直接使用的就是其接口，也就可以将两个模块间的循环依赖关系给解决了。

而SPI最重要的一个能力就是把项目内定义的注解收集起来，然后通过ServiceLoader把这些注解定义的实现类加载出来。因为AutoService是基于META-INFO格式的文件的，而文件因为有个IO操作，所以相对来说性能较差，但是如果是在Plugin中，这100ms左右的时间是完全可以被忽略的。

也就是说我只要在Base基础库定义好抽象接口，之后就可以在组合插件上，通过ServiceLoader机制，把所有的实现类都调用一次，就能完成这个简单的功能。

interface PluginProvider {

    fun getPlugin(): Class<out Plugin>


    fun dependOn(): List
}
复制代码

上面就是我定义的抽象接口，第一个方法就是获取当前定义好的插件，而第二个就是获取到当前插件所依赖的前置插件（为了后面的拓扑排序做准备）。

class MultiPlugin : Plugin<Project> {

    override fun apply(project: Project) {
        // 菜虾版本byteX beta版本
        val providers = ServiceLoader.load(PluginProvider::class.java).toList()
        providers.forEach {
          // 将子插件注册到合并插件上
            project.plugins.apply(it.getPlugin())
        }
    }
}
复制代码

上面是我之前写的beta版本，这个就是ServiceLoader的最简单的使用了。

如何实现一个子插件呢

上面我们已经定义好了接口，让各位看看我怎么写一个子插件的。

@AutoService(value = [PluginProvider::class])
class AutoTrackPluginProvider : PluginProvider {

    override fun getPlugin(): Class<out Plugin> {
        return AutoTrackPlugin::class.java
    }

    override fun dependOn(): List {
        return arrayListOf().apply {
            add("com.kronos.plugin.thread.ThreadHookProvider")
        }
    }

}
复制代码

这里为了保证子插件之间没有形成循环依赖，所以是通过className的形式，声明依赖关系的。举个例子，当前插件就要依赖于ThreadHookProvider。而getPlugin方法因为返回的就是一个Plugin的子类，所以也就是当前的plugin可以单独存在。

这样我从我个人使用上来说，因为插件是分离而且都能单独存在的，所以就可以直接使用了。

有向无环图

你写的plugin多了，其中就会出现好几个插件之间也存在了依赖关系，前置任务要先被执行，然后才能执行后面的任务。而Transform的本质其实也是一个Task，所以它的依赖关系就会非常难搞。

他们之间的关系很有可能就和下面这张图一样，这种数据结构我们叫他Graph。

在计算机科学中，一个图就是一些顶点的集合，这些顶点通过一系列边结对（连接）。顶点用圆圈表示，边就是这些圆圈之间的连线。顶点之间通过边连接。

而在我们的逮虾户X中，正常会出现的就是一个单向图（DAG），划重点，面试的时候可以吹牛的。一般有几种场景会使用到这个东西。第一就是gradle编译的时候，因为Module之间有依赖关系，所以就需要搞清楚他们的先后执行顺序，第二就是可以被应用到启动优化中，因为初始化的时候也会有很多这种初始化依赖关系的，举个例子jetpack组件中的starup就是基于拓扑排序的。还有就是workManger也有对这个的使用。

而这次逮虾户X也要使用到这个技术栈了，这里我参考了我们大佬在BRouter内使用的CachingDirectedGraphWalker，这个就是gradle源代码内解决Task的拓扑排序的类。

fun analyze(): Set {

       val modules = ConcurrentHashMap()


       val walker = CachingDirectedGraphWalker(false, object : DirectedGraph {
           override fun getNodeValues(node: ModuleNode, values: MutableCollection<in ModuleNode>, connectedNodes: MutableCollection<in ModuleNode>) {
               values.add(node)
               node.taskDependencies.forEach { name ->
                   modules[name]?.let {
                       connectedNodes += ModuleNode(it.moduleName, it.taskDependencies)
                   } ?: if (!allowMiss) error("Task(${name}) that $node dependsOn does not exists.")
               }
           }
       })

       libs.parallelStream().forEach {
           val nodes = arrayListOf()
           modules.put(it.moduleName, it)?.let {
               error("Duplicated module: ${it.moduleName}")
           }
           nodes += ModuleNode(it.moduleName, it.taskDependencies)

           synchronized(walker) {
               walker.add(nodes)
           }
       }
       return walker.findValues()
   }
复制代码

这部分就是我拿来计算其中的拓扑排序相关的。CachingDirectedGraphWalker其中定义的DirectedGraph接口呢，是让我们可以自己定义当前Node节点的连通关系的，通过这个connectedNodes添加当前节点的连通，我们就可以在最后的findValues(),方法直接返回当前有向无环图的拓扑排序了。

class MultiPlugin : Plugin<Project> {

    override fun apply(project: Project) {
        // 菜虾版本byteX beta版本
        val providers = ServiceLoader.load(PluginProvider::class.java).toList()
        val graph = mutableListOf()
        val map = hashMapOf()

        providers.forEach {
            val list = it.dependOn()
            val className = it.javaClass.name
            val meta = ModuleNode(className, list)
            graph.add(meta)
            map[className] = it
        }
        Log.info("after sort:$graph")
        val analyzer = Analyzer(graph, true)
        val graphNodes = analyzer.analyze()
        Log.info("graphNode:$graphNodes")
        graphNodes.forEach {
            map[it.moduleName]?.apply {
                project.plugins.apply(getPlugin())
            }
        }

    }
}
复制代码

这个地方由于我使用的是Node，而不是原始的Plugin，所以我在完成拓扑排序之后要重新获取到PluginProvider对象，进行一次代码调用操作。