簡單介紹單例模式

單例模式其實(shí)大家應(yīng)該都耳熟能詳了，至少在工作上會時不時的聽到單例這個詞。那么什么是單例模式，簡單的講，就是只有一個實(shí)例，可以在所有的地方調(diào)用。舉個例子，你買了臺PS4放在公司休閑區(qū)里，那么全公司的人，都可以去玩這臺PS4，而且現(xiàn)實(shí)生活中的PS4并不能因?yàn)槟鉵ew一個又多生成一個，那是沒有意義的。
還有一個場景：有時候你想創(chuàng)建一個對象，并且讓所有人都以一種簡單一致的方式使用這個對象，這個時候用單例模式就會來的比較簡單。舉個例子：如果我們定義了一個logger.swift的類，這個類的作用是捕獲項(xiàng)目里所有的log日志，如果不使用單例模式，那么如果創(chuàng)建了兩個logger對象，這兩個輸出的log日志是獨(dú)立的，并不能滿足我們的捕捉所有日志的需求。這就是所謂的 封裝共享資源。

實(shí)現(xiàn)單例模式

實(shí)現(xiàn)單例模式必須遵循的原則：

• 單例必須是該類唯一的實(shí)例
• 單例不能被另一個對象取代，不管是誰，都！不！行！
• 單例必須能讓所有需要使用它的組件獲取到

快速實(shí)現(xiàn)單例

在swift中可以通過使用 全部常量，快速實(shí)現(xiàn)單例模式。

let globalLogger = Logger()
final class Logger {
     private ini() {
        // do something
     }

   func log(msg: String) {
      // do something
   }
}

使用Swift常量可以保證兩點(diǎn)：

1. 全局常量是惰性初始化的
2. 這種惰性初始化是線程安全的

final 關(guān)鍵字可以防止子類創(chuàng)建

傳統(tǒng)地實(shí)現(xiàn)單例

final class Foo {
    ... //some var and func
    class var manager:Foo {
        struct SingletonWrapper {
            static let singleton = Foo(); 
        }
        return SingletonWrapper.singleton;
    }
}

為什么要嵌套結(jié)構(gòu)體，因?yàn)镾wift不支持類存儲屬性

處理并發(fā)

當(dāng)我們使用單例的時候，往往就會出現(xiàn)一個情況，就是當(dāng)有多個組件調(diào)用同一個單例的時候，會造成單例中的變量是線程不安全的。也就是說，不能同時的對一個類似數(shù)組等變量進(jìn)行操作。所以最好使用 串行隊(duì)列 來保證線程安全。

private let serialQueue = dispatch_queue_create("serialQueue", DISPATCH_QUEUE_SERIAL);
...
dispatch_sync(serialQueue, {() in
      // do something
})

可能遇到的問題

代碼文件共享

在創(chuàng)建單例和定義全局常量時，應(yīng)該用關(guān)鍵字修飾將他們定義在單獨(dú)的文件中，這樣其他組件就無法違反單例的原則。

不使用并發(fā)保護(hù)

如果應(yīng)用對共享的數(shù)據(jù)結(jié)構(gòu)存在依賴，例如對數(shù)組或者全局函數(shù)存在依賴，我們就應(yīng)該確保單例代碼不會同時被多個線程訪問。如果不確定是否應(yīng)該采取并發(fā)保護(hù)，那就采取并發(fā)保護(hù)。因?yàn)槲覀儗幵付嘞囊稽c(diǎn)串行訪問所需的成本，也不想讓應(yīng)用崩潰。

拙劣的優(yōu)化

其實(shí)，當(dāng)并發(fā)保護(hù)出現(xiàn)性能問題時，應(yīng)該優(yōu)先考慮一下代碼的設(shè)計是否合理。而不是埋怨像GCD這樣的并發(fā)機(jī)制性能不佳，一般GCD就夠用了，而且GCD簡單，容易理解。

Tips

barrier block

var arrayQ = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_CONCURRENT)
...
dispatch_barrier_async(arrayQ, {() in
    // write data
})
...
dispatch_sync(arrayQ, {() in
    // read data
})

為什么要這樣做呢？
這樣做可以區(qū)分讀取數(shù)組內(nèi)容的線程和修改數(shù)組內(nèi)容的線程
將讀操作放在普通的block里，將寫操作放在了barrier block里。dispatch_barrier_async會向隊(duì)列丟一個block，并且同時會改變block的執(zhí)行方式，上面這個隊(duì)列會先看前面有沒有其他任務(wù)要執(zhí)行，如果有，就等著，等到在他面前所有的任務(wù)都執(zhí)行完了，它再執(zhí)行。
也就是說，當(dāng)它到達(dá)了隊(duì)列最前端時,GCD會等待所有正在進(jìn)行的讀操作完成，再進(jìn)行寫操作。
再換句話說，使用barrier block會將并發(fā)隊(duì)列暫時變成串行隊(duì)列。這可以很方便的創(chuàng)建讀/寫鎖。

保護(hù)回調(diào)

上面的代碼還有一個小問題，就是：如果我們在線程block里再丟一個block進(jìn)去，like this：

var callback() -> Void
var arrayQ = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_CONCURRENT)

init(callback -> Void) {
    self.callback = callback
}
...
dispatch_barrier_async(arrayQ, {() in
    // write data
    self.callBack()
})
...
dispatch_sync(arrayQ, {() in
    // read data
    self.callback()
})

這里的callback也是很有可能被并發(fā)調(diào)用的，所以我們可以采取比較合適的做法，就是讓組件在提供callback的時候自行說明是否這個回調(diào)block加了保護(hù)。

var callback() -> Void
var arrayQ = dispatch_queue_create("arrayQ", DISPATCH_QUEUE_CONCURRENT)
var callbackQ =  dispatch_queue_create("callbackQ", DISPATCH_QUEUE_SERIAL)

init(callback -> Void, protect:Bool = true) {
    self.callback = callback
    if protect {
        // 如果添加保護(hù)，則加入到串行隊(duì)列中
        self.callback = {() in 
              dispatch_sync(self.callbackQ, {() in
                    callback()
              })
        }
    }
}
...
dispatch_barrier_async(arrayQ, {() in
    // write data
    self.callBack()
})
...
dispatch_sync(arrayQ, {() in
    // read data
    self.callback()
})