写点什么

字节码技术在模块依赖分析中的应用

  • 2020-03-04
  • 本文字数:3164 字

    阅读完需:约 10 分钟

字节码技术在模块依赖分析中的应用

本文介绍 Java 字节码技术在 Android 模块依赖分析中的应用。文中的“字节码”特指“Java 字节码”。

背景

近年来,随着手机业务的快速发展,为满足手机端用户诉求和业务功能的迅速增长,移动端的技术架构也从单一的大工程应用,逐步向模块化、组件化方向发展。以高德地图为例,Android 端的代码已突破百万行级别,超过 100 个模块参与最终构建。


试想一下,如果没有一套标准的依赖检测和监控工具,用不了多久,模块的依赖关系就可能会乱成一锅粥。


从模块 Owner 的角度看,为什么依赖分析这么重要?


  1. 作为模块 Owner,我首先想知道“谁依赖了我?依赖了哪些接口”。唯有如此才能评估本模块改动的影响范围,以及暴露的接口的合理性。

  2. 我还想知道“我依赖了谁?调用了哪些外部接口”,对所需要的外部能力做到心中有数。


从全局视角看,一个健康的依赖结构,要防止“下层模块”直接依赖“上层模块”,更要杜绝循环依赖。通过分析全局的依赖关系,可以快速定位不合理的依赖,提前暴露业务问题。


因此,依赖分析是研发过程中非常重要的一环。

常见的依赖分析方式

提到 Android 依赖分析,首先浮现在脑海中的可能是以下这些方案:


  • 分析 Gradle 依赖树。

  • 扫描代码中的 import 声明。

  • 使用 Android Studio 自带的分析功能。


我们逐个来分析这几个方案:


1. Gradle 依赖树


使用 ./gradlew :<module>:dependencies --configuration releaseCompileClasspath -q 命令,很容易就可以得到模块的依赖树,如图:



不难发现,这种方式有两个问题:


  • 声明即依赖,即使代码中没有使用的库,也会输出到结果中。

  • 只能分析到模块级别,无法精确到方法级别。


2. 扫描 import 声明


扫描 Java 文件中的 import 语句,可以得到文件(类)之间的调用关系。


因为模块与文件(类)的对应关系非常容易得到(扫描目录)。所以,得到了文件(类)之间的依赖关系,即是得到了模块之间文件(类)级别的依赖关系。


这个方案相比 Gradle 依赖扫描提升了结果维度,可以分析到文件(类)级别。但是它也存在一些缺点:


  • 无法处理 import * 的情况。

  • 扫描“有 import 但未使用对应类”的场景效率太低(需要做源码字符串查找)。


3. 使用 IDE 自带的分析功能


触发 Android Studio 菜单 「Analyze」 -> 「Analyze Dependencies」,可以得到模块间方法级别的依赖关系数据。如图:



Android Studio 能准确分析到模块之间“方法级别”的引用关系,支持在 IDE 中跳转查看,也能扫描到对 Android SDK 的引用。


这个方案比前面两个都优秀,主要是准确。但是它也有几个问题:


  • 耗时较长:全面分析 AMap 全源码,大约需要 10 分钟。

  • 分析结果无法为第三方复用,无法生成可视化的依赖关系图。

  • 分析正向依赖和逆向依赖,需要扫描两次。


总结一下上述三种方案:Gralde 依赖基于工程配置,粒度太粗且结果不准。“Import 扫描方案”能拿到文件级别依赖但数据不全。IDE 扫描虽然结果精准,但是数据复用困难,不便于工程化。

为什么要使用字节码来分析?


参考 Android 构建流程图,所有的 Java 源代码和 aapt 生成的 R.java 文件,都会被编译成 .class 文件,再被编译为 dex 文件,最终通过 apkbuilder 生成到 apk 文件中。图中的 .class 文件即是我们所说的 Java 字节码,它是对 Java 源码的二进制转义。


在 Android 端,常见的字节码应用场景包括:


  • 字节码插桩:用于实现对 UI 、内存、网络等模块的性能监控。

  • 修改 jar 包:针对无源码的库,通过编辑字节码来实现一些简单的逻辑修改。


回到本文的主题,为什么要分析字节码,而不是 Java 代码或者 dex 文件?


不使用 Java 代码是因为有些库以 jar 或者 aar 的方式提供,我们获取不到源码。不使用 dex 文件是因为它没有好用的语法分析工具。所以解析字节码几乎是我们唯一的选择。

如何使用字节码分析依赖关系?

要得到模块之间的依赖关系,其实就是要得到“模块间类与类”之间的依赖关系。而要确定类之间的关系,分析类字节码的语句即可。


1. 在什么时机来分析?


了解 Android 构建流程的同学,应该对 transform 这个任务不陌生。它是 Android Gradle 插件提供的一个字节码 Hook 入口。


在 transform 这个任务中,所有的字节码文件(包括三方库) 以 Input 的格式输入。


以 JarInput 为例,分析其 file 字段,可得到模块的名称。解析 file 文件,即可得到此模块所有的字节码文件。



有了模块名称和对应路径下的 class 文件,就建立了模块与类的对应关系,这是我们拿到的第一个关键数据。


2. 使用什么工具分析?


解析 Java 字节码的工具,最常用的包括 Javassit,ASM,CGLib。ASM 是一个轻量级的类库,性能较好,但需要直接操作 JVM 指令。CGLib 是对 ASM 的封装,提供了更高级的接口。


相比而言,Javassist 要简单的多,它基于 Java 的 API ,无需操作 JVM 指令,但其性能要差一些(因为 Javassit 增加了一层抽象)。在工程原型阶段,为了快速验证结果,我们优先选择了 Javassit 。


3. 具体方案是怎样的?


先看一个简单的示例,如何分析下面这段代码的调用关系:


1: package com.account;2: import com.account.B;3: public class A {4:     void methodA() {5:         B b = new B(); // 初始化了 Class B 的实例 b6:         b.methodB();   // 调用了 b 的 methodB 方法7:     }8: }
复制代码


第 1 步:初始化环境,加载字节码 A.class,注册语句分析器。


// 初始化 ClassPool,将字节码文件目录注册到 Pool 中。ClassPool pool = ClassPool.getDefault();pool.insertClassPath('<class文件所在目录>')// 加载类ACtClass cls = pool.get("com.account.A");// 注册表达式分析器到类AMyExprEditor editor = new MyExprEditor(ctCls)ctCls.instrument(editor)
复制代码


第 2 步:自定义表达式解析器,分析类 A(以解析语句调用为例)。


class MyExprEditor extends ExprEditor {    @Override    void edit(MethodCall m) {        // 语句所在类的名称        def clsAName = ctCls.name        // 语句在哪个方法被调用        def where = m.where().methodInfo.getName()        // 语句在哪一行被调用        def line = m.lineNumber        // 被调用类的名称        def clsBName = m.className        // 被调用的方法        def methodBName = m.methodName    }    // 省略其它解析函数 ...}
复制代码


ExprEditor 的 edit(MethodCall m) 回调能拦截 Class A 中所有的方法调用(MethodCall)。


除了本例中对 MethodCall 的解析,它还支持解析 new,new Array,ConstructorCall,FieldAccess,InstanceOf,强制类型转换,try-catch 语句。


解析完 Class A,我们得到了 A 对 B 的依赖信息 :


---------------------------------------------------------------------------| Class1        | Class2        | Expr       | method1 | method2 | lineNo || ------------- | ------------- | ---------- | ------- | ------- | ------ || com.account.A | com.account.B | NewExpr    | methodA | <init>  | 5      || com.account.A | com.account.B | methodCall | methodA | methodB | 6      |------------------- -------------------------------------------------------简单解释如下:类 com.account.A 的第5行(methodA方法内),调用了 com.account.B 的构造函数;类 com.account.A 的第6行(methodA方法内),调用了 com.account.B 的 methodB 函数;
复制代码


这便是“类和类之间方法级”的依赖数据。结合第 1 步得到的“模块和类”的对应关系,最终我们便获得了“模块间方法级的依赖数据”。


基于这些基础数据,我们还可以自定义依赖检测规则、生成全局的模块依赖关系图等,本文就不展开了。

小结

本文主要介绍了模块依赖分析在研发过程中的重要性,分析了 Android 常见的依赖分析方案,从 Gradle 依赖树分析, Import 扫描,使用 IDE 分析,到最后的字节码解析,方案逐步递进。越是接近源头的解法,才是越根本的解法。


2020-03-04 14:481496

评论

发布
暂无评论
发现更多内容

金灿灿的季节 - Apache DolphinScheduler收获5位新Committer

代立冬

在培训机构花了好几万学Java,当了程序员还常被鄙视,这是招谁惹谁了?

四猿外

Java 学习 程序员 个人成长

不懂送女朋友什么牌子的口红?没关系!Python 数据分析告诉你。

JackTian

Python 程序员 数据分析 python 爬虫 口红

MySQL死锁系列-常见加锁场景分析

程序员历小冰

MySQL

服务化架构-状态码设计要点

图南日晟

微服务 RESTful 架构设计

解决版权难题,“豪横”字体自己做

zhoo299

设计 CG

Eureka 实例注册状态保持 STARTING 的问题排查

张晓辉

spring Spring Cloud netflix

游戏夜读 | vim,vim,vim

game1night

超简单入门MyBatis,看了就会了~

程序员的时光

mybatis

Vol.8 云栖小镇游记

pyfn2030

阿里云 随笔 数字化转型

ARTS|Week 1 第一次使用LeetCode

Puran

LeetCode ARTS活动

Rust 遇上 C/C++(二):函数传参

Coding Fatty

c c++ rust 编程语言

只用CSS实现响应式Full-Width img 2种方法

寇云

CSS css3

小谈校招offer选择

dongh11

职场 职业规划 应届毕业 心态 招聘

【写作群星榜】5.22~5.28写作平台优秀作者&文章排名

InfoQ写作社区官方

写作平台 排行榜 热门活动

认识数据产品经理(四 与互联网产品经理的区别)

马踏飞机747

大数据 互联网 产品经理 职业规划

时序数据库

pydata

安装R语言编译器:

唯爱

珍藏已久的 OS 学习网站拿出来分享给大家

苹果看辽宁体育

操作系统

控制 Pod 内容器的启动顺序

张晓辉

Kubernetes

服务化构建-多维度的认识中台

图南日晟

软件工程 分层架构 架构设计

XSKY发布XMotion纳管热迁移技术,OpenStack集群迁移效率提升超10倍

XSKY星辰天合

Vol.9 Web前端发展历程及前端工程化

pyfn2030

大前端

Dataway 整合 Swagger2,让 API 管理更顺畅

哈库纳

Spring Boot DataQL Dataway Hasor

磁盘挂载

唯爱

Vol.7 聊聊我热爱的陕西省图书馆

pyfn2030

记录 生活,随想

Java 学习笔记(三)数据类型

杜朋

《中国互联网简史》系列笔记之P2P

dongh11

读书笔记

深入浅出Mysql索引的那些事儿

猿人谷

MySQL 性能优化 索引

避免争执

孙苏勇

职场 随笔杂谈

tput命令介绍

唯爱

字节码技术在模块依赖分析中的应用_文化 & 方法_高德技术_InfoQ精选文章