软件测试之SDK开发(ios)——再谈PodSpec

以前业务接SDK的时候，直接让其pod，如果编译报duplicate symbol（重复符号） 的问题，使用use_frameworks!即可以解决。
这一次接的一个项目，不允许使用use_frameworks!，只能使用静态库 并且不允许使用外部仓库https://github.com/CocoaPods/Specs.git。把解决问题的思路限制的死死的。

我这里想到了四个办法：
1、不允许使用外部仓库，那我把仓库搭建成私有的不就可以了，私有仓库搭建参考文章：iOS模块化实践 – 利用CocoaPods拆分项目
2、不允许使用动态库，我把依赖的命名空间改掉，和业务的命名不冲突不就可以了
3、直接将podspec的依赖打包成framework，以vendored_frameworks的方式引用
4、直接将SDK打包成静态库，供业务方使用，cocoapods打包静态库，参考文章：使用cocoapods打包静态库(依赖私有库，开源库，私有库又包含静态库)

我先尝试了最简单易行，最无脑的修改命名空间之旅，有过这种尝试的都知道这不是人干的，简单替换还好说，关键是第三方库的代码还包含了各种C的混编，C语言又没有命名空间，改的胆战心惊，后期还不好维护，改了一半我就放弃了。

命名空间即然改不了，搭建私有库也肯定不行了，搭建完了引入还是会报duplicate symbol。

只能尝试第三种方案了：
把依赖打包成framework后，通过vendored_frameworks引用，操作完之后，引入到工程中，duplicate symbol消失了，正当我以为ok的时候，发现SDK引用的FMDB会优先引用业务pod的FMDB，而业务的FMDB和SDK中的FMDB是不同的版本，造成错误。我这里是通过修改SDK代码，兼容不同版本的FMDB api。

第四种方案理论上也是可行的，因为第三种方式已经可以了，并且更容易维护和升级，就没有尝试第四种。

写了这么多，最后给一个简单的结论：
最好把SDK的依赖改成framework，因为你不能保证业务一定允许使用use_frameworks!，如果不允许使用use_frameworks!，很可能你的依赖会造成duplicate symbol错误。

参考文章

1、https://www.jianshu.com/p/a73b6bfdb41a
2、https://www.jianshu.com/p/9096a2eb2804