怎么调试arouter 源码
arouter的代码 首要分为 3个部分，一个是根底的arouter-api包， 然后是注解处理器arouter-compile包 最终是arouter-register 这个包， 简略概述一下 这3个模块的详细效果吧
arouter-api： 99%的人使用arouter代码 都是直接用这个包下面的api，大部分用下注解就能够了 arouter-compiler： 这儿是注解处理器，现在arouter代码 依旧是只能支撑kapt，还不支撑ksp，有兴趣的能够自己弄一个moudle 做一下ksp的支撑
arouter-regsiter： 在项目中 他的project名是 arouter-gradle-plugin ，这个包里边的代码首要效果便是在编译期间 对字节码进行插桩， 效果便是生成arouter的路由表，这个是最要害的一步，假如你不使用这个register的插桩技能， arouter也能运转，只不过此刻arouter 需求在应用首次启动的时分 扫描dex文件 去生成路由表，大约耗时在1s左右
搞清楚arouter的机制 咱们就要想办法调试代码了， 最简略的调试办法便是 将咱们修正后的arouter 代码发布到本地mavenLocal上， 然后让项目引用咱们修正后的jar包就能够了。
能够打开as的gradle task 面板，找到installLocal 这个任务 履行即可，版别号和maven名称的修正在各个子module的 gradle.propertis 中
androidx 的支撑
考虑到现在support实在是太老，而且 将arouter代码 改成androidx以后，接入arouter的业务方能够少一些 Jetifier的过程，对编译时间是有正向效果的，所以趁着这个时机，咱们首要能够将arouter的代码 全体改成 支撑androidx的
榜首步 当然是在as工程中右键直接对项目进行androidx的转换了，这一步 不过多叙述了，咱们都会
第二步， 已然咱们现在是支撑androidx，那么显然 arouter-compiler的包 是需求修正的，为什么？ 因为这个注解处理器 曾经处理的是support包啊，现在你要支撑androidx 是不是 要改一下？
这一步 其实也不难了，略微看下代码 就能够找到 Consts这个类中的常量，咱们修正一下从support包 改成 androidx 即可
别的便是不要忘记了 对arouter-api的build文件修正，在曾经arouter的代码中，对api这个module 对compiler的依靠是 写的1.5.2的maven 长途库房依靠， 现在咱们修正了代码以后 天然不能用这个依靠了， 改成咱们本地工程依靠即可，这一步很重要，否则你api用的是曾经的support，注解处理器处理成androidx的 会报许多奇怪的错
第三步 注解处理器支撑androix以后，咱们的asm 字节码生成部分 也要跟从修正了，其实和compiler的修正比较类似，便是支撑下androidx的包即可
基本上改完这三步，你的arouter就能完美支撑androix了
agp 7.3
首要要阐明的是 自身agp7.3.0的代码就有bug，因为agp7.3.0 默许带着的r8 处理器对 阿里的 fastjson 处理有bug 详细表现在这个类： com.alibaba.fastjson.serializer.ASMSerializerFactory
有兴趣的能够看下issue
这儿不得不吐槽，r8的bug 是真得多，咱们晋级agp以及 kotlin版别的时分一定要小心，动辄编译失利，或者编译成功 运转失利的。
为了防止咱们在适配agp7.3的时分 引发一些不必要的毛病 咱们能够 将agp版别从7.3.0 改成7.3.1 即可。
然后咱们看下 arouter 究竟是因为什么原因导致的 在agp>7.3.0 运转失利的
首要咱们能够看下报错信息：
这儿很显着的 能够看出来 是咱们的transfrom 出现了问题， 再重新编译一下，加入–stacktrace 命令看下详细是哪里出的错？
看这个仓库 ，很显着是asm的api报了个错，这儿再细心想想看，asm的api 报错 只要两种或许，榜首咱们asm的使用方式不对，但想一想 之前agp7.3 以下都没报错，那这儿还报错，只或许是是别的一个原因：
asm读取的文件发生了错误，有了这个思路就简略多了，咱们简略对比一下，在agp7.2 和agp 7.3 版别中 读取的文件在哪里发生了改变
咱们能够在读取的地方 加一下日志，然后对比一下改变：
先看720 运转正常的版别：
再看730 报错的版别：
这现已能看出来显着的区别了，720版别中 读取jar文件 中的文件时，咱们只能读取到.class 文件 而730中 咱们 还读取到了 文件夹的途径 这样显着就不对了，拿文件夹途径去给asm读取 肯定会报错啊。
找到问题原因以后，修正起来就很容易了， 无非便是在asm读取文件的地方判断一下， 假如不是.class 结尾的 那就不要去读取修正他了
修正点如下：
arouter 还有什么需求适配的
经过上面一系列的修正，咱们现已能够将arouter 在7.3.0上完美运转了， 那后续其实arouter还是有持续修正的必要，例如 现在arouter 仅支撑kapt 而不支撑ksp，这个就有点尴尬，因为ksp 的运转速度 远高于kapt，且现在jetpack的 组件现已悉数支撑ksp了，假如这儿arouter 还不支撑ksp，全体编译速度还是会有不少影响，
所以ksp 支撑至关重要
别的便是transfrom的适配支撑，现在agp 版别现已到了7.3.1 咱们在build的时分 会发现一个告警：
API ‘android.registerTransform’ is obsolete. It will be removed in version 8.0 of the Android Gradle plugin.
也便是说这个API 在 8.0的时分 会被删掉，到时分 arouter 又会报错了，所以这个api也要尽早适配
能够重视下 魔改arouter 这个项目，现在现已适配了7.3.0，ksp以及transfrom 的适配也在方案中
