Android：如何开发无依赖冲突的三方库，无需宿主手动排除依赖

你提到的修改依赖包名/设置别名的方案完全可行，这也是业内Android三方库规避依赖冲突的常用手段，除此之外还有另外两种不需要宿主手动排除依赖的解决方案，具体如下：

方案1：依赖重打包（即改包名/别名方案） #

这个方案的核心是把你库内依赖的X 1.0版本的全量代码做包名替换，和宿主使用的X版本做完全隔离，不会出现类加载冲突，也不需要宿主做任何额外配置。

• 操作方式：可以通过shadow Gradle插件的relocate配置自动化完成，不需要手动改代码，示例配置如下：

// 你的库模块的build.gradle配置
plugins {
    id 'com.github.johnrengelman.shadow' version '7.1.2'
}

shadowJar {
    // 把X的原包名替换为你库专属的阴影包名
    relocate 'com.original.x', 'com.your.library.shadow.x'
    // 可以配置要排除的不需要打包的类，控制包体积
    exclude 'META-INF/**'
}

• 注意事项：如果X是带资源的AAR类型依赖，需要额外处理资源重命名，避免和宿主的资源ID冲突，可以配合AAPT2的资源命名空间功能实现。
• 优缺点：适配所有场景，不需要宿主做任何操作，唯一缺点是会增加你的库的包体积，相当于把X 1.0的代码全量打进了你的库产物。

方案2：将依赖X声明为compileOnly #

如果你的库用到的X 1.0的所有API在X 0.5版本中都存在，没有调用高版本独有API的情况，可以直接把X的依赖声明改为compileOnly：

• 原理：compileOnly类型的依赖只会参与你库的编译流程，不会被打包进最终的AAR产物，运行时会直接使用宿主提供的X版本，不会出现版本冲突。
• 配置示例：

dependencies {
    // 把原来的implementation改为compileOnly
    compileOnly 'com.xxx:x:1.0'
}

• 优缺点：实现成本极低，不会增加包体积，缺点是仅适用于高低版本API完全兼容的场景，如果你的库用到了1.0独有API，宿主使用0.5版本时会出现运行时崩溃。

方案3：配套轻量Gradle插件自动处理排除 #

如果你不想做重打包，也无法保证API兼容性，可以开发一个极简的Gradle插件随你的库一起提供给宿主接入：

• 原理：插件会在宿主的构建阶段自动执行你的库的X依赖排除逻辑，不需要宿主手动编写exclude规则，对宿主来说接入成本和普通依赖几乎没有区别。
• 适用场景：你的库的接入方数量较多，不想给每个接入方增加手动配置的成本。

注意：如果你的库用到了X 1.0的独有API，且你无法接受重打包带来的包体积增加，就只能在接入文档里明确告知宿主需要做强制版本指定，不需要做排除操作，直接在宿主的dependencies里锁定X的版本即可，Gradle默认会采用最高版本的依赖，宿主指定0.5版本后会覆盖你库传递的1.0版本。

内容的提问来源于stack exchange，提问作者Vamsi Calpakkam