[UIKit] Dicee 앱 만들기

iOS & Swift - The Complete iOS App Development Bootcamp 에 대한 TIL 입니다.

 

학습 주제

@IBOutlet, @IBAction을 사용하여 인터페이스 빌더와 코드를 연결하는 법을 배운다.

 

@IBOutlet

@IBOutlet은 인터페이스 빌더의 UI 요소를 Xcode의 코드에 연결하는 데에 사용되는 키워드이다. 이를 통해 UI 요소에 대한 참조를 생성하고 코드에서 액세스 할 수 있으므로 요소의 속성을 인스펙터가 아닌 코드로 지정할 수 있다. 참고로 미국에서는 콘센트를 콘센트라 하지 않고 Outlet이라고 한다. 따라서, IBOutlet은 이름 그대로 인터페이스 빌더와 연결하는 콘센트 역할을 하는 것이다.

 

 

코드와 연결시킬 UI 요소를 control 버튼을 누른 상태로 Assistant 영역으로 드래그하면 위 화면과 같은 창이 뜨는데 Name 부분에 해당 UI 요소의 코드 변수명을 적어주면 된다.

 

@IBOutlet

@는 Swift에서 특성(Attribute, 속성으로도 번역이 되는데 Property와 겹치므로 특성이라고 하겠음)라고 하는 것으로 컴파일러에게 어떤 특성을 가지고 있다고 전하는 역할을 하는 키워드이다. Swift의 속성에는 선언 특성과 타입 특성이 있다. 두 특성 모두 선언을 할 때 혹은 타입을 지정할 때 컴파일러에게 특성에 대한 정보를 전달하는 일종의 메타 데이터 역할을 한다.

 

@IBOutlet 같은 경우에는 diceImageViewOne 프로퍼티를 선언할 때 인터페이스 빌더와 연결된 프로퍼티라는 특성을 컴파일러에게 알려주는 역할을 하는 것임으로 선언 특성이라고 할 수 있다.

 

weak

Swift에서 weak과 strong은 Class와 같은 참조 타입의 메모리 관리 기법인 ARC(Automatic Reference Count)와 관련이 있다. 아래 코드는 strong 참조에 대한 예시이다. 참고로 Swift에서는 기본이 강한 참조이므로 아무런 키워드를 사용하지 않아도 강한 참조가 된다.

 

class Person {
    let name: String
    
    init(name: String) {
        self.name = name
        print("\(name) is being initialized")
    }
    
    deinit {
        print("\(name) is being deinitialized")
    }
}

var person1: Person?
var person2: Person?
var person3: Person?

person1 = Person(name: "Alice") // 강한 참조 -> RC: 1
person2 = person1 // 강한 참조 -> RC: 2
person3 = person1 // 강한 참조 -> RC: 3

person1 = nil // RC: 2
person2 = nil // RC: 1
person3 = nil // RC: 0 -> 메모리에서 할당 해제

 

강한 참조를 한다는 것은 RC(Referece Count)가 1 증가한다는 의미이다. RC가 0이 되면 메모리의 힙 영역에서 할당 해제가 된다. 참고로, 일반적으로 참조 타입은 힙 영역, 값 타입은 스택 영역에 저장된다.

 

강한 참조를 하면 메모리 누수의 위험성이 존재한다. 이 부분까지 설명하면 글이 너무 길어지니 참고 링크로 대체하겠다.

[Swift] ARC-Strong Reference Cycle(강한참조사이클; 순환참조)

 

다음은 weak 참조에 대한 예시이다. 약한 참조를 사용하려면 weak 키워드를 붙여줘야 한다. weak 참조는 RC 값을 올리지 않는 참조 방식이다.

 

class Person {
    let name: String
    
    init(name: String) {
        self.name = name
        print("\(name) is being initialized")
    }
    
    deinit {
        print("\(name) is being deinitialized")
    }
}

var person1: Person?
weak var person2: Person?
weak var person3: Person?

person1 = Person(name: "Alice") // 강한 참조 -> RC: 1
person2 = person1 // 약한 참조 -> RC: 1
person3 = person1 // 약한 참조 -> RC: 1

person1 = nil // RC: 0 -> 메모리에서 할당 해제
print(person2) // nil
print(person3) // nil

 

이렇게 weak과 strong 참조에 대해서 알아봤는데 과연 IBOutlet과 무슨 관련이 있을까? 이 부분에 대해서 궁금증이 생겨 따로 공부해 봤다.

 

다음은 뷰 컨트롤러, 뷰(UIView) 그리고 뷰 위에 올라오는 UI 요소들(뷰 객체) 간의 참조 구조이다.

 

 

우선, 뷰 위에 UI 요소들이 올라와서 화면을 구성하기 때문에 뷰 컨트롤러가 살아있는 한 뷰는 없어지면(RC 값이 0) 안되므로 모든 뷰 컨트롤러는 자신이 관리하는 뷰에 대해 강한 참조를 유지하고 뷰도 자신의 하위 UI 요소들에 대해 강한 참조를 유지한다.

 

이때, IBOutlet으로 UI 요소를 연결할 때 strong 참조이냐 weak 참조이냐에 따라서 다음과 같은 RC 값이 형성된다.

IBOutlet 강한 참조

 

• 뷰 컨트롤러는 뷰를 강하게 참조한다 -> 뷰의 RC: 1
• 뷰는 UI 요소를 강하게 참조한다 -> UI 요소의 RC: 1
• 뷰 컨트롤러가 UI 요소를 강하게 참조한다 -> UI 요소의 RC: 2

 

IBOutlet 약한 참조

 

• 뷰 컨트롤러는 뷰를 강하게 참조한다 -> 뷰의 RC: 1
• 뷰는 UI 요소를 강하게 참조한다 -> UI 요소의 RC: 1
• 뷰 컨트롤러가 UI 요소를 약하게 참조한다 -> UI 요소의 RC: 1(변동 없음)

 

아까 위에서 말했듯 강한 참조를 사용하면 메모리 누수의 가능성이 존재한다. 하지만, 정상적인 경우에는 메모리 누수가 일어나지 않는다.

다음은 뷰 컨트롤러가 정상적으로 메모리 해제가 되었을 때의 RC 값이다.

 

• 뷰 컨트롤러가 메모리에서 해제되면서 뷰와 UI 요소에 대한 참조를 잃는다 -> 뷰의 RC: 0, UI 요소의 RC: 1(1 감소)
• 뷰가 메모리에서 해제되면서 UI 요소에 대한 참조를 잃는다 -> UI 요소의 RC: 0 (메모리 해제)

 

그러면 어떤 경우에 메모리 누수가 일어날까? 그리고 strong 참조와 weak 참조에 대한 사용 판단 기준이 무엇일까? 해당 내용도 일일이 다 설명하면 글이 길어질 것 같아 참고 링크로 대체하겠다.

 

iOS) IBOutlet연결 Strong VS Weak

 

이 모든 내용을 종합해 보았을 때, 메모리 누수를 막음으로써 성능을 높이고 싶다면 weak 참조를, 뷰 컨트롤러가 살아있는 한 UI 요소들이 값을 갖고 있도록 보장함으로써 의도치 않은 런타임 에러를 피하고 싶다면 strong 참조를 사용하면 되는 것 같다.

 

UIImageView!

@IBOutlet 프로퍼티의 타입을 지정해 주는 부분인데 어떤 UI 요소와 연결되었냐에 따라 타입이 변경된다. 위 코드에서 연결된 UI 요소는 UIImageView이므로 타입이 UIImageView로 설정되었는데 이때, 암시적 언래핑 옵셔널(IUO: Implicitly Unwrapped Optional)이 자동으로 붙는다. 이 부분에 대해서 궁금증이 생겨 따로 공부해 봤다.

 

왜 하필 옵셔널 타입?

Swift에서 클래스와 구조체가 초기화되어 각각의 인스턴스가 생성될 때까지 모든 저장 프로퍼티를 적절한 초기값으로 설정해야 한다. 이때, 초기화 중에 저장 프로퍼티가 어떤 값을 가져야 하는지 모르는 경우 기본값을 할당하거나 저장 프로퍼티를 옵셔널 타입으로 선언할 수 있다. IBOutlet 저장 프로퍼티에 연결된 UI 요소 값을 넘겨주는 시점은 뷰 컨트롤러가 초기화되고 나서 viewDidLoad() 메서드에서 이루어진다고 한다. 즉, 뷰 컨트롤러 클래스가 초기화되는 시점엔 IBOutlet 저장 프로퍼티에 어떤 값이 들어올지 결정이 안된 상태이므로 이를 위해 옵셔널 타입으로 선언한다고 한다.

 

왜 하필 IUO로 자동 선언?

이 부분은 옵셔널과 IUO의 사용 판단 기준에 대한 것과 연관이 있다. 언제 옵셔널을 사용하고, 언제 IUO을 사용할까? 보통 Swift 문법을 배울 때 IUO는 위험하니 되도록이면 안전성이 높은 옵셔널을 사용하라고 많이 들었을 것이다. 그럼에도 IUO 타입 변수를 사용하는 이유는 명확성(Clarity)과 편의성(Convenience) 때문이다. IUO 타입으로 선언된 변수는 옵셔널 바인딩이나 옵셔널 패턴 같이 지저분한 코드를 사용하지 않고도 값에 바로 접근할 수 있어 코드가 명확해지고 편리하다.

 

아래 예시는 간단한 IUO의 특징을 볼 수 있는 코드이다.

let a: Int!
print(a) // 따로 초기화 하지 않으면 nil

let b: Int! = 1

let c: Int = b // Optional로 사용되지 않으면 자동으로 언래핑된다.

let d: Int = b! // 위 결과와 같다.

let e = b // 타입을 따로 지정해주지 않으면 Optional 타입이다.

let f = b + 1 // 자동으로 언래핑되어서 연산을 수행한다.
print(f) // 2

let g: Int? = nil
print(a!) // nil 값에 대한 강제 언래핑은 컴파일 타임이 아니라 런타임에 오류가 나므로 주의!!!!!!

 

위 코드에서 변수 c와 f를 주목해서 보자. 옵셔널 타입 변수와는 다르게 IUO 타입 변수는 자동으로 강제 언래핑되어 원시 타입 변수처럼 행동할 수 있으므로 편리하다.

 

이번엔 변수 a와 g에 주목해 보자. 먼저, 변수 a에서 보듯 IUO 타입의 변수를 초기화하지 않으면 nil 값을 갖는다. 그다음, 변수 g에서 보듯 nil 값을 강제 언래핑하면 컴파일 타임이 아니라 런타임에 오류가 난다. 이 두 가지 특징을 기억하고 아래 글을 읽어보자.

 

이렇게 편리한 IUO 타입 프로퍼티를 사용하는 것에 대한 가장 큰 위험은 다음과 같다.

class Person {
    var age: Int!
}

let p: Person = Person()
print(p.age + 1)

 

위 코드를 간단하게 설명하면 아직 IUO 타입의 프로퍼티가 초기화되지 않은 상태에서 원시 타입 프로퍼티처럼 행동하게 했다. 변수 a, g에서의 특징을 기억한 사람이라면 분명 이 코드의 결과를 알 수 있을 것이다.

 

뷰 컨트롤러 클래스의 IBOutlet 프로퍼티도 마찬가지로 아직 뷰 컨트롤러의 viewDidLoad() 메서드가 불리지 않는 시점에서 IBOutlet 프로퍼티에 접근하는 상황이 발생하면 런타임 에러가 날 것이다. 컴파일 에러는 개발 단계에서 고치면 되지만 런타임 에러는 실제 서비스 중에 에러가 나므로 굉장히 치명적일 수 있기 때문에 주의해야 한다.

 

따라서, IUO 타입 프로퍼티를 사용할 때에는 이 점을 항상 생각하면서 그에 대한 대응 방식이 필요하다.

첫 번째 방식은 단순하게 IUO 타입을 사용하지 않고 옵셔널 타입을 사용해서 선언하는 것이다. 옵셔널 바인딩이나 옵셔널 패턴 등을 사용해서 명확성과 편리성을 버리고 안전성을 택하는 코드를 짜면 된다.

두 번째 방식은 옵셔널 체이닝을 사용하는 것이다.

diceImageViewOne?.image는 diceImageViewOne의 값이 nil이 아닐 때 image 프로퍼티에 접근하라는 의미이다. 옵셔널 체이닝을 사용해서 코드를 작성하면 원하는 결과를 얻지 못할 수도 있지만, 적어도 런타임 에러가 나지는 않는다.