百度App Objective-C/Swift 组件化混编之路（二）- 工程化
?
作者丨張渝、郭金
來源丨百度App技術
前文《百度App Objective-C/Swift 組件化混編之路》已經介紹了百度App 引入 Swift 的影響面評估以及落地的實施步驟，本文主要以依賴管理工具為支撐，介紹百度App 如何實現組件內的 Objective-C/Swift 混編、單測、二進制發布和集成，以及組件間的依賴和引用。
百度App 自研的依賴管理工具 EasyBox 工具鏈已經把混編作為功能子集，如果你感興趣，可以閱讀百度App 技術公眾號往期文章《百度App iOS工程化實踐: EasyBox破冰之旅》。掌握 Xcode 編譯、鏈接選項等相關知識點，有助于理解混編的實現過程。
一. 組件Target類型 和 Module化
為解決大規模并行開發問題，百度App 將工程進行了組件化拆分，并實現組件的二進制化，一個組件即為一個獨立的功能單元和編譯單元，具有兩種形態，源碼形態和二進制形態，開發過程中可以按需進行組件的源碼/二進制切換。所以我們要解決這兩種形態下的組件內混編和組件間混合調用問題。
在介紹混編之前，我們先來了解兩個重要的概念：組件 Target 類型和 Module。
1.1 組件 Target 類型
EasyBox 工具鏈會為源碼形態的組件生成一個 Xcode 子工程和對應的 Target，Target 可以是以下類型中的一種：
-
dynamic_library：動態庫，Xcode 7 之前擴展名為 .dylib， Xcode 7 后是 .tbd ；目前官方環境并不允許為 iOS 平臺添加這種類型。
-
static_library：靜態庫，擴展名 .a
-
static_framework：靜態庫，擴展名 .framework
-
dynamic_framework：動態庫，擴展名 .framework
.a 與 .framework 的區別是：Framework 是分層目錄，它將共享資源（例如動態共享庫，nib 文件，圖像文件，本地化字符串，頭文件和參考文檔）封裝在一個程序包中。動態庫與靜態庫的區別是：系統根據需要將動態庫加載到內存中，可以被多個應用程序同時訪問，并在所有可能的應用程序之間共享資源的一份副本。靜態庫則是鏈接到某個應用程序的二進制中。
這些 Target 可能還存在一個或多個伴生 Target ：
-
bundle
-
octest_bundle
-
unit_test_bundle
-
ui_test_bundle
What's the Xcode target?
https://developer.apple.com/library/archive/featuredarticles/XcodeConcepts/Concept-Targets.html
對于伴生 Target，與 Swift 混編相關的只有單測；而對于主 Target，按照 Target 的文件組織形式可以分兩類：
-
Library（擴展名為 .a)
-
Framework（擴展名為 .framework）
當 Target 中只有 Objective-C 源碼(.h、.m)時，無論哪種 Target，源文件之間都可以通過 import 頭文件的方式進行引用，但 Swift 語言是強制以?module 形式?引用的，所以在 Swfit 中需要將 Target 的產物轉換為一個獨立的 module，供其他 module 依賴并引用。所以要實現 Swift 混編，每個組件對應的主 Target （源碼或二進制）都必須以一個 module 的形式存在。下面介紹如何實現 Target 內的 module 混編、以及 Target 之間的 module 依賴。
1.2 Module 化
1.2.1 基本概念
-
module：是一個編譯單元，或構建產物，對一個軟件庫的結構化替代封裝，供鏈接器使用（更多介紹請查閱 Clang-Module：https://clang.llvm.org/docs/Modules.html#introduction）
-
umbrella header：module 對外公開的根頭文件，包含了這個 module 中所有其他公開頭文件的引用。以 Foundation 框架的根頭文件?<Foundation/Foundation.h>為例：
對編譯器來講，每次編譯過程一個 module 只會加載一次，避免多次引入并加載相同的頭文件帶來的編譯耗時問題。所以 module 化后編譯效率更高。
-
modulemap：描述 module 和 module header 間的關系，描述現有 header 如何映射到 module 的邏輯結構。modulemap 結構如下：
ModuleMap采用模塊映射語言，但是到現在( 2020 年 Q3 為止)該語法依然不夠穩定，所以建議：編寫 modulemap 時需要盡可能使用少的關鍵字實現 module 功能，比如 framework、umbrella、header、extern、use。
建議 modulemap 內聲明一個umbrella header，便于快速引用對應的頭文件，但必須將所有公開的頭文件填充到 umbrella header 文件內。否則將得到一個警告：
<module-includes> Umbrella header for module 'XXX' does not include header 'absolute path to a public header'不包含 umbrella header 的 module ，modulemap 中不必添加?module * { export * }
包含 umbrella header 的 framework，不用配置任何(包括 MODULEMAP_FILE )即可自動 module 化
1.2.2?module 相關的 build setting 參數
上古時期，程序員通過 Makefile 來控制程序的編譯鏈接過程。現如今在 IDE 的封裝下，復雜度大大降低，只需要通過 IDE 來控制關鍵變量和自定義變量，在 Xcode 中，這個控制變量被稱為 build setting，build setting 和 Module 化相關的變量主要有這些：
-
對module自身的描述：
-
DEFINES_MODULE：YES/NO，module 化需要設置為 YES
-
MODULEMAP_FILE：指向 module.modulemap 路徑
-
HEADER_SEARCH_PATHS：modulemap 內定義的 Objective-C 頭文件，必須在 HEADER_SEARCH_PATHS 內能搜索到
-
PRODUCT_MODULE_NAME：module 名稱，默認和 Target name 相同
-
-
對外部module的引用：
-
FRAMEWORK_SEARCH_PATHS：依賴的 Framework 搜索路徑
-
OTHER_CFLAGS：編譯選項，可配置依賴的其他 modulemap 文件路徑 -fmodule-map-file=${modulemap_path}
-
HEADER_SEARCH_PATHS：頭文件搜索路徑，可用于配置源碼中引用的其他 Library 的頭文件
-
OTHER_LDFLAGS：依賴其他二進制的編譯依賴選項
-
SWIFT_INCLUDE_PATHS：swiftmodule 搜索路徑，可用于配置依賴的其他 swiftmodule
-
OTHER_SWIFT_FLAGS：Swift 編譯選項，可配置依賴的其他 modulemap 文件路徑?-Xcc -fmodule-map-file=${modulemap_path}
-
本文的后續部分也會用到 build setting 中的其他關鍵變量。
1.2.3?非 framework 的 module 處理
包含 Swift 源碼的非 framework 的 module，建議在 buildphase 的 script 里處理編譯后的兩個事情：
-
編譯生成的 interface header，拷貝作為公開頭文件，供其他 Target 訪問編譯生成的 Swiftmodule，配置追加到 modulemap 文件中
至此，我們已經了解了單個組件的 module 化過程。
二. 組件內混編
根據官方說明，Target 內支持 Objective-C 和 Swift 語言的混編，無外乎解決兩個問題：
-
Objective-C 可以引用 Swift 的類和方法
-
Swift 可以引用 Objective-C 的類和方法
下面我們針對 Framework 和 Library（非 Framework 靜態庫）兩種類型，分別介紹下組件內的混編實現。
2.1 Framework
針對 Framework 類型的 Target 內混編，我們要做的就是什么都不做。
簡單吧，對于全新生成的有 umbrella header 的 Framework 默認就是 Module化 的，不需要做任何操作即可實現 Target 內混編。對于沒有umbrella header的Framework，需要參照?如何實現 Module化?進行 Module 化改造。
-
Objective-C 引用 Swift 在頭文件內添加引入 Swift 的 Interface 頭文件即可，可以訪問 Swift 中以?@objc public?或?@objc open?修飾的類和方法，或者 class 修飾為?@objcMembers public
因為 Xcode 在編譯時已經對 framework 進行 Module 化處理，并自動生成該 Interface 頭文件，編譯成功時拷貝 Headers 文件夾內
-
Swift 引用 Objective-C 直接使用對應的類和方法
2.2 Library
針對 Library 類型的 Target 內混編，我們首先依然需要參照如何實現 Module 化改造。
-
Objective-C 引用 Swift 與 Framework 的引用方式一致，在頭文件內添加引入 Swift 的 Interface 頭文件即可，可以訪問 Swift 中以 @objc 修飾的類和方法，或者 class 修飾為 @objcMembers
-
Swift 引用 Objective-C 有顯式和隱式兩種方式 1、通過顯式配置橋接文件 BridingHeader，在橋接文件內 import 對 Swift 類公開的頭文件，用于 Swift 訪問 Objective-C 頭文件 (Importing Objective-C into Swift：https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/importing_objective-c_into_swift）
不足：無法開啟跨 Swift 版本兼容的功能
-
OTHER_SWIFT_FLAGS 的標記：-import-underlying-module?該構件標記由 Xcode 隱式創建下層 Module，并隱式引入當前 Module 內所有的 Objective-C 的公開頭文件，Swift 可以直接訪問。該標記需要配合?USER_HEADER_SEARCH_PATHS?或者?HEADER_SEARCH_PATHS?來搜索當前 module 所需的公開頭文件
不足：因為隱式創建下層 module，也會將 Swift 的類和方法包含到 Swift 的 Interface 頭文件中，需要在 Swift 的類和方法之前添加?@objc open，經測試發現，這樣會造成 module 將近一秒延遲(即修改 Swift 的部分接口后 Interface 文件不立即變更)。
三. 組件間依賴
組件間依賴調用的核心依然是?Module 化，否則 Swift 無法調用其他組件，下面介紹組件間依賴調用相關的?Build Settings?參數。
單測也是組件間依賴的一種，單測的 Target 依賴其他需要測試的組件，并且該組件以源碼形態集成
集成單測，除了配置組件間依賴的?Build Settings?，還需要注意兩個要點：
-
第一，需要鏈接對應的靜態庫到目標?testbundle
-
第二，如果當前單測是 Objective-C 源碼，而依賴的庫文件包含 Swift 相關的庫或 Target，必須在單測的 Target 內添加空的 Swift 占位源文件(空文件真的可以,后綴為 .swift)，否則鏈接時會報錯。
3.1 依賴 Framework 組件
如果依賴組件的Target類型是Framework，So Easy，因為Framework已經是一個module了(包含umbrella header)，直接配置BuildSettings：
-
FRAMEWORK_SEARCH_PATHS：?依賴的Framework搜索路徑，在對應的路徑下查找xxx.framework文件
-
OTHER_LDFLAGS：當依賴的組件是源碼時，可以有效將依賴的組件順序編譯，根據Xcode 10.2的升級說明(https://developer.apple.com/documentation/xcode-release-notes/xcode-10_2-release-notes)
3.2 依賴Library組件
當依賴組件的Target類型是Library，配置稍微復雜一點:
3.2.1 當前組件包含Objective-C源碼
-
OTHER_CFLAGS：配置當前Target依賴的其他Module
-
OTHER_LDFLAGS：同 3.1 依賴 Framework 組件
-
HEADER_SEARCH_PATHS：配置當前 Target 的頭文件搜索路徑，包含依賴的其他 Module 內配置的頭文件搜索路徑
-
OTHER_SWIFT_FLAGS；配置當前 Target 依賴的其他 Module
當依賴的 Library 中包含 Swift 源碼，那么該源碼編譯后將生成 swiftmodule，或依賴 Library 二進制中包含 swiftmodule，那么當前組件需要配置：
-
SWIFT_INCLUDE_PATHS：依賴組件 swiftmodule 的搜索路徑，需要配置該路徑，目錄下包含?*.swiftmodule
3.2.4 編譯順序控制
當依賴的組件是 Library，并且包含 Swift 的源碼，需將當前 Target 的 Scheme 編譯條件配置為非并行編譯?uncheck Parallelize Build(如下圖所示)，達到控制編譯順序的目的，避免因為依賴組件還未生成的 *-Swift.h 文件（依賴組件編譯成功后生成），造成當前組件源碼的編譯錯誤。
四. 混編組件二進制打包
為了提升產品線的編譯速度，業界內很多產品線均做了組件二進制化，即將組件源碼編譯為多種架構的二進制，并合并架構后以二進制的方式引入工程，避免了大量源碼的重復編譯，提升編譯效率，對于 Swift 的組件來說，如何做二進制化？
4.1 module 化
參考 1.2 Module 化要點
4.2 兼容性
雖然 ABI 穩定了，但是根據 Swift 的設計，各自 Swift 編譯器打出的二進制并不能在其他版本使用，需要使用到跨 Swift 版本調用的 interface 文件（在編譯產物 swiftmodule 文件夾中），設置?BUILD_LIBRARY_FOR_DISTRIBUTION = YES?即可生成，但該標記與bridging 沖突，即在混編的 Library 且使用?bridging header?的工程中不可用；如果真要使用 Library 又想 Swift 二進制跨 Swift 版本兼容，參考 2.2 介紹的?-import-underlying-module
4.3 SWIFT_OBJC_INTERFACE_HEADER 文件合并
對于 Framework ，Swift 源碼編譯產生的 Objective-C Interface 文件會被自動拷貝到公開頭文件夾，只需要合并多架構 Interface 頭文件即可；但對于 Library 則需要先手動移動頭文件再合并 Interface 頭文件，建議在 BuildPhase 添加 Script Phase 在編譯完成后拷貝操作：
不同架構的 *-Swift.h 文件的合并方式：
以?#ifdef 架構?的方式進行(當各架構提供的接口沒有區別的情況下，可直接使用模擬器架構)
合并為 XCFramework 的形式
4.4 swiftmodule文件合并
對于包含 Swift 源碼的產物中將包含 swiftmodule 文件夾，直接合并兩個 swiftmodule 目錄即可，不同架構以不同的文件名呈現
對于開啟?BUILD_LIBRARY_FOR_DISTRIBUTION?的 module 來說，swiftmodule 文件夾內包含 *.interface 即為跨 Swift 版本兼容文件
4.5 合并二進制
使用?lipo?命令進行二進制架構的常規合并，這里不做贅述
4.6 二進制包
如下圖：模擬器架構 Framework 形態的?*.swiftmodule（.a的 *.swiftmodule與之類似），其中?x86_64-apple-ios-simulator.swiftinterface是跨 Swift 版本調用的 interface 文件?
4.7 小知識：swiftmodule 的傳遞依賴性
已知：有組件 A 依賴組件 B，組件 B 依賴組件 C 在 Objective-C 中，B 對外暴露的頭文件中引用了 C 的公開頭文件，我們叫組件 B 傳遞依賴 C，結果就是編譯組件 A 時必須同時能找到組件 B 和組件 C 的頭文件，否則編譯失敗。
然而 Swift 并沒有公開頭文件一說，只要組件 B?import C，導致 swiftmodule 中也明確標記了?import C，當組件 A?import B?時，也同時?import C?，如果組件 A 找不到組件 C 的 module，那組件 A 將編譯失敗。
五. 總結
對于百度App 的開發者來說，不用去關心混編的是如何實現的，只需要跟正常開發一樣，組件內引用所需的頭文件（#import <ModuleXX/xx.h>）或module（@import ModuleXX），組件間在聲明依賴后亦可直接引用頭文件或 module ，EasyBox 工具鏈會根據源碼文件或配置進行module 化和?Xcode Build setting?相關的處理，以下情況將判定為需要 module 化：
-
存在 .swift 的源碼文件的組件
-
存在 .swiftmodule 或 *-Swift.h 文件的二進制組件
-
宿主工程的 Boxfile 中顯式配置 module 化
-
組件的 boxspec 描述中聲明 modulemap 文件
對于混編組件的二進制打包，開發者們也不用去關心如何處理編譯產物，諸如?*-Swift.h、二進制架構、*.swiftmodule、*.interface等，EasyBox 工具鏈打包命令?box package?會全權處理，降低開發者們的配置難度和協同成本。
六. 常見問題
6.1 Swift 組件內調用 Objective-C，只能調用 Objective-C 的公開頭文件，就不能調用私有頭文件嗎？
-
如果組件以源碼的方式被集成，是可行的。
-
Framework 中將私有頭文件聲明為一個私有 module（modulemap內聲明），由組件內的 Swift 源碼 import 該私有 module 即可
-
Library 中使用 bridging header
-
-
如果組件是以二進制方式被集成，則不可以：
-
集成 Framework 二進制，由于 Swiftmodule 的傳遞依賴的這個特性，這種調用方式將導致其他組件依賴這個組件的二進制時，無法找到對應的私有 module，導致編譯失敗
-
集成 Library 二進制，由于編譯二進制時無法同時開啟 Bridging Header 和?BUILD_LIBRARY_FOR_DISTRIBUTION，開啟 Bridging Header 后該二進制將無法在不同的 Swift 版本下被集成
-
6.2 到底使用 Framework 還是 Library？
建議直接全部使用 Framework ，因為 Framework 針對 Swift 混編支持非常簡單
對于最低支持版本在 iOS8 及以下的 App，由于 Apple 限制 ipa 中二進制包大小為 80M，為了縮小二進制體積，一般都采用內置動態庫，如果動態庫也建議使用 Framework，而非動態庫的 Library
6.3 App 鏈接一個 Swift 二進制時報錯？
當一個組件或產物需要鏈接其他 Swift 的產物時，比如 App、單測、動態庫等，需要告訴 Xcode 開啟 Swift 鏈接功能，開啟方法就是添加一個 Swift 文件，否則報錯。
七. 參考
-
官方文檔
https://swift.org
-
What are Frameworks?
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html
-
Clang Module?
http://clang.llvm.org/docs/Modules.html
-
Importing Objective-c Into Swift?
https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/importing_objective-c_into_swift
-
Xcode Release Notes?
https://developer.apple.com/documentation/xcode_release_notes
-
Xcode Build Settings
https://xcodebuildsettings.com/#category-core-build-system
總結
以上是生活随笔為你收集整理的百度App Objective-C/Swift 组件化混编之路（二）- 工程化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 大模型应用新范式：统一特征表示优化（UF
- 下一篇： 百度App Objective-C/Sw