【转载】Android插件化常见冲突解决方案

文章转自：https://blog.csdn.net/xiangzhihong8/article/details/80278068

在Android组件化和插件化的过程中，经常会遇到狠多的问题，如常见的包依赖冲突，资源文件依赖冲突等问题，当然，在资源文件上面，一些组件化框架已为我们提供了一些资源文件冲突的解决方案。下面做一个简单的总结，未完待续。

1，资源冲突问题

在组件化项目中，经常会遇到多个Module模块的资源冲突问题。例如，一个简单的app包含app模块、user模块、me模块，其中app模块依赖user模块和me模块。 
 
而我们在user模块和me模块的strings.xml中都定义了greet字符串。

// user模块
<resources>
    ...
    <string name="greet">Hello!</string>
    ...
</resources>

// me模块
<resources>
    ...
    <string name="greet">Hi!</string>
    ...
</resources>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

那么，在app模块引用greet字符串就会出现资源冲突问题。解决方法也挺简单，就是给每个子模块给资源名添加前缀，具体做法是在每个子模块的build.gradle文件的android块内添加一行代码：resourcePrefix “资源名前缀”。

// me模块的build.gradle文件
...
android {

    compileSdkVersion 27
    buildToolsVersion "27.0.3"

    resourcePrefix "me_"

    ...

}
...
// user模块的build.gradle文件
...
android {

    compileSdkVersion 27
    buildToolsVersion "27.0.3"

    resourcePrefix "user_"

    ...

}
...

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

如果修改后，那么对应的资源文件也要做相应的修改。

// user模块
<resources>
    ...
    <string name="user_greet">Hello!</string>
    ...
</resources>

// me模块
<resources>
    ...
    <string name="me_greet">Hi!</string>
    ...
</resources>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

2，多个Module依赖同一个jar的解决方案

在做插件化的过程中，有如下的一个场景：环信Module和我们自己的app的Module都要用到定位sdk，如果同时引入这两个sdk的时候就会出现jar冲突问题。 
解决方案：将任意一个Module中的jar依赖为compile files(‘your jar name’)，其他需要依赖的地方改为provided files(‘your jar name’)并且删除compile fileTree(include: [‘*.jar’], dir: ‘libs)。

对于上面的场景，具体操作如下： 
1、在自己app的gradle中以compile引入如：

compile files('libs/AMap_Location_V2.4.1_20160414.jar')

• 1

2、在环信的Module的gradle中以provided的方式引入如：

provided files('libs/AMap_Location_V2.4.1_20160414.jar')

• 1

环信的gradle中不能存在compile fileTree(include: [‘*.jar’], dir: ‘libs’) 
说到这里，就得给大家普及下Android，gradle脚本依赖包的几种方式（熟悉的可以略过）。

gradle脚本依赖包的几种方式

compile 
compile是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中。

Provided 
Provided是对所有的build type以及favlors只在编译时使用，类似eclipse中的external-libs,只参与编译，不打包到最终apk。

APK 
只会打包到apk文件中，而不参与编译，所以不能再代码中直接调用jar中的类或方法，否则在编译时会报错。

Test compile 
Test compile 仅仅是针对单元测试代码的编译编译以及最终打包测试apk时有效，而对正常的debug或者release apk包不起作用。

Debug compile 
Debug compile 仅仅针对debug模式的编译和最终的debug apk打包。

Release compile 
Release compile 仅仅针对Release 模式的编译和最终的Release apk打包。

3，组件化开发中引用aar包引起的jar包

经常遇到下面的一些场景：公司项目需要引用公司内部开发的IM组件，组件以AAR包的形式进行引入，由于IM组件相当于一个完整的项目，所以用到的jar包比较多，比如fastjson、okhttp、glide。而我们自己的项目中也会存在这样一些jar，那么对于这种问题怎么解决冲突呢？ 
可以在我们的主工程中添加如下的一些过滤：

configurations {
    compile.exclude module: 'okhttp'
    compile.exclude module: 'fastjson'
    compile.exclude module: 'glide'
}

• 1
• 2
• 3
• 4
• 5

当然，如果宿主和子工程的module所依赖的jar的版本不一样也可以通过这种方式来过滤。