[SwiftUI/WWDC2021] View를 식별하고 업데이트하는 방법

SwiftUI 내부 작동 원리 이해하기

SwiftUI가 내부적으로 어떤 작업을 수행하는지 이해하기 위해서 코드를 볼 때 아래 세 가지를 유의해야 합니다.

• Identity: SwiftUI가 앱의 요소를 업데이트하기 위해서 요소를 동일하게, 또는 서로 다르게 인식하는 방법
• Lifetime: SwiftUI가 시간에 따라 뷰와 데이터의 존재를 추적하는 방법
• Dependencies: SwiftUI가 인터페이스를 언제 업데이트하고, 이를 이해하는 방법

 

View Identity

아래 사진에서는 화면 어디든 탭하면 상태를 전환할 수 있습니다.

아이콘에 초첨을 맞추어 보면, 서로 완전히 다른 뷰로 보는지 아니면 위치와 색상만 다를 뿐 같은 뷰로 보는지에 따라 인터페이스의 상태를 전환하는 방식이 달라집니다.

 

이것이 바로 View Identity의 핵심 개념입니다. 동일한 Identity를 공유하는 뷰는 동일한 UI 요소의 다양한 상태를 나타내고, 반면에 서로 다른 UI 요소를 나타내는 뷰는 항상 서로 다른 Identity를 갖습니다.

 

이 두가지 유형에 따라 뷰를 식별하는 두 가지 방법이 있습니다.

• Explicit Identity (명시적): 사용자 정의 또는 데이터 기반의 식별자를 사용합니다.
• Structural Identity (구조적): 뷰 계층 구조에서 뷰의 유형과 위치에 따라 뷰를 구별합니다.

 

Explicit Identity

같아보이는 여러 개체도 명시적으로 이름이나 식별자를 할당하여 해당 개체들을 추적할 수 있습니다.

 

UIKit과 AppKit 전체에 사용되는 포인터 Identity가 명시적 Identity의 한 형태입니다. UIKit과 AppKit의 NSView는 클래스이므로 각각 메모리 할당에 대해 고유한 포인터를 갖습니다. 개별 뷰는 포인터를 통해서만 참조되며 다른 뷰가 포인터를 공유하는 경우 실제로는 동일한 뷰를 바라보고 있음을 보장합니다.

 

하지만 SwiftUI는 포인터를 사용하지 않습니다. SwiftUI는 값 타입이며 일반적으로 구조체로 표현되기 때문입니다.

(왼) UIKit, AppKit (오) SwiftUI

 

SwiftUI는 뷰의 영구적인 Identity를 위한 참조가 없는 대신에 다른 형태의 명시적 Identity가 존재합니다. ForEach에 id 속성값을 통해 Identity를 설정하거나, id(:) 모디파이어와 scrollTo(:) 메소드를 통해서 뷰를 명시적으로 식별하고 특정 뷰로 이동하라고 알릴 수 있습니다.

 

이처럼 모든 뷰를 식별할 필요 없이 코드의 다른 곳에서 참조해야 하는 뷰만 식별하면 되는 장점이 있습니다.

 

Structural Identity

SwiftUI는 뷰 계층 구조를 사용하여 암시적으로 Identity를 생성하고, 뷰의 유형과 위치에 따라서 뷰를 결정하고 식별합니다. SwiftUI는 API 전체에서 Structural Identity를 사용하며, 대표적으로 View 코드 내에서 if문과 같은 조건문에서 사용합니다.

 

하지만 이 방법은 뷰의 위치가 정적일 때만 작동하고 각 분기의 뷰가 서로 다른 Identity를 가지게 됩니다.

 

if문 코드를 참/거짓 정보를 가지는 하나의 제네릭 타입의 뷰인 _ConditionalContent로 변환합니다. 이는 ViewBuilder 기반으로 수행되며, View 프로토콜에서는 body 프로퍼티를 암시적으로 ViewBuilder로 래핑하여 하나의 단일 뷰로 구성합니다.

 

따라서 이 제네릭 타입을 사용하여 SwiftUI는 True인 뷰가 항상 AdoptionDirectory이고, False인 뷰가 항상 DogList가 되도록 암시적으로 Identity를 할당합니다.

 

SwiftUI는 아래 두 가지 방법 모두 작동하지만 일반적으로 두 번째 방법인 단일 Identity을 유지하면서 유연하게 인터페이스를 전환하는 방법을 권장하고 있습니다.

이는 뷰의 Lifetime과 상태를 보존하는 데 도움이 되기 때문입니다.

 

AnyView 사용을 지양할 것

만약 각 조건 분기에 서로 다른 View를 반환한다고 가정한다면, 함수의 리턴 타입은 하나일 것이기 때문에 그 타입을 맞춰주기 위해 AnyView로 래핑하게 될 것입니다.

 

하지만 이러한 구조는 Static type 정보를 숨겨 컴파일러가 알 수 없기 때문에 오류와 경고가 표시되지 않을 수 있습니다. 성능이 저하될 수 있고, 가독성이 매우 떨어집니다.

 

따라서 AnyView를 제거하여 코드를 단순화하고, ViewBuilder를 통해 단일 뷰로 래핑하여 코드를 수정할 수 있을 것입니다.

 

View Lifetime

Identity가 뷰와 데이터의 수명과 어떻게 연결되는지 알아보면서 SwiftUI의 작동 방식을 이해할 수 있습니다.

• 뷰의 값은 일시적이므로 Lifetime에 의지해서는 안 된다.
• 뷰의 Lifetime은 일시적이지 않기 때문에 시간이 지나도 연속성을 부여해야 한다.
• 뷰의 Identity는 제어가 가능하며, 뷰의 Lifetime을 명확히 할 수 있다.
• SwiftUI는 Identifiable 프로토콜을 최대한 활용하므로 데이터에 대한 안정적인 식별자를 선택하는 것이 중요하다.

 

View Value와 View Identity는 다르다.

뷰의 값은 일시적인 것이므로 Lifetime에 의존해서는 안 됩니다.

뷰는 Lifetime 동안 다른 상태 값을 가질 수 있지만 동일한 Identity를 갖는 이상 동일한 뷰로 인식합니다.

 

뷰의 수명은 뷰와 연결된 Identity의 지속기간이다.

뷰의 Lifetime이란 뷰의 Identity가 지속되는 기간을 의미합니다.

따라서 뷰의 Identity 수명을 뷰의 수명과 연결 짓는 것이 SwiftUI가 뷰의 상태를 유지하는 방법을 이해하는 것입니다.

 

뷰가 처음 생성되고 나타날 때 SwiftUI는 암시적 Identity를 통해 뷰의 Identity를 할당합니다. 시간이 지나 업데이트 되어 뷰에 대한 새로운 값이 생성되어도 SwiftUI 관점에서는 동일한 뷰입니다. 뷰의 Identity가 변경되거나 뷰가 제거되면 Lifetime이 종료됩니다.

 

State 수명과 View의 수명은 동일합니다.

아래 예제에서 SwiftUI는 처음 조건 분기에 진입하면 초기값을 사용하여 영구 저장소에 상태 값을 할당합니다.

하지만 조건 값이 바뀌고 브랜치가 바뀌면 이에 해당하는 저장소가 새로 생성되고 이전의 저장소는 할당이 해제됩니다.

 

SwiftUI가 뷰를 처음 생성할 때 초기값을 State나 StateObject에 대한 메모리 저장소에 할당합니다. 뷰의 Lifetime 동안 뷰가 변형되고 body가 재평가되어도 이 저장소는 유지됩니다.

 

Identifiable 프로토콜

SwiftUI는 데이터의 Identity를 뷰의 명시적 Identity로 사용하는 몇 가지 데이터 기반 구조를 가지고 있는데, 대표적인 예로 ForEach가 있습니다.

 

ForEach는 일반적으로 고정된 범위 내에서 Identity를 안정적으로 보장해주지만, 동적인 컬렉션을 위해서는 ForEach의 id 속성을 통해 요소에서 생성된 모든 뷰에 Identity를 할당해야 합니다. ForEach의 id 속성은 해시가 가능해야 합니다.

KeyPath로 가능하나, Identifiable 프로토콜을 채택하여 데이터가 안정적인 Identity를 얻어올 수 있습니다.

 

Dependency

dependency는 단순하게 뷰에 대한 입력입니다. dependency가 변경되면 뷰에서 새로운 body를 생성해야 합니다.

body는 뷰에 대한 계층 구조(hierarchy)를 빌드하는 영역이고, action은 뷰의 dependency를 변경하는 트리거입니다.

 

dependency의 종류에는 여러 가지가 있습니다. 여러 가지 프로퍼티 래퍼를 사용하여 dependency를 형성할 수 있습니다.

• Binding
• Environment
• State
• StateObject
• ObservedObject
• EnvironmentObject

 

Dependency graph

위 코드를 다이어그램으로 나타내면 트리 구조 형태로 나타낼 수 있습니다. 하지만 동일한 상태나 다른 데이터에 따라 여러 가지 뷰가 존재할 수 있습니다.

 

결과적으로 사실 그래프의 구조를 형성하고 있습니다.

뷰는 값 타입이므로 SwiftUI는 뷰의 올바른 하위 집합만 업데이트하기 위해 뷰를 효율적으로 비교할 수 있고, 새 body가 필요한 뷰만 효율적으로 업데이트할 수 있습니다.

 

Explicit Identity에서의 고려 사항

Lifetime에서 이야기했듯이 뷰의 수명은 뷰의 Identity의 지속 시간이며, 이는 식별자의 안정성이 매우 중요합니다.

 

Identifier stability

안정적인 식별자를 사용하면 SwiftUI가 뷰에 대한 저장소를 지속적으로 관리하기 위해 Lifetime을 이용하기 때문에 상태의 손실을 방지할 수 있고, 저장소를 새로 생성하거나 그래프를 업데이트할 필요가 없기 때문에 성능도 향상됩니다.

 

아래 코드에서 Identifier로 UUID를 사용하거나 배열의 인덱스 id인 indices를 사용하고 있습니다.

이는 안전하지 않습니다. UUID를 사용하면 데이터가 변경될 때마다 새로운 ID를 얻게 되고, indices를 사용하면 마지막 위치의 인덱스에 개체가 삽입되기 때문에 ID가 변경되기 때문입니다.

 

databaseID 등과 같이 고유한 값을 ID로 사용하여 안전하게 만들 수 있습니다.

 

Identifier Uniqueness

아래 코드에서 name을 ID로 사용하고 있습니다. 이름은 고유하지 않기 때문에 문제가 됩니다.

 

시리얼 넘버와 같은 고유한 ID를 사용하는 것이 더 나은 애니메이션과 성능이 보장됩니다. SwiftUI에서 모든 Identifier는 변경되지 않고 안정적이며 고유한 값을 가져야 합니다.

 

Structural Identity에서의 고려 사항

아래 코드에서 브랜치를 통해 뷰가 분기되어 있습니다. 즉 각각의 뷰는 서로 다른 뷰라는 것을 알 수 있습니다.

 

분기 조건은 modifier에 있기 때문에 modifier 내부에 조건문을 옮겨 새로운 뷰 Identity가 생기는 문제를 피할 수 있습니다.

 

브랜치를 추가할 때는 여러 뷰를 표현하는지, 단일 뷰의 두 가지 상태를 표현하는지 고려해야 할 필요가 있습니다.

브랜치는 훌륭하며 존재하는 데 이유가 있지만, 불필요하게 사용하면 성능 저하, 애니메이션 문제 등이 발생할 수 있고, 상태의 손실까지 발생할 수 있습니다.

 

---

 

WWDC

https://developer.apple.com/videos/play/wwdc2021/10022/

Demystify SwiftUI - WWDC21 - Videos - Apple Developer