導(dǎo)讀introduction Swift 是一種適用于iOS/macOS應(yīng)用開發(fā)、服務(wù)器端的編程語言。自2014年蘋果發(fā)布 Swift 語言以來，Swift5 實(shí)現(xiàn)了 ABI 穩(wěn)定性、Module 穩(wěn)定性和Library Evolution，與Objective-C（下文簡稱“OC”）相比，Swift 在開發(fā)效率、安全、編譯優(yōu)化、運(yùn)行性能和內(nèi)存管理方面具有顯著優(yōu)勢。（官方博客：https://www.swift.org/about/）

百度App 已在工程和環(huán)境上支持 Swift 開發(fā)，百度搜索大前端團(tuán)隊(duì)負(fù)責(zé)搜索服務(wù)的穩(wěn)定落地，我們積極探索 Swift的應(yīng)用，希望能大幅提升開發(fā)效率和靈活性、提升端用戶的搜索體驗(yàn)。然而，在實(shí)施過程中可能會(huì)遇到各種問題，例如代碼陳舊且不支持Swift，人員對Swift掌握不夠熟練、意識不足，協(xié)作方對Swift的支持不足等。

對于其他語言來說，Swift相對年輕，我們在實(shí)踐過程中整理一些常見問題及其解決方法，希望能幫助讀者更順利地使用Swift進(jìn)行編程，提高研發(fā)效率。

GEEK TALK

01

Swift 適用場景

在決定是否引入Swift前，我們需要判斷場景是否適合。通常情況下，可以用OC的場景均適合使用Swift，但也有一些不太適合直接替換的場景，需要慎重，比如：

1、涉及OC動(dòng)態(tài)性，頻繁在runtime時(shí)操作屬性和方法；

2、核心基礎(chǔ)功能，出現(xiàn)問題影響面較大的邏輯；

3、調(diào)用C++（目前Swift不能直接調(diào)用C++）；

4、繼承不支持Swift組件的類。

此外，對使用OC比較久遠(yuǎn)的工程，使用Swift前也應(yīng)注意：

1、能在工程環(huán)境和單獨(dú)模塊上支持Swift；

2、模塊較多的工程，可以內(nèi)外OC和Swift混編；

3、為了避免Swift Waring帶來的潛在問題，可以把SWIFT_TREAT_WARNINGS_AS_ERRORS設(shè)置為YES，這樣警告會(huì)作為錯(cuò)誤，輔助程序員更好的規(guī)范代碼；

4、模塊Module化后，要注意維護(hù) umbrella header 中的公開頭文件。

△注：本文中的“組件”均指代工程中的“Target”。

GEEK TALK

02

Swift的基本用法

2.1 Swift 的字符串為什么這么難用？

如：字符串不能通過索引取字符

• 原因：Swift認(rèn)為字符串是由一個(gè)個(gè)字形群集 （grapheme clusters）組成的，字形群集的大小不固定所以不能用整數(shù)去索引 (字形群集其實(shí)就是Swift中的Character（字符）類)。
  

• 解決方案：如要通過下標(biāo)取字符可以為String添加擴(kuò)展在下標(biāo)subscript實(shí)現(xiàn)通過傳入Int索引，在subscript轉(zhuǎn)為String.index獲取對應(yīng)字符的方式。

2.2 try try? try! 的區(qū)別

當(dāng)你進(jìn)行文件操作時(shí)，可能會(huì)遇到需要使用try、try?和try!的情況。它們在異常處理方面有所不同。

1、使用try時(shí)，如果出現(xiàn)異常，程序會(huì)進(jìn)入異常處理流程，你可以在catch語句塊中處理這個(gè)異常。

2、使用try?時(shí)，如果發(fā)生異常，它不會(huì)進(jìn)入異常處理流程，而是返回一個(gè)可選值類型。也就是說，如果出現(xiàn)異常，它將返回nil。

3、使用try!時(shí)，它不允許異常繼續(xù)傳播。一旦出現(xiàn)異常，程序會(huì)立即停止執(zhí)行。

因此，在文件操作中，你可以根據(jù)需要選擇合適的異常處理方式。在百度App中一般推薦使用try?。

2.3public 和 open 的區(qū)別

在Swift語言中，public和open都是用于在模塊中聲明需要對外界暴露的函數(shù)的關(guān)鍵字，但它們在繼承和公開程度上有所不同。

1、public關(guān)鍵字修飾的類在模塊外部無法被繼承。這意味著，如果其他模塊試圖繼承這個(gè)類，編譯器會(huì)報(bào)錯(cuò)。這樣的限制可以保護(hù)類的完整性，但也可能限制了其在其他模塊中的可重用性。

2、open關(guān)鍵字則允許任意繼承。如果一個(gè)類被open關(guān)鍵字修飾，那么其他模塊中的類可以自由地繼承這個(gè)類，不受任何限制。這樣的公開程度使得open關(guān)鍵字修飾的類在模塊間的重用性和擴(kuò)展性更加靈活。

從公開程度上來說，public的限制比open更嚴(yán)格，所以可以說public < open，即public的公開程度比open要低。

2.4 解析JSON情況

在Swift中解析JSON的情況，如果自行將JSON轉(zhuǎn)換為字典，需要涉及到類型判斷、轉(zhuǎn)換等操作，代碼比較復(fù)雜。這時(shí)可以使用第三方庫SwiftyJSON、ObjectMapper或者系統(tǒng)庫JSONEncoder來簡化操作，提高開發(fā)效率。

2.5 UIView子類必須添加init?(coder decoder: NSCoder)的原因

1、這是NSCoding protocol定義的，遵守了NSCoding protocol的所有類必須繼承。只是有的情況會(huì)隱式繼承，而有的情況下需要顯示實(shí)現(xiàn)。

2、當(dāng)我們在子類定義了指定初始化器(包括自定義和重寫父類指定初始化器)，那么必須顯示實(shí)現(xiàn)required init?(coder aDecoder: NSCoder)，而其他情況下則會(huì)隱式繼承，我們可以不用理會(huì)。

3、當(dāng)我們使用storyboard實(shí)現(xiàn)界面的時(shí)候，程序會(huì)調(diào)用這個(gè)初始化器。

4、注意要去掉fatalError，fatalError的意思是無條件停止執(zhí)行并打印。

2.6 Swift類和子類的初始化

Swift的類和子類初始化涉及到兩個(gè)關(guān)鍵階段。首先，確保所有的存儲(chǔ)屬性被賦予初始值，然后，在實(shí)例準(zhǔn)備使用之前，可以自定義存儲(chǔ)屬性的值。為了確保這兩個(gè)階段成功，實(shí)施了四步安全檢查，詳細(xì)如下：

1、在完成本類所有存儲(chǔ)屬性賦值之后，指定構(gòu)造器才能向上代理到父類的構(gòu)造器。

2、在為繼承的屬性設(shè)置新值之前，指定構(gòu)造器必須向上代理調(diào)用父類構(gòu)造器。

3、便利構(gòu)造器必須先調(diào)用其他構(gòu)造器，再為任意屬性（包括所有同類中定義的）賦新值。

4、在第一階段構(gòu)造完成之前，構(gòu)造器不能調(diào)用任何實(shí)例方法，不能讀取任何實(shí)例屬性的值，不能引用self作為一個(gè)值。

總之，類初始化必須完成的一個(gè)任務(wù)就是讓所有的存儲(chǔ)屬性都有初始值（optional 除外）。如果父類有指定初始化，子類必須也有指定初始化，并且必須調(diào)用父類的其中一個(gè)指定初始化（如果是必須初始化，就是重載），并遵循兩段式初始化的規(guī)則。一個(gè)便利初始化必須調(diào)用同一類中的初始化方法（可以是另一個(gè)便利初始化，也可以是指定初始化），但最終一定會(huì)調(diào)用到一個(gè)指定初始化。便利初始化不遵循兩段式初始化的規(guī)則，不能被子類調(diào)用或者重載。

GEEK TALK

03

OC與Swift的互相調(diào)用及跳轉(zhuǎn)

3.1 組件內(nèi)Swift文件調(diào)用公開OC頭文件

• 將公開OC頭文件（如：xyz.h）添加到組件（如：ABC）umbrella header中（如：#import）；

• Swift文件中直接調(diào)用公開OC頭文件內(nèi)容。

3.2組件內(nèi)Swift文件調(diào)用非公開（私有）的OC文件

組件應(yīng)該盡可能少的公開暴露頭文件，但Swift和OC混編不可避免使用OC非公開頭文件，因此我們可以采取以下措施：將Framework 中將私有頭文件聲明為一個(gè)私有 module（modulemap內(nèi)聲明），由組件內(nèi)的 Swift 源碼 import 該私有 module 即可。

1、創(chuàng)建Private.modulemap文件，以NewModule做為組件名為例，可以命名為NewModule.private.modulemap，內(nèi)容為下，module后面加_Private

• 羅列頭文件的形式

framework module NewModule_Private {
  header "xxxxx.h"
}

• 使用根頭文件的形式，添加頭文件NewModule_Private.h

framework module NewModule_Private {
  umbrella header "NewModule_Private.h"


  export *
  module * { export * }
}

2、在組件build settings中配置MODULEMAP_PRIVATE_FILE路徑，MODULEMAP_PRIVATE_FILE='NewModule.private.modulemap'；百度App中在NewModule.boxspec中如下代碼設(shè)置路徑；

s.xcconfig = {
    'MODULEMAP_PRIVATE_FILE' => '${BOX_ROOT}/NewModule.private.modulemap'
}

3、將NewModule.private.modulemap添加到工程目錄；百度App中在NewModule.boxspec中如下代碼設(shè)置路徑；

s.refer_files = [
      "NewModule.private.modulemap",
]

4、將xxxxx.h設(shè)置為Private header，百度App中在NewModule.boxspec中如下代碼設(shè)置xxxxx.h到Private header

s.private_headers = [
    "Sources/xxxxx.h"
  ]

5、調(diào)用方式

import NewModule_Private
let objectX = xxxxx()
print(objectX)

注意：

• 添加的Private頭文件可能存在傳遞頭文件的情況，即import其他頭文件，也需要將傳遞的頭文件添加到NewModule_Private中，同時(shí)import需要使用尖括號；

• Private Header也會(huì)暴露在framework中，所以可以約定外部組件使用Public Header，而避免使用Private Header，因?yàn)殡S著業(yè)務(wù)發(fā)展和Swift&OC混編，Private Header是不穩(wěn)定的。

3.3組件內(nèi)OC文件如何調(diào)用Swift文件？

• Swift 類需要繼承 NSObject，方法前面加上@objc 標(biāo)識，并且是 public 或者 open 的；

• 引入方式 #import"

3.4OC中的向前聲明，被Swift文件引用該組件會(huì)報(bào)錯(cuò)

如error:cannotfindprotocoldefinitionfor'xxxProtocol'

• 原因：此報(bào)錯(cuò)在OC中是代碼警告，百度App中默認(rèn)情況Swift中SWIFT_TREAT_WARNINGS_AS_ERRORS 設(shè)置為 YES，導(dǎo)致OC中的Warning視為Error；

• 解決方案：三選一

1、暫時(shí)設(shè)置 SWIFT_TREAT_WARNINGS_AS_ERRORS 為 NO

2、import xxxProtocol 不要向前聲明

3、使用 pragma 忽略警告

3.8Swift怎么用OC定義的宏？

• 在Swift中，能直接使用定義為常量的宏，不能使用帶有方法調(diào)用的宏，也不能使用靜態(tài)常量。

下面這種定義為常量的宏可以使用
#define APP_LANGUAGE_EN @"en" 
#define kNavigationBarHeight 44.0


下面帶有方法調(diào)用的宏不可以使用
#define kScreenHeight [[UIScreen mainScreen] bounds].size.height
#define kScreenWidth [[UIScreen mainScreen] bounds].size.width


下面帶有靜態(tài)常量swift不能使用，可以改成宏
static NSString *const StopTabRefreshNotifyNameHtml = @"TabRefreshNotifyNameHtml";

3.6Swift與OC泛型的混編

• 在我分們基礎(chǔ)框架中，有一個(gè)使用了OC泛型的類，如：

@interface BBAXYZ<T> : NSObject <BBAXYZEventProtocol>  
@property (nonatomic, weak) T page;  
@end

這個(gè)泛型的使用導(dǎo)致無法使用Swift來繼承和開發(fā)BBAXYZ的子類。然而，這個(gè)基礎(chǔ)框架是業(yè)務(wù)的核心部分，因此，我們需要在未來支持Swift的開發(fā)。

• 經(jīng)過仔細(xì)觀察和分析，我們發(fā)現(xiàn)泛型主要被用于指定page屬性的類型。因此，我們可以考慮去掉泛型，改為提供一個(gè)返回適當(dāng)類型的方法。這樣，我們就可以在Swift中順利地繼承和使用這個(gè)基礎(chǔ)框架。修改后的代碼如下：

@interface BBAXYZ : NSObject <BBAXYZEventProtocol>  
- (id)page;  
@end

然后，我們可以創(chuàng)建一個(gè)OC類來實(shí)現(xiàn)這個(gè)基礎(chǔ)框架，并讓所有的子類繼承這個(gè)OC類并實(shí)現(xiàn) page 方法，以返回適當(dāng)類型的對象。這樣，我們就可以在Swift中順利地繼承和使用這個(gè)基礎(chǔ)框架。

例如：

@interface BBAABC : BBAXYZ  
- (UIViewController *)page; 
@end

需要注意的是，雖然這樣的修改增加了輕量級的中間OC類，但它仍然實(shí)現(xiàn)了Swift與OC的混編，并允許我們在Swift中開發(fā)新的子類。這種方式既保證了代碼的兼容性，又使得我們可以繼續(xù)利用OC的優(yōu)點(diǎn)。

• 使用方式

class BBAEFG: BBAABC {
    
}

3.7Swift調(diào)用OC接口，OC的nullability標(biāo)注使用時(shí)的注意事項(xiàng)

問題場景：

1、OC 接口定義為 nonnull，swfit 調(diào)用時(shí)正常是當(dāng)做不可選類型使用，這時(shí)如果 OC 接口不規(guī)范返回 nil，則出現(xiàn)運(yùn)行時(shí)崩潰。

2、OC 接口未定義 nonnull 或 nullable，在這種情況下，編譯器會(huì)將 OC 的指針類型當(dāng)成是隱式解析可選類型（例如 String!）導(dǎo)入到 Swift 中。swift 調(diào)用時(shí)，OC接口如果返回 nil，將會(huì)因?yàn)殡[式解析一個(gè)為 nil 的可選值導(dǎo)致運(yùn)行時(shí)崩潰。

解決方式：

1、Swift 調(diào)用 OC 接口時(shí)，如果 OC 的接口聲明為 nonnull 或未指定 nullability 時(shí)，只有明確 OC 接口不為空的情況下才可調(diào)用。

2、在 OC 環(huán)境下，將 nil 賦值給 nonnull 指針也沒有關(guān)系，編譯器只會(huì)產(chǎn)生警告。這就需要程序員按規(guī)范編寫 OC 代碼，正確使用 nullability 標(biāo)注，并增加運(yùn)行時(shí)判空的斷言，以支持向后兼容。

GEEK TALK

04

其他常見問題

4.1 Xcode編譯只提示編譯錯(cuò)誤，提示信息非常少

• 原因：使用Swift語言開發(fā)的組件，依賴了不支持Module化的組件，導(dǎo)致組件都能編譯成功，但整個(gè)工程卻編譯失敗了；

• 解決方案：二選一

1、檢查并保障所有依賴的組件都已經(jīng)Module化了，如配置build settings；

2、在組件中新增Swift文件（空文件也行）。

4.2 由于組件開啟了Library Evolution 導(dǎo)致的編譯報(bào)錯(cuò)

錯(cuò)誤顯示：@objc' instance method in extension of subclass of 'xxxxx' requires iOS 13.0.0

這是由于組件開啟了Library Evolution導(dǎo)致，開關(guān)BUILD_LIBRARY_FOR_DISTRIBUTION 控制的。

一個(gè)庫開啟了Library Evolution，在依賴鏈下游的庫中將：

1、對它的類實(shí)現(xiàn) @objc 子類。

2、對它的類使用 extension 實(shí)現(xiàn) @objc 的方法（這在 UIKit 的 protocol 中經(jīng)常會(huì)遇到）。

3、對它的類實(shí)現(xiàn)子類，并添加 @objc 方法，且方法中使用父類的類型作為參數(shù)。

這些功能是實(shí)現(xiàn)的局限。估計(jì)是需要在 Swift 運(yùn)行時(shí)有一些對應(yīng)的更改，所以只在 swift 5.1 （iOS 13）運(yùn)行時(shí)里才可以運(yùn)行。

除此之外，還會(huì)有一些編譯時(shí)沒有報(bào)錯(cuò)，但運(yùn)行時(shí) crash 或結(jié)果不正確的情況。

百度App中默認(rèn)開啟Library Evolution，一個(gè)組件關(guān)閉Library Evolution會(huì)導(dǎo)致二進(jìn)制存在不兼容的情況，暫時(shí)無解決方案。

4.3 暴露的Private頭文件如果使用雙引號import，會(huì)報(bào)警告，需要修改為尖括號

如果使用import ，Project下其他Target就引用不到了，如百度App中Debug模塊引用此Private頭文件時(shí)，會(huì)報(bào)錯(cuò) not found with include, use "quotes" instead。

• 原因：這是由于其他Target對主模塊引用時(shí)默認(rèn)是從當(dāng)前項(xiàng)目下引用頭文件，而尖括號方式從系統(tǒng)庫或用戶庫中引用；

• 解決方案：其他Target將Private Header 配置到其 HEADER_SEARCH_PATHS，使用雙引號和尖括號均可。

GEEK TALK

05

總結(jié)

以上是我們在Swift開發(fā)過程中所遇到的一些常見問題及其相應(yīng)的解決方案。然而，隨著我們不斷深入Swift開發(fā)這片浩渺的海洋，更多獨(dú)特的問題將會(huì)逐漸浮現(xiàn)。我們會(huì)持續(xù)將這些新問題以及其對應(yīng)的解決方案整理并發(fā)布出來，為廣大的開發(fā)者們提供有價(jià)值的參考。歡迎大家留言探討。