分析概览

分析时机

时机关注点工具示例
设计态架构设计UML, Feakin
创建态代码规范内建、规范执行机制、分层规范等应用脚手架
开发态代码规范CheckStyle 的 Intellij IDEA插件
测试态代码规范、分层架构、API 规范等ArchUnit
集成态质量门禁Sonarqube
运行态服务依赖Skywalking

诸如于:

  • 开发态
    • 静态代码分析 (编译前):对源码进行语法、控制流行等的分析,从而实现对代码的依赖分析、静态检查、自动化重构等。
    • 基于构建工具分析 (编译时):通过编写 Gradle 插件/IDE 插件、执行特定的 task,分析各个模块间的依赖关系等。
    • 中间表示分析 (编译后): 对编译过程或者编译后产生的中间表示(IR)分析,如字节码(bytecode)、smali 等。
  • 运行态
    • 运行时分析 (运行时):对运行时的数据进行分析,如 JVM 内存、线程、GC 等。

静态代码分析工具对比

工具精确度开发难度跨语言成本新语言成本自动化重构主要挑战
语言编译器完美-Yes部分编译器不提供 AST 接口
Antlr极高Yes学习成本,添加对于框架的支持成本高
CtagsYes同上
Tree-sitterYes同上
DoxygenNo不准确
CodeQuery极高Yes添加对于框架的支持成本高

Android 不同依赖方式对比

 静态代码分析基于构建工具分析中间表示分析
适用场景代码分析、架构分析、重构工具等模块间依赖代码依赖分析、编译优化
精确度中。诸如注解需要定制高。编译过程依赖于依赖解析高。
开发难度中。已有的资源比较多中。不同语言需要重新学习高。相关学习资料少
方式源码分析过程产出物和编译时 API过程和结果产出物
工具示例Sonarqube、FindbugsAndroid StudioProguard/R8、Baksmali
主要问题分析结果的准确性依赖于框架的支持、语言特性分析等,类似于 IDE。想实现 100% 的准确性不太可能,适用度高,成本相对低。依赖于 Gradle 的版本,需要考虑版本兼容性问题。官方文档较少,需要结合 ADT 中的 Gradle 源码。由于过程和结果产出物,已经是优化的结果,想要 100% 复原是不可能的。