swift에 대한 weak var의 행동

개시하다

swift에서 let나 var가 아니라 억지로 사용하는 경우weak var가 어떤 상황이나 행동에 따라 내 마음속에 말로 쓰고 싶다.
벽장에 자주 쓰인 곳[weak self]은 몇 년 전 이 글에 쓰여 있었다.
https://qiita.com/hs7/items/1f17baf43b943949a7ff

let/var/weak var의 차이

let

이편(변경 불가)의 값

스토리지 관리에 대한 강력한 참고 사항

var

정음판(변경 가능)의 값

스토리지 관리에 대한 강력한 참고 사항

weak var

정음판(변경 가능)의 값

스토리지 관리에 약한 참조

는 참고 유형class의 변수weak에만 사용할 수 있다.

나는 이렇게 weak의 차이는 약하게 참조되고 싶다.

Weak References 정보

다음 공식 ARC의 Weak References에 대한 설명에 적혀 있습니다.
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html#ID53
특히
A weak reference is a reference that doesn’t keep a strong hold on the instance it refers to, and so doesn’t stop ARC from disposing of the referenced instance. This behavior prevents the reference from becoming part of a strong reference cycle. You indicate a weak reference by placing the weak keyword before a property or variable declaration.
Because a weak reference doesn’t keep a strong hold on the instance it refers to, it’s possible for that instance to be deallocated while the weak reference is still referring to it. Therefore, ARC automatically sets a weak reference to nil when the instance that it refers to is deallocated. And, because weak references need to allow their value to be changed to nil at runtime, they’re always declared as variables, rather than constants, of an optional type.
weak이 있으면 변수 인스턴스가 버려지는 것을 방지하지 않기 때문에 인스턴스가 버려질 수 있으며 ARC에서 자동으로 nil을 설정할 수 있습니다.따라서 변수var로 발표weak는 반드시var이어야 한다.발표할 수 없음weak let.이런 견해가 있다.
참고로 weak let에서 성명하면 다음과 같은 구축 오류가 발생합니다.

'weak' must be a mutable variable, because it may change at runtime

따라서 개체 A의 개체 B를 참조할 때 개체 B의 폐기된 개체 A에 참조가 남아서 버릴 수 없도록 개체 B를 사용합니다.일반적으로 생각하다.

코드 예

이용 방법

import Foundation

class Person: CustomStringConvertible {
    let name: String
    
    init(name: String) {
        self.name = name
    }
    
    var description: String {
        "My name is \(self.name)."
    }
}

class Logic {
    var person: Person?
    
    init(person: Person) {
        self.person = person
    }
}

var person: Person? = Person(name: "hs7")
let logic = Logic(person: person!)
person = nil

print(logic.person)

// 出力結果
// Optional(My name is hs7.)

let 활용

import Foundation

class Person: CustomStringConvertible {
    let name: String
    
    init(name: String) {
        self.name = name
    }
    
    var description: String {
        "My name is \(self.name)."
    }
}

class Logic {
    let person: Person?
    
    init(person: Person) {
        self.person = person
    }
}

var person: Person? = Person(name: "hs7")
let logic = Logic(person: person!)
person = nil

print(logic.person)

// 出力結果
// Optional(My name is hs7.)

네트워크 활용

설정

import Foundation

class Person: CustomStringConvertible {
    let name: String
    
    init(name: String) {
        self.name = name
    }
    
    var description: String {
        "My name is \(self.name)."
    }
}

class Logic {
    weak var person: Person?
    
    init(person: Person) {
        self.person = person
    }
}

var person: Person? = Person(name: "hs7")
let logic = Logic(person: person!)
person = nil // 🐦このタイミングでlogic.personにnilがARCによって設定されます。logic.personはweakなためです。

print(logic.person)

// 出力結果
// nil

weak var만 한 후person = nil의logic.person에도 설정person했다.

Unowned References

수치를 약시하고 싶지만 nil이 되지 않을 것을 알았을 때는 Unnowned References를 이용하는 것이 좋다.이는 인스턴스가 폐기된 ARC에도 nil이 설정되지 않고 nil도 사용할 수 있기 때문(폐기된 경우unowned let 오류를 참조한 경우)이다.나는 별로 써 본 적이 없다signal SIGABRT..
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html#ID54

import Foundation

class Person: CustomStringConvertible {
    let name: String

    init(name: String) {
        self.name = name
    }

    var description: String {
        "My name is \(self.name)."
    }
}

class Logic {
    unowned let person: Person

    init(person: Person) {
        self.person = person
    }
}

var person: Person? = Person(name: "hs7")
let logic = Logic(person: person!)
person = nil // このタイミングでpersonは破棄される。logic.personの参照は残ったまま。

print(logic.person) // ❌error: Execution was interrupted, reason: signal SIGABRT.

총결산

다음은 unowned시의 행위를 총결하였다.weak var에서 선언하는 것이 좋은 모델로서 존재weak var,View 등 생명주기의 대상을 이 생명주기에 의존하지 않는 대상 내에서 변수로 선언하는 경우ViewController이상하게도 대상이 유지되지 않아 메모리 효율이 좋아질 것 같고 오류 동작(원래 폐기된 타이밍에 폐기되지 않았던 View 등)도 줄어들 것 같다.