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

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

對(duì)于其他語(yǔ)言來(lái)說(shuō)，Swift相對(duì)年輕，我們?cè)趯?shí)踐過(guò)程中整理一些常見(jiàn)問(wèn)題及其解決方法，希望能幫助讀者更順利地使用Swift進(jìn)行編程，提高研發(fā)效率。

GEEK TALK

01

Swift 適用場(chǎng)景

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

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

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

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

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

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

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

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

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

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

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

GEEK TALK

02

Swift的基本用法

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

如：字符串不能通過(guò)索引取字符

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

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

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

當(dāng)你進(jìn)行文件操作時(shí)，可能會(huì)遇到需要使用try、try?和try!的情況。它們?cè)诋惓Ｌ幚矸矫嬗兴煌?/span>

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

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

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

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

2.3public 和 open 的區(qū)別

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

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

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

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

2.4 解析JSON情況

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

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

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

2、當(dāng)我們?cè)谧宇惗x了指定初始化器(包括自定義和重寫(xiě)父類指定初始化器)，那么必須顯示實(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的意思是無(wú)條件停止執(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)用公開(kāi)OC頭文件

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

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

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

組件應(yīng)該盡可能少的公開(kāi)暴露頭文件，但Swift和OC混編不可避免使用OC非公開(kāi)頭文件，因此我們可以采取以下措施：將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需要使用尖括號(hào)；

• 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)識(shí)，并且是 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)致無(wú)法使用Swift來(lái)繼承和開(kāi)發(fā)BBAXYZ的子類。然而，這個(gè)基礎(chǔ)框架是業(yè)務(wù)的核心部分，因此，我們需要在未來(lái)支持Swift的開(kāi)發(fā)。

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

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

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

例如：

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

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

• 使用方式

class BBAEFG: BBAABC {
    
}

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

問(wèn)題場(chǎ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 指針也沒(méi)有關(guān)系，編譯器只會(huì)產(chǎn)生警告。這就需要程序員按規(guī)范編寫(xiě) OC 代碼，正確使用 nullability 標(biāo)注，并增加運(yùn)行時(shí)判空的斷言，以支持向后兼容。

GEEK TALK

04

其他常見(jiàn)問(wèn)題

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

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

• 解決方案：二選一

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GEEK TALK

05

總結(jié)

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