Swift開發之String 還是 NSString

既然像 這樣的 Swift 的類型和 Foundation 的對應的類是可以無縫轉換的，那麼我們在使用和選擇的時候，有沒有什麼需要特別注意的呢？

簡單來說，沒有特別需要注意的，但是儘可能的話還是使用原生的 類型。

原因有三。

首先雖然 和 有著良好的互相轉換的特性，但是現在 Cocoa 所有的 API 都接受和返回 類型。我們沒有必要也不必給自己憑空添加麻煩去把框架中返回的字元串做一遍轉換，既然 Cocoa 鼓勵使用 ，並且為我們提供了足夠的操作 的方法，那為什麼不直接使用呢？

其次，因為在 Swift 中 是 struct，相比起 的 類來說，更切合字元串的 "不變" 這一特性。通過配合常量賦值 (let) ，這種不變性在多線程編程時就非常重要了，它從原理上將程序員從內存訪問和操作順序的擔憂中解放出來。另外，在不觸及 特有操作和動態特性的時候，使用 的方法，在性能上也會有所提升。

最後，因為 實現了像 這樣的介面，因此有些 Swift 的語法特性只有 才能使用，而 是沒有的。一個典型就是 的枚舉，我們可以寫：

而如果轉換為 的話，是無法編譯的。

不過也有例外的情況。有一些 的方法在 中並沒有實現，一個很有用的就是在 iOS 8 中新加的 。我們想使用這個 API 來簡單地確定某個字元串包括一個子字元串時，只能先將其轉為 ：

A> Swift 的 沒有 是一件很奇怪的事情，理論上應該不存在實現的難度，希望只是 Apple 一時忘了這個新加的 API 吧。當然你也可以自行用擴展的方式在自己的代碼庫為 添加這個方法。當然，還有一些其他的像 和 這樣的 API 也沒有 的版本，這主要是因為 和 在處理編碼上的差異導致的。

使用 唯一一個比較麻煩的地方在於它和 的配合。在 中，我們在匹配字元串的時候通常使用 來表徵結果或者作為輸入。而在使用 的對應的 API 時， 也會被映射成它在 Swift 中且對應 的特殊版本：。這有時候會讓人非常討厭：

一般來說，我們可能更願意和基於 的 一起工作，而不喜歡使用麻煩的 。這種情況下，將 轉為 也許是個不錯的選擇：

作者：王巍 (@onevcat)

程序員共讀整理髮布，轉載請聯繫作者授權。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！