Skip to main content

[Swift3] weak 與 unowned 關鍵字

雖然在 Swift 中看起來"很像"是不需要煩惱內存管理的問題,不過實際上它還是遵循著自動引用計數 (ARC) 的規則,當一個物件沒有被其他對象引用時會自動被銷毀,如果三魂七魄沒有完全回位的話,就會有個靈體留在現世的空間裡,最經典的範例如下:

閉包(Closure)引用


classClassA {

typealias Complete = ()->()

var name : String
var onComplete : Complete?

init(_ name: String){
self.name = name
print("Hello I am \(self.name)")

onComplete = {
print("\(self.name): onComplete!") // --> 閉包引用 self, 計數 + 1
}
}

deinit {
print("deinit: \(self.name)")
}
}

var a : ClassA? = ClassA("A") // --> 引用計數 + 1
a = nil // 2-1 = 1 還剩下 1 所以沒辦法銷毀

---output-------
Hello I am A

由於這邊的 onComplete 宣告為 Optional, 正確的做法要連同 onComplete 一起刪除才可以被回收,若不是 Optional 則會進入無法回收狀態:

var b : ClassA? = ClassA("B")
b?.onComplete = nil // --> 還好是 Optional 可以設成 nil 計數 - 1
b = nil // 計數 = 0 所以被回收

---output-------
Hello I am B
deinit: B

但是做人不需要煩惱太多,這時候就出動 unowned 關鍵字讓物件可以順利被回收:

onComplete = { [unowned self] in
print("\(self.name): onComplete!") // --> 沒有強制持有 self
}

---output-------
Hello I am A
deinit: A

不過眼尖的朋友應該會發現,在網路分享的教學文章內,也常看到有人使用 [weak self] 到底與 [unowned self] 最大的差別是什麼?

無主的 (unowned) 與 虛體 (weak)

直接翻成中文應該就很比較容易區分了吧?unowned 通常都用於該實體不會比引用閉包或持有它的物件更早被刪除如:self 或 parent,所以一般來說,用於 self 直接採用 [unowned self] 寫法比較直覺。

onComplete = { [unowned self] in
print("\(self.name): onComplete!") // --> unowned self 計數虛的
}

但是人生就是不怕一萬只怕萬一,誰知道那天 self 會不會提早被 release?所以基於安全的情況下就會使用 [weak self]。

onComplete = { [weak self] in
//這邊的 self 是 Optional 所以需要寫成 self?.xxx
print("\(self?.name ?? "nil"): onComplete!")
}
//建議寫法:
onComplete = { [weak self] in
if let strongSelf = self {
print("\(strongSelf.name): onComplete!")
}
}

所以當你無法確定使用哪個的話,直接採用 [weak self] 就可以囉!

循環引用

另外一種需要考慮加上 weak 或 unowned 關鍵字的情況就是循環引用。循環引用會讓程式 呈現一種「你中有我,我中有你」的境界:

class User {

var name : String
var firend: User?

init(_ name: String){
self.name = name
print("Hello I am \(self.name)")
}

func makeFriend(_ user: User) {
firend = user
print("\(self.name)'s new friend is \(user.name)")
}

deinit {
print("deinit: \(self.name)")
}
}

var A: User? = User("A")
var B: User? = User("B")

A?.makeFriend(B!)
B?.makeFriend(A!)

A = nil
//理論上 A 掛了應該印不出來會是 nil,
//但是因為沒有正確消除引用計數,所以 A 還是存在在 B 的心裡(朋友啊!我懷念你)
print(B?.firend!)
B = nil // 兩個都掛了但是還有魂體沒有回收而成為地縛靈

---output----------
Hello I am A
Hello I am B
A's new friend is B
B's new friend is A
Optional(User)

上面情況真的要能回收就是得在 A = nil 那段下面加上:

B?.firend = nil // A 被回收了
B = nil // 所以 B 也可以順利回收

---output----------
Hello I am A
Hello I am B
A's new friend is B
B's new friend is A
deinit: A
deinit: B

同理,不想要煩惱太多就是採用 weak 關鍵字指定 friend:

class User {

var name : String
weak var firend: User?

init(_ name: String){
self.name = name
print("Hello I am \(self.name)")
}

func makeFriend(_ user: User) {
firend = user
print("\(self.name)'s new friend is \(user.name)")
}

deinit {
print("deinit: \(self.name)")
}
}

var A: User? = User("A")
var B: User? = User("B")

A?.makeFriend(B!)
B?.makeFriend(A!)

A = nil
print(B?.firend) // 朋友是虛的,不見就讓它隨風去吧...

---output----------
Hello I am A
Hello I am B
A's new friend is B
B's new friend is A
deinit: A
nil

總結

  • unowned: 使用於目標實體不會在執行閉包前或者是比引用它的物件還要早被回收的狀態下。
  • weak: 剩下的情況都可以適用。
  • 例外: 如果在 root ViewController 或 Singleton class 絕對不會被回收情況下,閉包引用就不需要考慮是 weak 還是 unowned 了,因為寫不寫不是很大的問題。

Comments

Popular posts from this blog

[AIR] JoSiResize - Mobile 開發小工具

JoSiResizev0.6.0,Adobe AIR 3 runtime之前開發 tool app 的時候並沒有很深刻的體認到圖片素材的 resize 是一個很麻煩的事情...畢竟圖片使用量並不大,等到開發遊戲類的 app 才發現光處理不同螢幕尺寸的圖片素材是一個相當折磨人的工作。
因此 JoSiResize app 誕生了~~~原理是採用最小 scale 長寬比例不變的方式進行放大縮小。使用方法非常簡單,設定好變更的尺寸,接下來,將需要處理的圖片檔案全選直接拖曳到視窗內,畫面即會跳出預備儲存的檔案夾選擇畫面,確認後即開始轉檔。

PureMVC for Titanium Mobile

為了秉持著哪裡都要用 PureMVC 的想法,試著修改 PureMVC 官網上提供的 Javascript 版本給 Titanium 使用。
**source code**
有任何問題請上:Titanium Mobile 中文開發者論壇

建立 instance 的方法:使用 Puremvc 為 namespace
Ti.include('puremvc-js-1.0.js');
var c = Puremvc.clone( Puremvc.SimpleCommand );
var p = Puremvc.clone( Puremvc.Proxy, "TestProxy", "This is TestProxy's data" );
var m = Puremvc.clone( Puremvc.Mediator , "MainMediator" );

[Unity] erinylin.lazylib - Cookie for PlayerPrefs

有鑑於 PlayerPrefs 測試與版本更新問題,將大家都愛用的 PreviewLabs.PlayerPrefs 打包起來,製作重點還是以懶人為主,基本上 PlayerPrefs 資料更新與數量並不可能會有強烈衝擊效能的狀況產生,所以為了方便開發,就弄了一個視覺化工具,方便除錯用。

雖然 PreviewLabs.PlayerPrefs 作者都宣告放棄他們的版權,不過為了尊重程式,僅僅加入了兩個公用函式,其他並無更改。

內有:
Cookie ManagerCookie 用 DataObject 混合編輯 ScriptableObject執行階段除錯視窗工具當然還是有懶人常數檔案輸出資料版本控制,方便更新版後儲存資料更新功能其實很多,有興趣的請自行到 Github 下載並參考範例吧!