為何要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中即可。
