引言

Flutter 在 iOS 上的編譯問題相信大家多多少少遇到過，不知道大家在搜索這方便的問題時，得到的答案是不是讓你 clean 或者 install 多幾次，很多時候就算解決完問題，也是處于薛定諤的狀態，所以本篇也簡單記錄下 Flutter 開發中，OC 混編 Swift 遭遇動態庫和靜態庫的問題，希望對“蒙圈”中的你有點幫助。

OC接入Swift 插件

首先，當我在一個 OC 項目里接入一個 Swift 插件，可能會遇到什么問題？

如下圖所示，如果你是一個比較老的 Flutter 項目，那可能會出現 swift 插件出現 not found 的問題。

針對這個問題，一般都是建議在 Podfile 文件下添加 use_frameworks! ，有時候還會建議添加 use_modular_headers! ，那這兩個標記位的作用是什么？

target 'Runner' do
  use_frameworks! 
  use_modular_headers!
  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end

我們知道 Podfile 的作用是處理 CocoaPads ，而 use_frameworks!告訴 CocoaPods 你想使用 Framework 而不是靜態庫，而默認由于 Swift 不支持靜態庫，因此有一開始 Swift 必須使用 Framework 的限制。

靜態庫和 Framework 區別

靜態庫和 Framework 的區別在于：

• *.a 的靜態庫類似于編譯好的機械代碼，源代碼和庫代碼都被整合到單個可執行文件中，所以它會和設備架構綁定，并且不包含資源文件比如圖片；
• Framework 支持將動態庫、頭文件和資源文件封裝到一起的一種格式，其中動態庫的簡單理解是：不會像靜態庫一樣被整合到一起，而是在運行或者運行時動態鏈接；

另外一個配置 use_modular_headers! ，它主要是將 pods 轉為 Modular，因為 Modular 是可以直接在 Swift中 import ，所以不需要再經過 bridging-header 的橋接。

但是開啟 use_modular_headers! 之后，會使用更嚴格的 header 搜索路徑，開啟后 pod 會啟用更嚴格的搜索路徑和生成模塊映射，歷史項目可能會出現重復引用等問題，因為在一些老項目里 CocoaPods 是利用Header Search Paths 來完成引入編譯，當然使用 use_modular_headers!可以提高加載性能和減少體積。

繼續回到問題上，我們在添加完 use_frameworks! 之后，有一定幾率中獎各種 Undefined symbol 的錯誤問題，這時候不要慌，因為這是 Swfit 里有靜態庫導致。

很明顯 Swift 不支持靜態庫的行為不科學，所以從 Xcode 9 開始 Swift 就開始支持靜態庫，而 CocoaPods 1.9.0 開始，引入了 use_frameworks! :linkage => :static 來生支持有靜態庫和 Framework 的情況。

新的問題： non-modular heade

所以修改 use_frameworks 配置，增加 static 之后可以看到 Undefined symbol 的錯誤都消失了，但是運行之后，可能會喜提新的問題： non-modular header 。

如果你去搜索答案，有很多答案會告訴你如下圖所示，通過 Allow Non-modular Includes in Framework Modules 設置為 true 就可以解決問題，但是很明顯這并不是正解，它更多適用于臨時的緊急狀體下。

當然，你也可以在出現問題的插件的 .podspec 下單獨配置 ALLOW ，效果相同，更輕量級，但是這也只是臨時解決方案。

s.user_target_xcconfig = { 'CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES' => 'YES' }

為什么說這種方式不靠譜，因為你不知道官方會什么時候刪除這種允許，當然這個問題網友提供的解決方案其實千奇百怪：

• 如果是 App 使用 dynamic framework 里的 header 導致錯誤，可以使用 #import "MyFile.h" 而不是 #import <MyFramework/MyFile.h> ；
• 將#import語句移到 .m（而不是將其放在.h頭文件中）， 這樣它就不會有包含 non-modular header 的問題，例如： github.com/AFNetworkin… ；
• 重命名 header ，不要讓 header 和模塊名一樣，變為 #import <FrameworkName/Header.h>
• 在 build setting 配置 OTHER_SWIFT_FLAGS -Xcc -Wno-error=non-modular-include-in-framework-module 解決 Swift 的問題；

有可能它們都能解決你的問題，但是為什么呢？下次遇到這些問題要選哪個解決？

不能在Framework Module中使用非Modular 的 Header

回歸到我們的問題，其實我的問題關鍵是：不能在 Framework Module 中使用非 Modular 的 Header，也就問題是在 Framework Module 中加載了非當前 Module 的頭文件，而由于 Header 是對外 public ，比如配置到了 s.public_header_files ，就會導致非 Modular 的 Header 也出現對外暴露的風險，所以我這邊的解放方式也很簡單：

*在 s.public_header_files 里只放需要公開的 Plugin.h ，使用了非 Modular 的 Header 不對外 public，從而符合規范達到編譯成功。

所以這里面的核心是：不要在 Umbrella Header File 中引用不需要對外公開的 OC 頭文件去作為子 module ，這也解釋了為什么上面講出問題的 #import語句移到 .m 就解決問題的邏輯。

例如有時候你還會引用一些系統的 C Module ，其實在 Framework Module 化過程中也會有類似的問題。

所以知道了為什么和怎么解決，就不會只是粗暴通過 LLVM 的配置來設置 Allow Non-modular Includes in Framework Modules 去解決薛定諤的問題。

另外你可能還有用到的，比如模擬器編譯提示 unsupport arm64、 BITCODE 失敗，SWIFT_VERSION 版本沖突等等：

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)
    target.build_configurations.each do |config|
        # building for iOS Simulator, but linking in an object file built for iOS, for architecture ‘arm64'
        config.build_settings['EXCLUDED_ARCHS[sdk=iphonesimulator*]'] = 'arm64'
        #不支持 BITCODE
        config.build_settings['ENABLE_BITCODE'] = 'NO'
        #解決swift模塊問題
        config.build_settings['SWIFT_VERSION'] = '5.0' 
    end
  end
end

當然，最后一句話：珍愛頭發，遠離 Swift 混編。