-
Notifications
You must be signed in to change notification settings - Fork 3
Boost‐SwiftUI‐2024年07月11日(목)
유정주 JeongJu Yu edited this page Oct 16, 2024
·
2 revisions
- 2024年07月11日 목 오후 9:53 ・ 46분 58초
- 이준복 권승용 윤동주 유정주 홍승현
- 클로버노트를 이용해 회의 내용을 기록하고, GPT를 이용해 요약, 편집했습니다.
- SwiftUI는 구조체와 실제 렌더링되는 뷰를 별도로 관리함
- 구조체: 뷰의 정의와 속성을 포함
- 뷰: 실제 화면에 그려지는 UI 요소
- 구조체의 생명주기
- 상태 변경 시 새로운 구조체 인스턴스가 생성되고 이전 인스턴스는 사라짐
- 이는 SwiftUI의 불변성(immutability) 원칙을 따르는 것
- SwiftUI 프레임워크가 뷰의 수명을 별도로 관리함
- 뷰 아이디 시스템
- 각 뷰에 고유한 아이디를 부여
- 아이디를 통해 뷰의 지속성과 업데이트를 추적
- 뷰의 내용을 정의하는 계산 프로퍼티
- 상태 변경 시 바디가 재호출됨
- 이는 뷰의 내용을 새로 계산하는 과정
- 변경된 부분만 효율적으로 업데이트
- 업데이트 결정 요인:
- 상태(State) 변경
- 바인딩된 값의 변경
- 환경(Environment) 값의 변경
- 상위 뷰의 상태 변경이 하위 뷰에 자동으로 전파되지 않음
- 하위 뷰가 업데이트되는 경우:
- 명시적으로 바인딩된 값이 변경될 때
- 하위 뷰가 상위 뷰의 상태를 직접 참조할 때
- 콘텐트 뷰:
- 상태 변경 시 바디가 재호출됨
- 내부 로직과 레이아웃이 업데이트됨
- A 뷰:
- 구조체 인스턴스는 여러 번 생성되지만 실제 렌더링된 내용은 변경되지 않음
- 이는 A 뷰가 변경된 상태에 의존하지 않기 때문
- 상위 뷰(콘텐트 뷰)의 레이아웃 변경이 하위 뷰(A 뷰)에 자동으로 반영되지 않음
- 이는 SwiftUI의 최적화된 렌더링 방식 때문
- 성능 최적화: 필요한 부분만 선택적으로 업데이트하여 리소스 사용 최소화
- 효율적인 메모리 관리: 불필요한 뷰 재생성 방지
- 빠른 UI 응답성: 최소한의 업데이트로 인한 신속한 화면 갱신
- 복잡성: 뷰 업데이트 메커니즘의 이해가 필요함
- 예측 어려움: 복잡한 뷰 구조에서 업데이트 동작 예측이 쉽지 않음
- UIKit과의 차이로 인한 학습 곡선
- 뷰를 적절한 크기로 분리하여 관리
- 각 뷰의 책임을 명확히 정의
- 상태(State)와 바인딩(Binding)을 효과적으로 사용
- 필요한 경우에만 상태를 공유하여 불필요한 업데이트 방지
- 가능한 한 작은 단위의 뷰로 분리하여 필요한 부분만 업데이트되도록 설계
-
@ObservedObject,@EnvironmentObject등을 적절히 활용하여 데이터 흐름 관리
- Xcode의 성능 프로파일링 도구를 활용하여 불필요한 뷰 업데이트 감지 및 최적화
- SwiftUI의 렌더링 방식은 성능과 효율성 면에서 큰 이점을 제공
- 개발자는 SwiftUI의 뷰 라이프사이클과 업데이트 메커니즘을 깊이 이해해야 함
- 복잡한 UI 구조에서는 더욱 신중한 설계와 테스트가 필요
- "Essentials in SwiftUI" 문서의 "SwiftUI에서의 뷰와 뷰의 역할" 챕터에서 추가 정보 확인 가능
- 구조체의 인스턴스 소멸: SwiftUI에서 구조체 인스턴스는 한 번 렌더링된 후 사라지지만, 필요할 때 다시 생성된다.
- SOT (Single Source of Truth): 상태가 변경되면 해당 상태를 사용하는 뷰들만 업데이트된다. 이는 프레임워크가 상태와 뷰를 연결해 관리하기 때문에 가능하다.
- 뷰의 계층 구조: 변경된 상태를 기준으로 필요한 부분만 다시 그려진다. 전체 뷰가 아닌 필요한 뷰만 업데이트되기 때문에 효율적이다.
- 뷰 모델의 생명 주기: 뷰 모델이 클래스일 경우, 특수한 상태 저장 프로퍼티 래퍼(StateObject 등)를 사용하지 않으면 사라질 수 있다.
- 뷰와 구조체의 생명 주기 관리: SwiftUI는 뷰의 생명 주기와 구조체의 생명 주기를 별도로 관리한다. 이는 효율적인 리렌더링을 위해 필요하다.
- 리렌더링 테스트: 특정 상태 변화 시 전체 뷰가 아닌 필요한 부분만 업데이트되는지 테스트 필요.
- 상태 바인딩: 상태를 바인딩하여 뷰의 일부분만 변경되는지 확인.
SwiftUI에서는 구조체 인스턴스가 렌더링된 후 사라지지만, 상태(SOT)가 변경되면 해당 상태를 사용하는 뷰만 다시 그려집니다. 이는 프레임워크가 상태와 뷰를 연결해 관리하기 때문에 가능합니다. 또한, 뷰 모델이 클래스일 경우, 특수한 상태 저장 프로퍼티 래퍼를 사용하지 않으면 사라질 수 있습니다. SwiftUI는 뷰의 생명 주기와 구조체의 생명 주기를 별도로 관리하여 효율적인 리렌더링을 지원합니다.
SwiftUI에서 뷰와 구조체의 관계를 이해하는 것이 중요합니다. 상태 변화 시 필요한 부분만 리렌더링하는 방식은 애플리케이션의 성능을 최적화하는 데 큰 역할을 합니다. 따라서 뷰의 계층 구조와 상태 관리에 대한 깊이 있는 이해가 필요합니다.