为何要swift与oc混编
在ios开发中，swift与oc的混编，几乎是不可避免的。
2014年，Apple在开发者大会上发布了Swift语言，作为Apple平台新的开发语言。作为一款严谨、安全、简洁的静态语言，自出生时便注定要将Objective-C取而代之。
2015年，Apple开放了Swift源码，诱惑大量社区加入进来。2019年，Apple停止了Objective-C的API更新，强迫开发者使用Swift语言。
但在新生的这几年里，仍有许多开发者坚持使用Objective-C，并表示自己是重度OC爱好者，拒绝转向Swift。
然而，强势的Apple既然将Swift定义为未来的发展趋势，我们就不可避免的转头拥抱Swift。重要的是，Swift真的好用！！！
但在使用Swift开发的过程中，我们必然要接触到Objective-C的代码。不论是接手陈年项目，还是使用第三方提供的某些框架，或是合作方提供的古老模块，我们都不得不在新项目中兼容OC相关内容。
因此，我们必然要考虑Swift和OC混编的问题，以及C、C++等的混编问题。
为何选择自定义module
在swift与OC的开发中，如果我们面向Target，其实不必选择module，因为一个桥接头文件(Buid Settings 中 Objective-C Bridging Header)即可解决调用问题。
但在Framework中却不能如此处理，因为framework没有桥接配置。
对于初学者来说，我们可以将OC或C的头文件引用到XXXframework.h中，就可以在framework内的swift代码中随意使用。
但问题出现了，xxxframework.h引用的文件，必须为Public类型，所有引用此Framwork的target都可以随意调用，这个结果显然不是我们想要的。
我们迫切的需要一种方式，可以让framework内的OC代码以project的形式被swift使用，这就用到了module。
如何在Framework中使用module
- 新建一个Framework项目，暂命名为moduleMap(自行定义即可)
- 新建一个swift文件，命名为TestOc，用来测试调用OC代码
- 新建一个文件夹（new group），命名为mapoc
- 在mapoc中新建一个头文件myheader.h，及一个OC的类MyocHeader，再创建一个空文件，命名为module.modulemap
- module.modulemap中添加以下内容
module mapoc {
header "myheader.h"
export *
}
最终文件结构如下图：
- 进入Build Settings ，找到Import Paths，添加一条记录$(SRCROOT)/moduleMap/mapoc
- command+b 编译成功，此时即可在TestOc中import mapoc
-
在mapoc/myheader.h中引入MyocHeader.h，如下图
截屏2022-02-16 下午6.22.07.png
-
-
编译一次，TestOc中即可调用MyocHeader类，如下图
截屏2022-02-16 下午6.23.27.png
-
此时的头文件都是project类型的，当被其它项目引用时，是看不到这些project类的。
当然，如果你想把某个OC的类暴露给别的项目，即需要将头文件设置为public，则只需要在moduleMap.h中引用即可，此处无需赘述。
注意：如果你想设置多个module，只需要如上文中的mapoc一样，添加新的文件夹，文件夹中添加module.modulemap文件，增加一个公共请求头，并将请求头引用到module.modulemap 中，将文件夹路径新增到Import Paths中即可。
