Swift 自己從設計上來講是一門很是安全的語言,在 Swift 的思想中,全部的引用或者變量的類型都是肯定而且正確對應它們的實際類型的,你應當沒法進行任意的類型轉換,也不能直接經過指針作出一些出格的事情。這種安全性在平常的程序開發中對於避免沒必要要的 bug,以及迅速並且穩定地找出代碼錯誤是很是有幫助的。可是凡事都有兩面性,在高安全的同時,Swift 也相應地喪失了部分的靈活性。設計模式
現階段想要徹底拋棄 C 的一套東西仍是至關困難的,特別是在不少上古級別的 C API 框架還在使用 (或者被間接使用)。開發者,尤爲是偏向較底層的框架的開發者不得不面臨着與 C API 打交道的時候,仍是沒法繞開指針的概念,而指針在 Swift 中其實並不被鼓勵,語言標準中也是徹底沒有與指針徹底等同的概念的。爲了與龐大的 C 系帝國進行合做,Swift 定義了一套對 C 語言指針的訪問和轉換方法,那就是 UnsafePointer 和它的一系列變體。對於使用 C API 時若是遇到接受內存地址做爲參數,或者返回是內存地址的狀況,在 Swift 裏會將它們轉爲 UnsafePointer<Type> 的類型,好比說若是某個 API 在 C 中是這樣的話:數組
其對應的 Swift 方法應該是:安全
咱們這個 tip 所說的 UnsafePointer,就是 Swift 中專門針對指針的轉換。對於其餘的 C 中基礎類型,在 Swift 中對應的類型都遵循統一的命名規則:在前面加上一個字母 C 並將原來的第一個字母大寫:好比 int,bool 和 char 的對應類型分別是CInt,CBool 和 CChar。在上面的 C 方法中,咱們接受一個 int 的指針,轉換到 Swift 裏所對應的就是一個 CInt 的 UnsafePointer 類型。這裏原來的 C API 中已經指明瞭輸入的 num 指針的不可變的 (const),所以在 Swift 中咱們與之對應的是 UnsafePointer 這個不可變版本。若是隻是一個普通的可變指針的話,咱們可使用 UnsafeMutablePointer 來對應:框架
在 C 中,對某個指針進行取值使用的是 *,而在 Swift 中咱們可使用 memory 屬性來讀取相應內存中存儲的內容。經過傳入指針地址進行方法調用的時候就都比較類似了,都是在前面加上 & 符號,C 的版本和 Swift 的版本只在聲明變量的時候有所區別:性能
遵照這些原則,使用 UnsafePointer 在 Swift 中進行 C API 的調用應該就不會有很大問題了。插件
另一個重要的課題是如何在指針的內容和實際的值之間進行轉換。好比咱們若是因爲某種緣由須要涉及到直接使用 CFArray 的方法來獲取數組中元素的時候,咱們會用到這個方法:設計
由於 CFArray 中是能夠存聽任意對象的,因此這裏的返回是一個任意對象的指針,至關於 C 中的 void *。這顯然不是咱們想要的東西。Swift 中爲咱們提供了一個強制轉換的方法 unsafeBitCast,經過下面的代碼,咱們能夠看到應當如何使用相似這樣的 API,將一個指針強制按位轉成所需類型的對象:3d
unsafeBitCast 會將第一個參數的內容按照第二個參數的類型進行轉換,而不去關心實際是否是可行,這也正是 UnsafePointer 的不安全所在,由於咱們沒必要遵照類型轉換的檢查,而擁有了在指針層面直接操做內存的機會。指針
其實說了這麼多,Apple 將直接的指針訪問冠以 Unsafe 的前綴,就是提醒咱們:這些東西不安全,親們能不用就別用了吧 (做爲 Apple,另外一個重要的考慮是若是避免指針的話能夠減小不少系統漏洞)!在平常開發中,咱們確實不太須要常常和這些東西打交道 (除了傳入 NSError 指針這個歷史遺留問題之外,並且在 Swift 2.0 中也已經使用異常機制替代了 NSError)。總之,儘量地在高抽象層級編寫代碼,會是高效和正確的有力保證。無數先輩已經用血淋淋的教訓告訴咱們,要避免去作這樣的不安全的操做,除非你確實知道你在作的是什麼。orm
開源框架 RSA_Swift
iOS SKStoreProductViewController的應用
CocoaPods開源庫的搭建
CocoaPods搭建私有庫
CocoaPods搭建私有庫遇到問題
CocoaPods私有庫的升級維護
SKStoreReviewController之程序內評價
App應用程序圖標的動態更換
開源框架 MGJRouter_Swift
iOS的MVP設計模式
iOS插件化
iOS FMDB的使用
Swift之ReactiveSwift
OC之ReactiveCocoa
OC之ReactiveCocoa進階
iOS 性能考慮