13.从架构设计角度分析AAC源码-Room源码解析第2篇：RoomCompilerProcessing源码解析

前言

有人说细节决定成败，或者说别人注重的是结果，我们在意的是过程，roomCompilerProcessing源码读起来感觉好难哦，尤其细节处！！！

下面三浅一深，咳咳咳…由浅入深讲解roomCompilerProcessing源码。

下面每个部分，自己认真写，读者认真看。个人建议，可以在深入一点：在理解大框架的基础上，不要忽略细节部分（提醒自己和读者），否则自己想写出高逼格代码照样很难！！！

APT、KAPT和KSP的理解

简介

1. apt：Annotation Processing Tool

• 需要apply相应的android-apt插件，比如apply plugin: ‘com.neenbedankt.android-apt’。android gradle插件版本2.2以下使用，2.2发版时宣布不再维护。只支持 javac编译方式。

2. annotationProcessor：已经取代apt

• 无需apply android-apt插件。android gradle插件版本2.2及以上使用。同时支持javac和jack编译方式；

3. kapt：Kotlin Annotation Processing Tool

• kotlin注解处理工具。因kotlin-kapt不是android gradle内置插件，需要额外apply plugin: ‘kotlin-kapt’

• 和annotationProcesor的区别是，kapt处理kotlin文件，当然如果是kotlin或java混合，那么也是必须使用kapt处理的。速度上交apt(或annotationProcessor)肯定要慢的，因为首先会将kotlin解析成Java代码，再通过apt处理；

4. ksp:Kotlin Symbol Processing

• 在进行Android利用开发时Kotlin 的编译速度慢，而KAPT 便是拖慢编译的首恶之一。Android的很多库都会应用注解简化模板代码，著名的有 Room、Dagger 等，而默认状况下Kotlin 应用的是 KAPT 来解决注解的。KAPT没有专门的注解处理器，须要借助APT实现的，因而须要先生成 APT 可解析的 stub (Java代码)，这拖慢了 Kotlin 的整体编译速度。

• KSP 正是在这个背景下诞生的，它基于 Kotlin Compiler Plugin（简称KCP） 实现，不须要生成额定的 java代码，编译速度是 KAPT 的 2 倍以上。

以上文字多数抄袭，融入了个人观点，为了让我们简单了解一下各个编译的区别。

demo

AbstractProcessor

kapt和annotationProcessor的使用完全一致。

@AutoService(Processor.class) //自动生成注解处理器路径文件
public class BindingProcessor extends AbstractProcessor {

	
	init(ProcessingEnvironment processingEnv):初始化操作

	getSupportedSourceVersion()：设置版本

	getSupportedAnnotationTypes()：设置支持的注解

	process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv)：主要的注解元素解析方法
 
}

没有AbstractProcessor基础的，可参考Java学习之注解（五）Android循序渐进实现高逼格自定义ViewBinder。

SymbolProcessor

interface SymbolProcessor {
   	//处理节点
    fun process(resolver: Resolver): List<KSAnnotated>

	//处理结束
    fun finish() {}