1、为什么要分析依赖层级
在组件化模式的开发架构下，组件依赖是海量的，比如我们的壳工程下面的依赖就有上千个，但他们之间的引用关系是不知道的，在业务开发过程中，对于其他业务组件的调用，我们约定以 api 方式对外提供能力，以便实现组件的迭代与升级。 但总会出现一些不合规的情况，某些业务组件直接依赖了其他业务的实现组件来触发能力，在壳工程下，由于是全依赖编译，这类问题是无法发现的，但一到业务组件新需求开发时，一些实现模块的类与方法早在上个版本就删除了，导致调用的地方就会出现类、方法等找不到的问题。
2、分析依赖层级带来的好处
分析依赖层级可以提前检查出哪些组件有不合规的引用情况，并且，在整个层级上可以看到哪块业务组件使用的频率高，哪些组件在调用自己的业务组件，以便在改造自己业务组件时提前预估影响面
3、如何分析依赖层级
- 方案一：通过依赖 pom 分析
在业务开发过程中， 我们会将需要的子依赖添加到 dependencies 中，在发布组件时，可以将子依赖也打入 pom，这时，就可以通过分析组件 pom 来拿到依赖关系。
缺点:
pom 虽然可以拿到依赖关系，但他并不是很准确，比如在 dependencies 加入了依赖，代码里并没引用该依赖的代码，但依然会被打入 pom，并且，如果大家的 pom 中都有业务子依赖的话，就会造成各种版本混乱，甚至会出现覆盖掉壳工程的 release 组件版本，出现不可预知的错误，一般我们组件的 pom 都不带上子依赖，以壳工程的组件版本为准。
- 方案二：通过字节码分析
通过字节码分析组件的 class 文件引用情况，如果有引导到外部的类、字段、方法等，就记录他们之间的依赖关系。 该方案的优点通过字节码分析出来的引用是真实引用。
4、字节码分析效果图
以下是通过字节码插件分析 group 为 androidx.activity 依赖的引用关系：
5、组件引用边界处理
在上面我们有提到业务组件依赖了其他业务的实现模块，这种能不能在业务开发阶段就发现呢？组件是无状态的，又怎么知道他是实现模块呢？ 其实，我们可以通过在 META-INF 添加一个以组件 group 命名的文件，里面标明了组件是否是对外导出，效果如下：
然后我们在 upload 打包组件插件中检索所有的子依赖，如果 exported 为 false 的话就会打包失败并提醒。
总结：
后面章节会讲解插件分析实现的原理，并且能自动生成 plantUML 文件