Android组件工程怎么优雅的在宿主工程源码调试，如何试出一个Android开发者真正的水平

最新推荐文章于 2024-07-10 19:25:11 发布

m0_60707579

最新推荐文章于 2024-07-10 19:25:11 发布

阅读量566

点赞数 7

分类专栏： 2024年程序员学习文章标签： android

本文链接：https://blog.csdn.net/m0_60707579/article/details/136965477

版权

2024年程序员学习专栏收录该内容

288 篇文章 0 订阅

订阅专栏

Log.e(“xwy–>”, “MyLibrary.className:${MyLibrary.className}”)

Log.e(“xwy–>”, “MyLibrary.commonClassName:${MyLibrary.commonClassName}”)

}

在app工程中添加对mylibrary的依赖

dependencies {

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

…

}

运行结果

2021-10-16 13:53:11.019 29302-29302/com.example.testactivitytask E/xwy–>: MyLibrary.className:MyLibrary.java

2021-10-16 13:53:11.019 29302-29302/com.example.testactivitytask E/xwy–>: MyLibrary.commonClassName:CommonLibrary.java

一切正常

调试模式场景

在app工程中添加对commonlibrary工程的源码依赖

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

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

弊端

配置文件修改侵入性高，需要修改依赖配置
如果有很多个业务组件都依赖了该基础组件，那么每一个业务组件都需要配置排除该基础组件的依赖

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.

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

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

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