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