网站开发沟通,东莞网页制作网站,网站色彩搭配,国内app开发商背景 近年来#xff0c;随着手机业务的快速发展#xff0c;为满足手机端用户诉求和业务功能的迅速增长#xff0c;移动端的技术架构也从单一的大工程应用#xff0c;逐步向模块化、组件化方向发展。以高德地图为例#xff0c;Android 端的代码已突破百万行级别#xff0…背景 近年来随着手机业务的快速发展为满足手机端用户诉求和业务功能的迅速增长移动端的技术架构也从单一的大工程应用逐步向模块化、组件化方向发展。以高德地图为例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 字节码的工具最常用的包括 JavassitASMCGLib。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 的实例 b 6: b.methodB(); // 调用了 b 的 methodB 方法 7: } 8: }第1步初始化环境加载字节码 A.class注册语句分析器。 // 初始化 ClassPool将字节码文件目录注册到 Pool 中。 ClassPool pool ClassPool.getDefault(); pool.insertClassPath(class文件所在目录) // 加载类A CtClass cls pool.get(com.account.A); // 注册表达式分析器到类A MyExprEditor 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 的解析它还支持解析 newnew ArrayConstructorCallFieldAccessInstanceOf强制类型转换try-catch 语句。 解析完 Class A我们得到了 A 对 B 的依赖信息 Class1Class2Exprmethod1method2lineNocom.account.Acom.account.BNewExprmethodA 5com.account.Acom.account.BmethodCallmethodAmethodB6 ------------------- ------------------------------------------------------- 简单解释如下 类 com.account.A 的第5行(methodA方法内)调用了 com.account.B 的构造函数 类 com.account.A 的第6行(methodA方法内)调用了 com.account.B 的 methodB 函数 这便是“类和类之间方法级”的依赖数据。结合第1步得到的“模块和类”的对应关系最终我们便获得了“模块间方法级的依赖数据”。 基于这些基础数据我们还可以自定义依赖检测规则、生成全局的模块依赖关系图等本文就不展开了。 小结 本文主要介绍了模块依赖分析在研发过程中的重要性分析了 Android 常见的依赖分析方案从 Gradle 依赖树分析 Import 扫描使用 IDE 分析到最后的字节码解析方案逐步递进。越是接近源头的解法才是越根本的解法。 原文链接 本文为云栖社区原创内容未经允许不得转载。