Swift如何優雅的進行解包

Posted on by

前言

對於Swift學習而言,可選類型Optional是永遠繞不過的坎,特別是從OC剛剛轉Swift的時候,可能就會被代碼行間的?與!,有的時候甚至是??搞得稀裡糊塗的.

這篇文章會給各位帶來我對於可選類型的一些認識以及如何進行解包,其中會涉及到Swift中if let以及guard let的使用以及思考,還有涉及OC部分的nullable和nonnull兩個關鍵字,以及一點點對兩種語言的思考.

var num: Int?它是什麼類型?

在進行解包前,我們先來理解一個概念,這樣可能更有利於對於解包.

首先我們來看看這樣一段代碼:

var num: Int?
num = 10
if num is Optional<Int> {
	print("它是可選類型")
}else {
	print("它是Int類型")
}

請先暫時不要把這段代碼復制到Xcode中,先自問自答,num是什麼類型,是Int類型嗎?

好瞭,你可以將這段代碼復制到Xcode裡去瞭,然後在IDE中的if上一定會出現這樣一段話:’is’ test is always true

不是Int類,它是Optiona類型

那麼Optional類型是啥呢–可選類型,具體Optional是啥,點進去看看你就知道瞭.在這裡我就不多做解釋瞭.

var num: Int?這是Optional的聲明，意思不是”我聲明瞭一個Optional的Int值”,而是”我聲明瞭一個Optional類型值，它可能包含一個Int值，也可能什麼都不包含”,也就是說實際上我們聲明的是Optional類型，而不是聲明瞭一個Int類型!

以此類推String?是什麼類型,T?是什麼類型,答案各位心中已經明瞭吧.

正是因為num是一個可選類型,所以它才能賦值為nil, var num: Int = nil,這樣是不可能賦值成功的,因為Int類型中沒有nil這個概念!

這就是Swift與OC一個很大區別,在OC中我們的對象都可以賦值為nil,而在Swift中,能賦值為nil隻有Optional類型!

解包的基本思路

使用if let或者guard let,而非強制解包

我們先來看一個簡單的需求,雖然這個需求在實際開發中意義不太大:

我們需要從網絡請求獲取到的一個人的身高(cm為單位)以除以100倍,以獲取m為單位的結果然後將其結果進行返回.

設計思路:

由於實際網絡請求中,後臺可能會返回我們的身高為空(即nil),所以在轉模型的時候我們不能定義Float類型,而是定義Float?便於接受數據

如果身高為nil,那麼nil除以100是沒有意義的,在編譯器中Float?除以100會直接報錯,那麼其返回值也應該為nil,所以函數的返回值也是Float?類型

那麼函數應該設計成為這個樣子是這樣的:

func getHeight(_ height: Float?) -> Float?

如果一般解包的話,我們的函數實現大概會寫成這樣:

func getHeight(_ height: Float?) -> Float? {
	if height != nil {
		return height! / 100
	}
	return nil
}

使用!進行強制解包,然後進行運算

我想說的是使用強制解包固然沒有錯,不過如果在實際開發中這個height參數可能還要其他用途,那麼是不是每使用一次都要進行強制解包?

強制解包是一種很危險的行為,一旦解包失敗,就有崩潰的可能,也許你會說這不是有if判斷,然而實際開發中,情況往往比想的復雜的多,所以安全的解包行為應該是通過if let 或者guard let來進行

func getHeight(_ height: Float?) -> Float? {
	if let unwrapedHeight = height {
		return unwrapedHeight / 100
	}
	return nil
}

或者

func getHeight(_ height: Float?) -> Float? {
	guard let unwrapedHeight = height else {
		return nil
	}
	return unwrapedHeight / 100
}

那麼if let和guard let 你更傾向使用哪個呢?

在本例子中,其實感覺二者的差別不大,不過我個人更傾向於使用guard let.

原因如下:

在使用if let的時候其大括號類中的情況才是正常情況,而外部主體是非正常情況的返回的nil;

而在使用guard let的時候,guard let else中的大括號是異常情況,而外部主體返回的是正常情況.

對於一個以返回結果為目的的函數,函數主體展示正常返回值,而將異常拋出在判斷中,這樣不僅邏輯更清晰,而且更加易於代碼閱讀

解包深入

有這麼一個需求,從本地路徑獲取一個json文件,最終將其轉為字典,準備進行轉模型操作

在這個過程中我們大概有這麼幾個步驟:

1.獲取本地路徑

func path(forResource name: String?, ofType ext: String?) -> String?

2. 將本地路徑讀取轉為Data

init(contentsOf url: URL, options: Data.ReadingOptions = default) throws

3. JSON序列化

class func jsonObject(with data: Data, options opt: JSONSerialization.ReadingOptions = []) throws -> Any

4. 是否可以轉為字典類型

我們可以看到以上幾個函數中,獲取路徑獲取返回的路徑結果是一個可選類型,而轉Data的方法是拋出異常,JSON序列化也是拋出異常,至於最後一步的類型強轉是使用as! [Sting: Any]這樣的操作

這個函數我是這來進行設計與步驟分解的:

函數的返回類型為可選類型,因為下面的4步中都有可能失敗進而返回nil

雖然有人會說第一步獲取本地路徑,一定是本地有的才會進行讀取操作,但是作為一個嚴謹操作,凡事和字符串打交道的書寫都是有隱患的,所以我這裡還是用瞭guard let進行守護

這個函數看起來很不簡潔,每一個guard let 後面都跟著一個異常返回,甚至不如使用if let看著簡潔

但是這麼寫的好處是:在調試過程中你可以明確的知道自己哪一步出錯

func getDictFromLocal() -> [String: Any]? {
	//1 獲取路徑
	guard let path = Bundle.main.path(forResource: "test", ofType:"json") else {
		return nil
	}
	//2 獲取json文件裡面的內容
	guard let jsonData = try? Data.init(contentsOf: URL.init(fileURLWithPath: path)) else {
		return nil
	}
	//3 解析json內容
	guard let json = try? JSONSerialization.jsonObject(with: jsonData, options:[]) else {
		return nil
	}
	//4 將Any轉為Dict
	guard let dict = json as? [String: Any] else {
		return nil
	}
	return dict
}

當然,如果你要追求簡潔,這麼寫也未嘗不可,一波流帶走

func getDictFromLocal() -> [String: Any]? {
	guard let path = Bundle.main.path(forResource: "test", ofType:"json"),
		let jsonData = try? Data.init(contentsOf: URL.init(fileURLWithPath: path)),
		let json = try? JSONSerialization.jsonObject(with: jsonData, options:[]),
		let dict = json as? [String: Any] else {
		return nil
	}
	return dict
}

guard let與if let不僅可以判斷一個值的解包,而是可以進行連續操作

像下面這種寫法,更加最求的是結果,對於一般的調試與學習,多幾個guard let進行拆分,也未嘗不可

至於哪種用法更適合,因人而異

可選鏈的解包

至於可選鏈的解包是完全可以一步到位,假設我們有以下這個模型

class Person {
	var phone: Phone?
}
class Phone {
	var number: String?
}

Person類中有一個手機對象屬性,手機類中有個手機號屬性,現在我們有位小明同學,我們想知道他的手機號

小明他不一定有手機,可能有手機而手機並沒有上手機號碼

let xiaoming = Person()
guard let number = xiaoming.phone?.number else {
	return
}

這裡隻是拋磚引玉,更長的可選鏈也可以一步到位,而不必一層層進行判斷,因為可選鏈中一旦有某個鏈為nil,那麼就會返回nil

nullable和nonnull

我們先來看這兩個函數,PHImageManager在OC與Swift中通過PHAsset實例獲取圖片的例子

[[PHImageManager defaultManager] requestImageForAsset:asset 
targetSize:size 
contentMode:PHImageContentModeDefault 
options:options 
resultHandler:^(UIImage * _Nullable result, NSDictionary * _Nullable info) {
// 非空才進行操作 註意_Nullable,Swift中即為nil,註意判斷
if (result) {
}
}];
PHImageManager.default().requestImage(for: asset, 
targetSize: size, 
contentMode: .default, 
options: options, 
resultHandler: { (result: UIImage?, info: [AnyHashable : Any]?) in
 guard let image = result else { return }
})

在Swift中閉包返回的是兩個可選類型result: UIImage?與info: [AnyHashable : Any]?

而在OC中返回的類型是 UIImage * _Nullable result, NSDictionary * _Nullable info

註意觀察OC中返回的類型UIImage * 後面使用瞭_Nullable來修飾,至於Nullable這個單詞是什麼意思,我想稍微有點英文基礎的應該一看就懂–“可能為空”,這不恰恰和Swift的可選類型呼應嗎?

另外還有PHFetchResult遍歷這個函數,我們再來看看在OC與Swift中的表達

PHFetchResult *fetchResult;

[fetchResult enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {

}];
let fetchResult: PHFetchResult
fetchResult.enumerateObjects({ (obj, index, stop) in
})

看見OC中Block中的回調使用瞭Nonnull來修飾,即不可能為空,不能為nil,一定有值,對於使用這樣的字符修飾的對象,我們就不必為其做健壯性判斷瞭.

這也就是nullable與nonnull兩個關鍵字出現的原因吧–與Swift做橋接使用以及顯式的提醒對象的狀態

一點點Swift與OC的語言思考

OC函數是這樣的

- (NSString *)stringByAppendingString:(NSString *)aString;

Swift中函數是這樣的

public mutating func append(_ other: String)

僅從API來看,OC的入參是很危險的,因為類型是NSString *

那麼nil也可以傳入其中,而傳入nil的後果就是崩掉,我覺得對於這種傳入參數為nil會崩掉的函數需要特別提醒一下,應該寫成這樣:

- (NSString *)stringByAppendingString:(NSString * _Nonnull)aString;

或者這樣

- (NSString *)stringByAppendingString:(nonnull NSString *)aString;

以便告訴程序員,入參不能為空,不能為空,不能為空.重要的事情說三遍!!!

反觀Swift就不會出現這種情況,other後面的類型為String,而不是String?,說明入參是一個非可選類型.

基於以上對於代碼的嚴謹性,所以我才更喜歡使用Swift進行編程.

當然,Swift的嚴謹使得它失去部分的靈活性,OC在靈活性上比Swift卓越,但是從安全角度和編碼的長遠意義看Swift才是現在與未來.

最後想說的是Swift在國內的使用並不是很受擁戴,這點很無奈,因為和整個的大環境有關.

以上就是Swift如何優雅的進行解包的詳細內容，更多關於Swift解包的資料請關註WalkonNet其它相關文章！

推薦閱讀：