我用过的代码生成方式综述_有哪些生成代码的方法

这段时间，做了很多开发效率相关的事情，涉及到了不少代码生成的方法和思路，总结如下。生成代码分两部分：代码分析生成工具和代码模板

工具

按编写难度排序

live template

这个是intellij的一个简单工具，看起来就是对freemarker或者正则替换做了一些封装。代表方案当然就是内置的那些了。
创建很简单：https://www.jetbrains.org/intellij/sdk/docs/tutorials/live_templates/template_support.html
值得注意的是，可以在 Edit variables的地方指定更复杂的匹配，生成更丰富的代码。

这种方案的优点：

• 无需开发工具
• 对当前环境有一定的判断能力（edit variables）

缺点：

• 强依赖ide
• 能力太弱

Config文件

代表方案是GreenDao。
生成代码的流程是独立于App编译过程的。即有一个Java console的main方法，执行这个方法，能够根据config在指定位置生成代码。如果要将这个融入到编译过程中，需要用gradle task 在所有编译前调用jar包。
GreenDao比较巧妙的使用了Java代码作为Config文件，大大简化了代码生成工具的复杂程度。在时机生成过程中，可以使用json、xml等作为配置文件（Spring模式），与写代码区别并不大，只是免去了复杂工具的编译时间。

这种方案的优点：

• 工具编制简单
• 生成的目标代码有一定的灵活性

缺点：

• 对于现有类的理解分析能力基本为0，很难做复杂自动化生成
• 嵌入的打包流程比较生硬

Annotation Processor

这是目前最常见的方案，个人感觉ButterKnife和Android annotation可以作为代表。
生成代码的流程是Java编译内置的hook点，安全性和兼容能力非常强。Java本身提供了javax.lang.model的整套代码分析体系，能够非常好的对现有代码进行分析。然而其中的element和typemirror之间的转换、类名获取这种事情非常容易被搞晕。
整个工具编写比较简单：tutorial。但是一旦出现正向（怎么做xxx）问题，很难找到know-how的人。反向问题（bug）的调试反而非常简单，因为生成的代码都是可见且可断点的（不能修改）。
apt能做的东西，个人理解有几种：生成boilerplate代码，ButterKnife这种；以编译期生成代码减少反射，EventBus 3.0的Subscriber Index，后面我还会开源一个无反射按field名读取值的apt工具；类的合法性校验，这个是只有apt才能做的。
这种方案的优点：

• 工具编写比较简单，不需要深奥的知识
• 对于代码的理解是非常非常好的，基本可以做到最极致的类分析
• debug极其容易
• 速度比较快（如果反复apt轮数比较少的话），技术还算普及

缺点：

• javax.lang.model的文档和相关资料都很少
• 不能修改现存的类
• 必须遵守依赖和可见关系

AspectJ

这是个通用技术，虽然顶着AOP的帽子，很多时候也会被用来生成代码。Hugo是个非常好的例子，有一个通用的plugin在Android工程下使用AspectJ，而切面又非常简单，好懂。
本身文档还比较完整，只是index比较乱。具体的hook，应该是基于gradle plugin的（没细致研究过）。底层是基于ASM的，成熟没什么兼容性问题。对于现有类的分析基本靠固定的匹配机制，更多的是依赖字符串和正则，不容易分析更深层次的类行为（人家本来就是用来做切面定义的），而且对于切面来说，能够拿到的上下文信息比较受限。
对于扩展信息，多是基于不适用Android的aspectj language，比较头疼。
这种方案的优点：

• 修改现有类而非生成新类
• 相较于其他修改类的方法来说，使用更加广泛（Spring），稳定性更有保障

缺点：

• 类理解和生成代码的风格、位置、上下文都受限，主要还是适合做大规模、重复性的简单工作
• 运行时需要依赖库
• hook方法时，会生成很多类，增加了调用，运行时性能有潜在风险简单细节
• debug行号都是错的，基本就是个跪。甚至反编译都很难看懂（生成的函数都蛮混淆的）

Javassist

Javassist是改代码的工具里最接近apt的。有个实例工程可以拿来当模板。
文档有，但比较有用的仅限于官方的tutorial，文档内容丰富程度堪比javax.lang.model，完全看不懂。想要嵌入打包过程，必须自己写plugin和transform，里面的坑也不少，资料也不多。而对于类的匹配和遍历都是需要手动写，远远高于apt的复杂程度。当然，真正处理也是复杂一些。Groovy语言本身，也是一大槽点，编的时候什么都能过，运行的时候什么都挂。主要的优势在于全能修改类和无视依赖关系两项。

这种方案的优点：

• 生成的代码模板来源可以比较广，可读性好（基本就是正常Java）
• 匹配逻辑可以做的非常复杂，与apt合用的话，可以写的比较简单
• 可以完全脱离正常的依赖路径，合包的时候做transform可以任意依赖
• 反编译修改后的类，代码可读性比较好
• 是插入代码，不是给方法套proxy（较于AspectJ），性能更有保障

缺点：

• 需要手写plugin、transform、匹配等等一系列额外操作
• groovy
• debug能力未知

ASM

ASM就是究极超神方案了，直接搞bytecode。仅仅看懂了某个开源项目。也需要手写plugin和transform，和javassist的区别主要在于代码形式和对代码的遍历方式（tree visitor vs structured object）。过多的做评述。

AST

专门做代码分析的，待补充。

模板

手写

仅在极简单或没有模板可用的时候用，否则就是自作孽。

freemarker

通用技术，没有对java的优化。
优点：

• 足够灵活，输入Map输出String
• 有一个带占位符的template文件，修改简单

缺点：

• 没有对于Java语言的支持，格式化和import都比较差

JavaPoet

针对Java生成的专门库，对于import、替换有非常好的支持。
优点：

• 结构、使用方便
• import、缩进支持的非常好

缺点：

• 不太容易有template模板文件，修改大多需要通读代码