直播带货app源码开发中存在多种冲突，比如依赖，三方aar,动态库等等

首先是直播带货app源码最常见的依赖冲突:

android {
    configurations.all {
        resolutionStrategy {
            failOnVersionConflict()
        }
    }
}

当开启failOnVersionConflict在编译时就会打印出存在的冲突依赖，并停止，比如直播带货app源码此处引入有冲突的glide依赖

implementation "com.github.bumptech.glide:glide:4.11.0"
implementation 'com.jph.takephoto:takephoto_library:4.0.3'

可以看见日志窗口提示，存在glide的不同版本在3.6-4.11之间。但是实际直播带货app源码中这一步只知道发生了冲突，缺无法清除知道是哪一个依赖里的glide冲突了。这时候可以通过gradle打印依赖关系树来查看(注意执行时需要将failOnVersionConflict注释，并重新sync):

#gradlew 模块名:dependencies
gradlew app:dependencies

我们在日志输出中搜索glide可以看到确实是takephoto下的依赖结构，直播带货app源码确实出现了glide的冲突，他里面的版本是3.6.0，而我们自己引入的依赖版本是4.11.0

接下来直播带货app源码可以通过exclude单独去排除冲突的依赖，或者全局强制指定依赖版本:

android {
    configurations.all {
        resolutionStrategy {
            force 'com.github.bumptech.glide:glide:4.11.0'
            //failOnVersionConflict()
        }
    }
}

其次有些冲突是aar引入导致的

举例某些aar可能也使用了glide，在glide4.0会要求本地实现一个AppGlideModule,但是三方aar中也实现了一个，这时候直播带货app源码只能去裁剪aar中的修改

首先解压aar文件:

unzip xxx.aar -d aarfile

接着继续解压classes.jar

cd aarfile
unzip classes.jar -d  classfile

接下来替换或者删减完classfile里的需要操作的class文件后，直播带货app源码重新将classfile打包回classes.jar

#注意斜杠后面加空格与.
jar cvf newClasses.jar -C classfile/ .

然后删掉之前的classes.jar,将新生成的重命名为classes.jar 接着再将所有文件重新打包成新的aar

jar cvf newAAR.aar -C aarfile/ .

将生成的aar重命名回去替换进直播带货app源码既可

最后就是出现so冲突:

通过pickFirst指定优先使用本地so文件既可

android {
    packagingOptions {
        pickFirst "lib/armeabi-v7a/libavcodec.so"
    }
    
 }

声明：本文由云豹科技转发自土豆泥加盐博客，如有侵权请联系作者删除

ITPub博客

解决直播带货app源码中存在的的依赖冲突

最新文章