问题缘由
本文以 ybimagebrowser[1] 组件举例。
ybimagebrowser 依赖了 sdwebimage，在使用 cocoapods 集成到项目中时，可能会出现一些依赖冲突的问题，最近社区提了多个 issues 并且在 insights -> traffic -> popular content 中看到了此类问题很高的关注度，所以不得不着手解决。
严格的版本限制
一个开源组件的迭代过程中，保证上层接口的向下兼容就不错了。为了优化性能并且控制内存，ybimagebrowser 没有直接用其最上层的接口，而是单独使用了下载模块和缓存模块，sdwebimage 的迭代升级很容易导致笔者的组件兼容不了，所以之前一直是类似这样依赖的：
|
1
|
s.dependency 'sdwebimage', '~> 5.0.0' |
这样做的好处是限制足够小版本范围，降低 sdwebimage 接口变动导致组件代码错误的风险。但如果 sdwebimage 升级到 5.1.0，不管相关 api 是否变动，cocoapods 都视为依赖冲突。
其它组件依赖了不同版本的 sdwebimage
当两个组件依赖了同一个组件的不同版本，并且依赖的版本没有交集，比如：
|
1
2
|
a.dependency 'sdwebimage', '~> 4.0.0'b.dependency 'sdwebimage', '~> 5.0.0' |
那么 a 和 b 同时集成进项目会出现依赖冲突。
解决方案
使用 cocoapods 集成项目非常便捷，对于组件使用者来说，总是想在任何场景下都能轻易集成，并且能在将来享受组件的更新优化，显然前面提到的问题可能会影响集成的便捷性。
更模糊的版本限制
很多时候一个大版本的组件不会改动 api，并且对于社区流行的组件我们可以寄一定希望于其做好向下兼容，所以放宽依赖的版本限制能覆盖将来更多的版本（规则参考：podspec dependency[2]）：
|
1
|
s.dependency 'sdwebimage', '>= 5.0.0' |
为什么不干脆去掉版本限制呢？
因为 ybimagebrowser 3.x 是基于 sdwebimage 5.0.0 开发的，笔者可以明确不兼容 5.0.0 之前的版本，所以在 sdwebimage 将来迭代版本出现相关 api 不兼容之前，这个限制都是“完美”覆盖所有版本的。
避免依赖冲突的暴力方案
当有其它组件依赖了不同版本的 sdwebimage，粗暴的解决方案如下：
• 直接修改其它组件依赖的 sdwebimage 版本。
• 将 ybimagebrowser 手动导入项目，并且修改代码去适应当前的 sdwebimage 版本。
• 社区朋友一个 issue 中提到的方法：在 ~/.cocoapods/repos 目录下找到 ybimagebrowser 文件夹，更改对应版本的 podspec.json 文件里对 sdwebimage 的依赖版本。
显然，上面的几种方案不太优雅，手动导入项目难以享受组件的更新优化，修改本地 repo 信息会因为 repo 列表的更新而复位。
避免依赖冲突的优雅方案
出现依赖冲突是必须要解决的问题，其它组件依赖的版本限制可以视为不变量，解决方案可以从组件的制作方面考虑。
要做到的目标是，既满足部分用户快速集成组件，又能让部分用户解决依赖冲突的前提下保证能享受组件将来的更新优化。
答案就是subspec，以下是 ybimagebrowser.podspec 部分代码（完整代码[3]）：
|
1
2
3
4
5
6
7
8
|
s.subspec "core" do |core|core.source_files = "ybimagebrowser/**/*.{h,m}"core.dependency 'sdwebimage', '>= 5.0.0'ends.subspec "nosd" do |core|core.source_files = "ybimagebrowser/**/*.{h,m}"core.exclude_files = "ybimagebrowser/webimagemediator/ybibdefaultwebimagemediator.{h,m}"end |
由此，用户可以自由的选择是否需要依赖 sdwebimage，在 podfile 里的观感大致是这样：
|
1
2
3
4
|
// 依赖 sdwebimagepod 'ybimagebrowser'// 不依赖 sdwebimagepod 'ybimagebrowser/nosd' |
那么在 ybimagebrowser 代码中应该如何区分是否依赖了 sdwebimage 并且提供默认实现呢？
第一步是设计一个抽象接口（这个接口不依赖 sdwebimage）：
|
1
2
3
|
@protocol ybibwebimagemediator <nsobject>// download methode, caching methode, and so on.@end |
第二步是在ybimagebrowser.h中定义一个遵循该接口的属性：
|
1
2
|
/// 图片下载缓存相关的中介者（赋值可自定义）@property (nonatomic, strong) id<ybibwebimagemediator> webimagemediator; |
第三步是实现一个默认的中介者（这个类依赖了 sdwebimage）：
|
1
2
3
4
5
|
@interface ybibdefaultwebimagemediator : nsobject <ybibwebimagemediator>@end@implementation ybibdefaultwebimagemediator//通过 sdwebimage 的 api 实现 <ybibwebimagemediator> 协议方法@end |
第四步是在内部代码中通过条件编译导入并初始化默认中介者：
|
1
2
3
4
5
6
7
|
#if __has_include("ybibdefaultwebimagemediator.h")#import "ybibdefaultwebimagemediator.h"#endif...#if __has_include("ybibdefaultwebimagemediator.h")_webimagemediator = [ybibdefaultwebimagemediator new];#endif |
第五步在 ybimagebrowser.podspec 中也可以看到，在不依赖 sdwebimage 的集成方式时排除了两个文件：ybibdefaultwebimagemediator.{h.m}。
由此便实现了目标：
• 用依赖 sdwebimage 的集成方式快速集成。
• 使用不依赖 sdwebimage 的集成方式避免各种情况下的依赖冲突，但注意这种情况需要自行实现一个遵循<ybibwebimagemediator>协议的中介者。
以上便是避免依赖冲突的小技巧，希望读者朋友能提出更好的建议或意见
