導(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í)施過程中可能會遇到各種問題，例如代碼陳舊且不支持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，這樣警告會作為錯(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í)，可能會遇到需要使用try、try?和try!的情況。它們在異常處理方面有所不同。

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

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

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

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

2.3public 和 open 的區(qū)別

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

1、public關(guān)鍵字修飾的類在模塊外部無法被繼承。這意味著，如果其他模塊試圖繼承這個(gè)類，編譯器會報(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的所有類必須繼承。只是有的情況會隱式繼承，而有的情況下需要顯示實(shí)現(xiàn)。

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

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

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

2.6 Swift類和子類的初始化

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

1、在完成本類所有存儲屬性賦值之后，指定構(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ù)就是讓所有的存儲屬性都有初始值（optional 除外）。如果父類有指定初始化，子類必須也有指定初始化，并且必須調(diào)用父類的其中一個(gè)指定初始化（如果是必須初始化，就是重載），并遵循兩段式初始化的規(guī)則。一個(gè)便利初始化必須調(diào)用同一類中的初始化方法（可以是另一個(gè)便利初始化，也可以是指定初始化），但最終一定會調(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也會暴露在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文件引用該組件會報(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，在這種情況下，編譯器會將 OC 的指針類型當(dāng)成是隱式解析可選類型（例如 String!）導(dǎo)入到 Swift 中。swift 調(diào)用時(shí)，OC接口如果返回 nil，將會因?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)系，編譯器只會產(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)常會遇到）。

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)行。

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

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

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

如果使用import ，Project下其他Target就引用不到了，如百度App中Debug模塊引用此Private頭文件時(shí)，會報(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ú)特的問題將會逐漸浮現(xiàn)。我們會持續(xù)將這些新問題以及其對應(yīng)的解決方案整理并發(fā)布出來，為廣大的開發(fā)者們提供有價(jià)值的參考。歡迎大家留言探討。