SWIFT中的引用關(guān)系說明.docx_第1頁
SWIFT中的引用關(guān)系說明.docx_第2頁
SWIFT中的引用關(guān)系說明.docx_第3頁
SWIFT中的引用關(guān)系說明.docx_第4頁
SWIFT中的引用關(guān)系說明.docx_第5頁
已閱讀5頁,還剩2頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

SWIFT中的引用關(guān)系說明我發(fā)現(xiàn)自己寫代碼的時候經(jīng)常擔(dān)心強引用循環(huán)(retain cycles)的出現(xiàn)。我覺得這個和其他問題一樣比較常見。不知道你是什么情況,我反正總是聽見我什么時候要用關(guān)鍵詞weak?unowned這坨東西到底是啥玩意兒?這類聲音。我們發(fā)現(xiàn)的問題是我們知道在swift代碼中要去用strong,weak和unowned說明符來避免強引用循環(huán),但是我們不大了解具體用哪一個。好在我知道它們是啥,還知道啥時候去用他們!希望這篇文章能教會你知道什么時候,并且在哪里用這3個說明符。咱們開始吧ARCARC是自動內(nèi)存管理Apple版本的一個編譯時特性(compile time feature)。全稱是Automatic Reference Counting。意思是對于一個對象來說,只有在沒有任何強引用指向它時,該對象占用的內(nèi)存才會被回收。STRONG - 強引用從什么是強引用說起。它本質(zhì)上是一個普通的引用(指針或者其他有相同意思的東西),但是它特殊在能夠通過將該引用指向?qū)ο螅╫bject)的保留計數(shù)(retain count)增加1來保護這個對象不被ARC回收。實質(zhì)上,哪怕任何一個東西的一個強引用指向了這個對象,這個對象就不會被回收。記住這點,待會兒講強引用循環(huán)和相關(guān)東西的時候會用到。強引用在swift中幾乎隨處可見。實際上聲明一個屬性(property)的時候默認(rèn)就是一個強引用。通常在關(guān)系層級是線性的時候用強引用問題不大。當(dāng)強引用從父層級流向子層級的時候,這個強引用的使用總是沒問題。這有個強引用的例子。1. classKraken2. lettentacle=Tentacle()/對子層級的強引用。3. 4. classTentacle5. letsucker=Sucker()/對子層級的強引用。6. 7. classSucker8. 9. */Kraken的意思是海妖,Tentacle的意思是觸手,sucker的意思是吸盤.譯者注/*例子中是一個線性的關(guān)系層級。Kraken有一個指向Tentacle實例的強引用,Tentacle實例又有一個指向Sucker實例的強引用。引用關(guān)系的流向從父層級(Kraken)一直向下流到子層級(Sucker)。在animation block里引用層級也是類似的:1. UIView.animateWithDuration(0.3)2. self.view.alpha=0.03. 因為animateWithDuration是UIView的一個靜態(tài)方法,這里的閉包是父層級,self是子層級。如果子層級想引用父層級怎么辦?這就是我們要用弱引用和unowned引用的地方。WEAK AND UNOWNED REFERENCES - 弱引用和UNOWNED引用WEAK - 弱引用弱引用就是一個保護不了其所指對象不被ARC回收的指針。強引用能讓它對象的保留計數(shù)增加1,弱引用不能。swift中,所有的弱引用都是非常量的可選類型(non-constant Optionals)(想一下var和let的關(guān)系),因為在沒有其他強引用指向的時候,這個引用能,并且會被改變成nil。例如下面的代碼就不能通過編譯:1. classKraken2. weaklettentacle=Tentacle()/let是一個常量。所有的weak變量都必須是可變(mutable)的。3. 因為tentacle是一個let常量。Let由于規(guī)范限制使得其在運行時不能夠被改變。因為弱引用變量(weak variables)在沒有任何強引用指向它們時是會被改變成nil的,所以swift編譯器要求你將弱引用變量聲明成var。那些會出現(xiàn)潛在的強引用循環(huán)的地方就是使用弱引用變量的關(guān)鍵之處。強引用循環(huán)發(fā)生在兩個對象彼此之間都用強引用指向?qū)Ψ降那闆r下,ARC不會對其中任何一個實例發(fā)出正確的釋放信號代碼(release message code),因為這兩個實例正彼此保護著對方。這有個來自Apple的簡潔圖片,非常明了的展示了這點:下面是一個能展示強引用循環(huán)的很棒的例子,其中用到了NSNotification API(還是比較新的API)。看看下面的代碼吧:1. classKraken2. varnotificationObserver:(NSNotification)-Void)?3. init()notificationObserver=NSNotificationCenter.defaultCenter().addObserverForName(humanEnteredKrakensLair,object:nil,queue:NSOperationQueue.mainQueue()notificationin4. self.eatHuman()5. 6. 7. deinit8. ifnotificationObserver!=nil9. NSNotificationCenter.defaultCenter.removeObserver(notificationObserver)10. 11. 12. 到這兒我們就搞出了一個強引用循環(huán)。你看,swift里的閉包與Objective-C里的blocks極像。如果一個變量是在閉包外面聲明的,在閉包里面引用這個變量就會產(chǎn)生出另一個強引用。此種情況下僅有的例外就是使用值類型的變量,比如swift里的Ints,Strings,Arrays和Dictionaries。這里NSNotificationCenter保留了一個閉包,當(dāng)你調(diào)用eatHuman()方法時這個閉包以強引用的方式捕獲了self。問題是:我們直到deinit的時候才清空這個閉包,但是deinit永遠(yuǎn)不會被ARC調(diào)用,因為這個閉包有一個對Kraken實例的強引用!用NSTimers和NSThread的地方也會出現(xiàn)這種情況。解決方法是在閉包的捕獲列表(capture list)里使用一個對self的弱引用。這就打破了強引用循環(huán)。到了這里,我們的對象引用關(guān)系圖就變成了這樣:把self變成weak不會給self的保留計數(shù)加1,這就能讓ARC在正確的時間將其合理的銷毀。要在閉包里使用weak和unowned變量的話,需要在閉包體內(nèi)用語法。例如:1. letclosure=weakselfin2. self?.doSomething()/記住,所有的weak變量都是可選類型。3. 為什么weak self會在方括號里?這看起來很怪!Swift中我們看見方括號就會想到數(shù)組。你猜怎么著?你可以在閉包里指定多個待捕獲的值!比如:1. letclosure=weakself,unownedkrakenInstancein/瞧這個捕獲了多個值的數(shù)組2. self?.doSomething()/weak變量是可選類型3. krakenInstance.eatMoreHumans()/unowned變量不是可選類型4. 看起來就像數(shù)組多了吧?現(xiàn)在你就知道了為什么捕獲值是寫在方括號里的。好,用我們現(xiàn)在所學(xué)到的,在上面notification代碼的閉包捕獲列表中加上weak self就可以解決強引用循環(huán)的問題:1. NSNotificationCenter.defaultCenter().addObserverForName(humanEnteredKrakensLair,object:nil,queue:NSOperationQueue.mainQueue()weakselfnotificationin/使用捕獲列表消除了強引用循環(huán)!2. self?.eatHuman()/self現(xiàn)在是一個可選類型了!3. 用到weak和unowned變量的另外一個地方就是使用協(xié)議(protocol)在多個class間去實現(xiàn)委托(delegation)的情況,因為swift中class是引用類型。結(jié)構(gòu)體(structs)和enum(枚舉)也能遵循協(xié)議,但是它們是值類型。如果一個父類帶上一個子類使用委托,像這樣:1. classKraken:LossOfLimbDelegate2. lettentacle=Tentacle()3. init()4. tentacle.delegate=self5. 6. funclimbHasBeenLost()7. startCrying()8. 9. 10. protocolLossOfLimbDelegate11. funclimbHasBeenLost()12. 13. classTentacle14. vardelegate:LossOfLimbDelegate?15. funccutOffTentacle()16. delegate?.limbHasBeenLost()17. 18. 那么我們就需要用weak變量。在這個例子里Tentacle以它所擁有的代理屬性(delegate property)的形式持有一個對Kraken的強引用,同時Kraken在它的tentacle屬性中也有一個對Tentacle的強引用。我們在代理聲明之前加上一個weak說明符來解決:1. weakvardelegate:LossOfLimbDelegate?你說什么?編譯不通過?好吧,因為非class類型的協(xié)議不能被標(biāo)識為weak。此時,我們得用一個唯類協(xié)議(class protocol)來使得代理屬性能夠標(biāo)識成weak。讓我們的協(xié)議繼承:class。1. protocolLossOfLimbDelegate:class/Protocol現(xiàn)在繼承了class2. funclimbHasBeenLost()3. 什么時候不用:class?Apple的文檔里說:當(dāng)一個協(xié)議需求所定義的行為(behavior)能夠確?;蛞笞裱@個協(xié)議的類型是引用類型而非值類型的時候,使用唯類協(xié)議?;旧?,如果你自己代碼的引用層級和我上面寫的一樣的話,你就加上:class。對于使用結(jié)構(gòu)體或者枚舉的情況,就不需要:class了,因為結(jié)構(gòu)體和枚舉是值類型,class是引用類型。UNOWNED弱引用和unowned引用本質(zhì)上是一樣的。Unowned引用并不增加它所引用對象的保留計數(shù)。然而swift語言中unowned引用的額外的優(yōu)點是它為非可選類型。這使得它用起來更方便,不用再去引入可選綁定(optional binding)。這和隱式可選類型(Implicity Unwarpped Optionals)沒什么區(qū)別。到這里就有點兒亂了。弱引用和unowned引用都不增加保留計數(shù)。它們都用來解決強引用循環(huán)的問題。那么我們什么時候用它們?Apple的文檔說:當(dāng)一個引用在其生命周期中變?yōu)閚il時依然合理,就把這個引用定義為弱引用。相反,如果你事先知道一個引用在被設(shè)置好了之后不會再變成nil,就把它定義成unowned引用。你知道答案了:就和隱式可選類型一樣,如果你能確保這個引用在被用到的時候肯定不是nil的話,就用unowned,如果不確保,就得用弱引用。下面是一個典型的例子,一個class的閉包中捕獲的self不會變成nil,這就生成了一個強引用循環(huán):1. classRetainCycle2. varclosure:()-Void)!3. varstring=Hello4. init()5. closure=6. self.string=Hello,World!7. 8. 9. 10. /初始化class,并激活強引用循環(huán)。11. letretainCycleInstance=RetainCycle()12. retainCycleInstance.closure()/此時我們可以確保閉包中捕獲的self不會再是nil了。此后的任何代碼(尤其是改變self的引用的代碼)都需要判斷一下unowned是否在這兒還起作用。上面的例子里,閉包以強引用的形式捕獲了self,同時self通過自己的閉包屬性也保留了一個對該 閉包的強引用,這就造出了強引用循環(huán)。簡單的給閉包加一個unowned self就能打破這個循環(huán):1. closure=unownedselfin2. self.string=Hello,Wo

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論