Android组件工程怎么优雅的在宿主工程源码调试

dependencies {

implementation project(path: ‘:commonlibrary’)

// mylibrary aar 会传递依赖 commonlibrary aar

implementation ‘com.xwy.test:mylibrary:1.0.0’

…

}

修改commonlibrary工程代码

public class CommonLibrary {

public static String className = “CommonLibrary.java–>update”;

}

运行程序，会发现修改的源码没有生效。

执行gradlew build --refresh-dependencies会显示如下的错误

Type com.example.commonlibrary.BuildConfig is defined multiple times:

/Users/xuweiyu/Work/TestActivityTask/commonlibrary/build/

.transforms/5da046d126b3df77c21768d16a3e3ca0/classes/classes.dex,

/Users/xuweiyu/Work/TestActivityTask/app/build/intermediates/external_libs_dex

/release/mergeExtDexRelease/classes.dex

解释一下这个错误，错误原因为dex文件合并的时候发现有多个com.example.commonlibrary.BuildConfig文件。

原因为我们通过aar依赖和源码依赖，引入了两个相同文件。

3. 解决问题

---

既然问题出现的原因是引入了两份相同的代码，那么我们在编译的时候去除掉aar依赖不就可以了，一个被大众所熟知的方式就是在引入mylibrary的时候去掉对commonlibrary的依赖，那么我们可以这样做， 在app工程依赖mylibrary的时候采用如下方式：

dependencies {

implementation project(path: ‘:commonlibrary’)

// mylibrary aar 会传递依赖 commonlibrary aar， 利用exclude去除依赖

implementation (‘com.xwy.test:mylibrary:1.0.0’){

transitive = true

exclude group: ‘com.xwy.test’, module: ‘commonlibrary’

}

…

}

运行结果

2021-10-16 15:16:57.194 31535-31535/com.example.testactivitytask E/xwy–>: MyLibrary.className:MyLibrary.java

2021-10-16 15:16:57.194 31535-31535/com.example.testactivitytask E/xwy–>: MyLibrary.commonClassName:CommonLibrary.java–>update

可以看到修改的代码已经生效，问题可以解决。

弊端

1. 配置文件修改侵入性高，需要修改依赖配置

2. 如果有很多个业务组件都依赖了该基础组件，那么每一个业务组件都需要配置排除该基础组件的依赖

4. 终极解决方案

---

我们可以配置全局项目替换，一个不被大众所熟知的方式。 可以进行如下配置

configurations.all {

resolutionStrategy.dependencySubstitution {

substitute module(“com.xwy.test:commonlibrary”) using project(“:commonlibrary”)

}

}

dependencies {

implementation(‘com.xwy.test:mylibrary:1.0.0’)

···

}

关于gradle项目替换的语法说明，大家可以参考官方文档

docs.gradle.org/current/use…

Using dependency substitution rules

Dependency substitution rules work similarly to dependency resolve rules. In fact, many capabilities of dependency resolve rules can be implemented with dependency substitution rules. They allow project and module dependencies to be transparently substituted with specified replacements. Unlike dependency resolve rules, dependency substitution rules allow project and module dependencies to be substituted interchangeably.

Adding a dependency substitution rule to a configuration changes the timing of when that configuration is resolved. Instead of being resolved on first use, the configuration is instead resolved when the task graph is being constructed. This can have unexpected consequences if the configuration is being further modified during task execution, or if the configuration relies on modules that are published during execution of another task.

To explain:

A Configuration can be declared as an input to any Task, and that configuration can include project dependencies when it is resolved.

If a project dependency is an input to a Task (via a configuration), then tasks to build the project artifacts must be added to the task dependencies.

In order to determine the project dependencies that are inputs to a task, Gradle needs to resolve the Configuration inputs.

Because the Gradle task graph is fixed once task execution has commenced, Gradle needs to perform this resolution prior to executing any tasks.

In the absence of dependency substitution rules, Gradle knows that an external module dependency will never transitively reference a project dependency. This makes it easy to determine the full set of project dependencies for a configuration through simple graph traversal. With this functionality, Gradle can no longer make this assumption, and must perform a full resolve in order to determine the project dependencies.

Substituting an external module dependency with a project dependency

One use case for dependency substitution is to use a locally developed version of a module in place of one that is downloaded from an external repository. This could be useful for testing a local, patched version of a dependency.

The module to be replaced can be declared with or without a version specified.

中文翻译为

使用依赖替换规则

依赖替换规则的工作方式与依赖解析规则类似。事实上，依赖解析规则的很多能力都可以通过依赖替换规则来实现。它们允许使用指定的替换透明地替换项目和模块依赖项。与依赖解析规则不同，依赖替换规则允许项目和模块依赖被互换替换。

向配置添加依赖项替换规则会更改解析该配置的时间。 不是在第一次使用时解析，而是在构建任务图时解析配置。如果在任务执行期间进一步修改配置，或者如果配置依赖于在另一个任务执行期间发布的模块，这可能会产生意想不到的后果。

解释：

一个Configuration可以声明为任何任务的输入，并且该配置可以在解析时包含项目依赖项。

如果项目依赖项是任务的输入（通过配置），则必须将构建项目工件的任务添加到任务依赖项中。

为了确定作为任务输入的项目依赖项，Gradle 需要解析Configuration输入。

因为一旦任务开始执行，Gradle 任务图就固定了，所以 Gradle 需要在执行任何任务之前执行此解析。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

学习分享

在当下这个信息共享的时代，很多资源都可以在网络上找到，只取决于你愿不愿意找或是找的方法对不对了

很多朋友不是没有资料，大多都是有几十上百个G，但是杂乱无章，不知道怎么看从哪看起，甚至是看后就忘

如果大家觉得自己在网上找的资料非常杂乱、不成体系的话，我也分享一套给大家，比较系统，我平常自己也会经常研读。

2021最新上万页的大厂面试真题

七大模块学习资料：如NDK模块开发、Android框架体系架构…

只有系统，有方向的学习，才能在段时间内迅速提高自己的技术。

这份体系学习笔记，适应人群：
**第一，**学习知识比较碎片化，没有合理的学习路线与进阶方向。
**第二，**开发几年，不知道如何进阶更进一步，比较迷茫。
**第三，**到了合适的年纪，后续不知道该如何发展，转型管理，还是加强技术研究。如果你有需要，我这里恰好有为什么，不来领取！说不定能改变你现在的状态呢！

由于文章内容比较多，篇幅不允许，部分未展示内容以截图方式展示 。如有需要获取完整的资料文档的朋友点击我的【GitHub】免费获取。

才能在段时间内迅速提高自己的技术。

这份体系学习笔记，适应人群：
**第一，**学习知识比较碎片化，没有合理的学习路线与进阶方向。
**第二，**开发几年，不知道如何进阶更进一步，比较迷茫。
**第三，**到了合适的年纪，后续不知道该如何发展，转型管理，还是加强技术研究。如果你有需要，我这里恰好有为什么，不来领取！说不定能改变你现在的状态呢！

由于文章内容比较多，篇幅不允许，部分未展示内容以截图方式展示 。如有需要获取完整的资料文档的朋友点击我的【GitHub】免费获取。