随着项目开发往后走，引入的三方库、框架、SDK越来越多，难免会出现重复引入三方库的问题。特别是提供SDK的，他们可能很少会去考虑这个问题（ps：谁碰到谁去解决，我干嘛要操心这么久远的事情，跟我又没有什么关系，早点快速实现功能对外提供SDK完成任务才是当下应该做的）
这不，我就遇到这麽个怪异问题：
这里报错了四个同类型的错误，我们挖出其中一条看看：
objc[29729]: Class MJPropertyType is implemented in both /Users/llbt/Library/Developer/CoreSimulator/Devices/5FCC1CE9-D8FE-42DF-B562-623A629C01C4/data/Containers/Bundle/Application/5EAA459F-2C14-4DBB-8FD2-C433A318544C/release.app/Frameworks/MJExtension.framework/MJExtension (0x106c7a298) and /Users/llbt/Library/Developer/CoreSimulator/Devices/5FCC1CE9-D8FE-42DF-B562-623A629C01C4/data/Containers/Bundle/Application/5EAA459F-2C14-4DBB-8FD2-C433A318544C/release.app/release (0x10394d5a8). One of the two will be used. Which one is undefined.
翻译一下就是说类“MJPropertyType”在
/Users/llbt/Library/Developer/CoreSimulator/Devices/5FCC1CE9-D8FE-42DF-B562-623A629C01C4/data/Containers/Bundle/Application/5EAA459F-2C14-4DBB-8FD2-C433A318544C/release.app/Frameworks/MJExtension.framework/MJExtension 和
/Users/llbt/Library/Developer/CoreSimulator/Devices/5FCC1CE9-D8FE-42DF-B562-623A629C01C4/data/Containers/Bundle/Application/5EAA459F-2C14-4DBB-8FD2-C433A318544C/release.app/release
中都实现了，它们中的一个将被使用，但是使用哪一个没有定义，是未知的。
我们先来看看MJPropertyType在哪里有定义：
首先我们去xcode的工程中搜索看看：
通过这一步，我们首先知道了MJPropertyType是三方库MJExtension中定义的类。
同时你也犯傻了对不对？ 明明只有这一个地方引入了三方库MJExtension，为什么会说有两个地方有类MJPropertyType的实现代码呢？好，接着我们去终端下去看个究竟：
打开终端，进入项目根目录，执行如下语句搜索整个项目中指定字符串：
grep -rn "MJPropertyType" ./*
搜索结果中列出来的./Pods/目录下的行是因为Pods中引入了MJExtension，这个我们前面在Xcode中也搜索到了，此处不必关注。
重点是我用红色框起来的列在搜索结果最后面的那两行。这两行指向的是同一个SDK的不同版本，一个是生产正式版，一个是测试版
Binary file ./puhui/ThridLib/CCB/ProductionSDK/CCBCommunication.framework/CCBCommunication matches
意思是说CCBCommunication.framework/CCBCommunica二进制文件中匹配到了字符串“MJPropertyType”
我们可以通过otool命令查看更多信息：
终端下进入项目中CCBCommunication.framework目录下，执行如下命令查看CCBCommunication.framework包含的.o文件并过滤出带“MJ”字符的行：
otool -Lv CCBCommunication | grep MJ
.o文件是相应的源文件（.m）编译后的目标文件。
我们再对比下三方库MJExtension中的文件清单：
如果你有心情的话，可以一一数一下，MJExtension中每一个.m文件都对应了上面的一个.o文件。
至此，我们可以确认三方库MJExtension在主工程和SDK文件CCBCommunication.framework中分别被引入包含进来了。
在跑工程的时候，你会发现：即使MJPropertyType类在两个地方都有实现，但是并不妨碍App的运行。并且理论上应该是没有什么大问题的。因为不管系统选择使用哪个地方的类实现，其实现代码都是一样的，因为是同一个库。
不过此时没有问题，不代表永远没有问题。并且也只是理论上没问题，你不能保证潜在问题被扼杀。所以最好我们还是应该消除这个隐患！
解决方案：删除主工程中引入的MJExtension库的实现文件（.m文件），只留下.h文件
写过C程序的都知道，C程序从代码到可启动程序经历：
预处理-->编译(包含汇编)-->.o目标文件-->链接-->可执行文件
OC/Swift基于C，自然也是包含这套逻辑的。
一般来说，只要有符号（变量名、函数名）的声明（.h文件），那么从源码到编译为.o的目标文件这几个步骤是不会有问题的。如果声明的符号没有对应的定义或实现，那么链接就会通不过（静态链接通不过，动态链接编译可以通过但是运行时会出现加载不了的错误，关于链接，后面再写篇文章介绍）。
我这里主工程中对MJExtension库的引入是动态库的形式，所以报的错是运行时抛出来的，运行时在两个地方找到了同一个符号。所以我们的解决方案是删除主工程中引入的MJExtension库的实现文件。理由如下：
1. SDK中虽然也引入了，但是很明显我们不应该动别人的东西。
2. 保留主工程中引入的MJExtension的头文件，是为了编译的需要。
注意要删除所有的实现文件，不删除干净会报类似如下这样的错误：
这是因为MJExtension剩下的实现文件会参与编译，但是编译过程中引用到了被删除的那个文件定义的符号，所以就会报这种符号找不到的错误。
删除所有实现文件后主工程引入的MJExtension如下：
重新Command + R编译运行，不报错了...==> OK，完美解决!!!
