开源库能否对依赖多版本共存做下兼容

[ximencx]

修改方式： appcompat 库版本号后面写个 +，或者 依赖方式改为compileOnly 比如 zixinglite库 及依赖对应的 viewfind 和 scan 库

[jenly1314]

修改方式： appcompat 库版本号后面写个 +，或者 依赖方式改为compileOnly 比如 zixinglite库 及依赖对应的 viewfind 和 scan 库

• 你的这个想法我很早之前就考虑过了，记得2.3.0以前的版本是用的compileOnly；后续版本特意改用的：implementation ;
• 至于版本号带+号的这种自动获取版本最新依赖的偷懒写法，你可以用在application模块，但不建议在library中使用，因为其存在版本不兼容的隐患。

[ximencx]

修改方式： appcompat 库版本号后面写个 +，或者 依赖方式改为compileOnly 比如 zixinglite库 及依赖对应的 viewfind 和 scan 库

• 你的这个想法我很早之前就考虑过了，记得2.3.0以前的版本是用的compileOnly；后续版本特意改用的：implementation ;
• 至于版本号带+号的这种自动获取版本最新依赖的偷懒写法，你可以用在application模块，但不建议在library中使用，因为其存在版本不兼容的隐患。

首先不兼容的概率很小，不兼容主要体现在 androidsdk 版本，而不是依赖库，所以第二条理论存在实际概率很小。 但是造成的多依赖共存确实会加大安装包体积，主流库一般采用的都是compileOnly加低版本，还是建议可以改一下，实在不行就自己编译本地 aar 包了

[jenly1314]

修改方式： appcompat 库版本号后面写个 +，或者 依赖方式改为compileOnly 比如 zixinglite库 及依赖对应的 viewfind 和 scan 库

• 你的这个想法我很早之前就考虑过了，记得2.3.0以前的版本是用的compileOnly；后续版本特意改用的：implementation ;
• 至于版本号带+号的这种自动获取版本最新依赖的偷懒写法，你可以用在application模块，但不建议在library中使用，因为其存在版本不兼容的隐患。

首先不兼容的概率很小，不兼容主要体现在 androidsdk 版本，而不是依赖库，所以第二条理论存在实际概率很小。 但是造成的多依赖共存确实会加大安装包体积，主流库一般采用的都是compileOnly加低版本，还是建议可以改一下，实在不行就自己编译本地 aar 包了

• gradle在同步拉取依赖时，会自动分析处理相同依赖不同版本的的兼容性问题，优先以app的依赖版本为准；
• 在使用implementation 时，是否造成多依赖得分情况来看的，主要分两种； 这里就拿appcompat 举例好了：
  1. 当app依赖的appcompat 版本大于等于第三库依赖的appcompat 版本时，会以app依赖的appcompat 版本为准，不会存在多个不同版本的依赖；
  2. 当app依赖的appcompat版本小于第三方依赖的appcompat 版本时，此时会存在多个不同版本的依赖；
• 我特意去看了下 ZXingLite 依赖的appcompat版本是v1.1.0，这是最低要求，只要app依赖的appcompat版本比这个高就行。