Boost‐SwiftUI‐2024.07.16(화)
- 2024.07.16 화 오후 9:01 ・ 81분 0초
- 권승용 유정주 홍승현 이준복 김대황
- 클로버노트를 이용해 회의 내용을 기록하고, GPT를 이용해 요약, 편집했습니다.
- SwiftUI는 구조체와 실제 렌더링되는 뷰를 별도로 관리함
- 구조체: 뷰의 정의와 속성을 포함
- 뷰: 실제 화면에 그려지는 UI 요소
- 구조체의 생명주기:
- 상태 변경 시 새로운 구조체 인스턴스가 생성되고 이전 인스턴스는 사라짐
- SwiftUI의 불변성(immutability) 원칙을 따름
- 뷰의 수명 관리:
- SwiftUI 프레임워크가 별도로 관리
- 뷰 아이디 시스템을 통해 각 뷰에 고유한 아이디 부여
- 아이디를 통해 뷰의 지속성과 업데이트를 추적
- 바디(body) 프로퍼티의 역할:
- 뷰의 내용을 정의하는 계산 프로퍼티
- 상태 변경 시 바디가 재호출되어 뷰의 내용을 새로 계산
- 선택적 업데이트 시스템:
- 변경된 부분만 효율적으로 업데이트
- 업데이트 결정 요인:
- 상태(State) 변경
- 바인딩된 값의 변경
- 환경(Environment) 값의 변경
- 하위 뷰의 업데이트 동작:
- 상위 뷰의 상태 변경이 하위 뷰에 자동으로 전파되지 않음
- 하위 뷰가 업데이트되는 경우:
- 명시적으로 바인딩된 값이 변경될 때
- 하위 뷰가 상위 뷰의 상태를 직접 참조할 때
- 구조체를 사용한 뷰 분리 vs 뷰빌더(@ViewBuilder) 사용:
- 구조체 사용:
- 장점: 명확한 캡슐화, 재사용성 증가
- 단점: 데이터 전달을 위한 추가 코드 필요
- 뷰빌더 사용:
- 장점: 간결한 코드, 상위 뷰의 프로퍼티 직접 접근 가능
- 단점: 뷰 구조가 복잡해질 수 있음
- 구조체 사용:
- 성능 최적화 관점:
- 구조체로 뷰를 분리할 때 SwiftUI의 뷰 업데이트 최적화가 더 잘 동작할 수 있음
- 애니메이션 처리 시 구조체로 분리된 뷰가 더 안정적일 수 있음
- 뷰 컨트롤러, 뷰 모델, SwiftUI 뷰의 관계 설정:
- 뷰 컨트롤러가 뷰 모델을 소유하고, SwiftUI 뷰에 전달하는 구조 제안
- 데이터 흐름: 뷰 -> 뷰 컨트롤러 -> 뷰 모델
- 이벤트 전달 방식:
- Published 프로퍼티나 Combine 프레임워크의 Subject 사용 고려
- 클로저를 통한 콜백 방식도 가능하나, 복잡성 증가 우려
- MVI (Model-View-Intent) 패턴:
- SwiftUI에 적용 가능한 반응형 아키텍처
- 단방향 데이터 흐름으로 상태 관리 용이
- TCA (The Composable Architecture):
- 복잡한 앱에 적합한 아키텍처
- 상태 관리, 의존성 주입, 테스트 용이성 제공
- UIKit과의 통합 시 추가적인 노력 필요
- SwiftUI의 장점:
- 선언적 UI 구현으로 코드 간결화
- 자동화된 성능 최적화
- UIKit의 장점:
- 더 많은 커스터마이징 옵션
- 기존 프로젝트와의 호환성
- 적절한 뷰 캡슐화:
- 뷰를 적절한 크기로 분리하여 관리
- 각 뷰의 책임을 명확히 정의
- 상태 관리의 중요성:
- 상태(State)와 바인딩(Binding)을 효과적으로 사용
- 필요한 경우에만 상태를 공유하여 불필요한 업데이트 방지
- 뷰 업데이트 최적화:
- 작은 단위의 뷰로 분리하여 필요한 부분만 업데이트되도록 설계
- @ObservedObject, @EnvironmentObject 등을 적절히 활용
- 성능 모니터링:
- Xcode의 성능 프로파일링 도구를 활용하여 불필요한 뷰 업데이트 감지 및 최적화
- SwiftUI의 렌더링 방식은 성능과 효율성 면에서 큰 이점 제공
- 개발자는 SwiftUI의 뷰 라이프사이클과 업데이트 메커니즘을 깊이 이해해야 함
- 복잡한 UI 구조에서는 더욱 신중한 설계와 테스트가 필요
- 새로운 아키텍처 패턴(MVI, TCA 등)의 도입을 고려할 수 있으나, 프로젝트 특성에 맞게 선택해야 함
- SwiftUI와 UIKit의 장단점을 고려하여 프로젝트에 적합한 기술 선택 필요
- SwiftUI와 UIKit의 장단점을 비교하며, SwiftUI의 장점과 단점을 논의함.
- UIKit으로 해결할 수 있는 문제들을 SwiftUI로 구현할 때의 어려움을 공유.
- SwiftUI의 프레임 처리와 스크롤 뷰에서의 빈 공간 처리 문제를 해결하는 방법을 고민함.
- TCA를 사용하는 것에 대해 논의, TCA를 SwiftUI와 UIKit에서 어떻게 사용할 수 있는지 검토.
- TCA와 관련된 참고 자료의 부족으로 인해 학습의 어려움을 공유함.
- TCA의 라이브러리 특성보다는 디자인 패턴으로 접근하는 방법을 제안.
- 뷰 모델과 뷰 컨트롤러의 역할을 구분하여 사용하려는 시도.
- 뷰 모델을 뷰 컨트롤러와 뷰에서 어떻게 분리할 것인지에 대해 논의.
- 회사 프로젝트에서 호스팅 뷰 컨트롤러를 사용해야 하는 이유와 그에 따른 구조 설계.
- 각 뷰마다 이벤트를 처리하는 문제에 대한 고민을 나눔.
- 퍼블리시드를 사용하여 뷰 모델과 뷰 간의 데이터 흐름을 설정하는 방법을 논의.
- 이벤트 처리의 딜레마와 이를 해결하기 위한 방법들에 대해 의견을 나눔.
- 개인 프로젝트와 회사 프로젝트에서 사용하는 기술과 라이브러리에 대해 공유.
- 회사 프로젝트에서 TCA를 사용하는 경험을 바탕으로 한 의견 교환.
- 개인 프로젝트에서 TCA를 사용하며 겪은 문제와 해결 방안에 대해 논의.
- UI를 구현하는 과정에서 발생하는 다양한 문제에 대해 논의.
- 프레임을 사용하여 UI 요소를 배치하는 방법과 그로 인한 문제 해결.
- 스크롤 뷰와 프레임 설정 시 발생하는 빈 공간 문제를 해결하는 방법을 공유.
- 공식 문서와 오픈 소스 자료를 활용한 학습 방법을 공유.
- 강의나 멘토링을 통해 학습할 수 있는 방법을 제안.
- 다양한 참고 자료와 학습 자료의 활용에 대해 논의.
- 캘린더 UI에서 빈 공간을 처리하는 문제를 논의했다.
- UIKit에서는 오토레이아웃으로 공간을 채울 수 있지만, SwiftUI에서는 뷰의 크기가 콘텐츠에 따라 변동되어 빈 공간이 생길 수 있다.
- ScrollView를 사용하면 의도하지 않은 스크롤이 발생할 수 있다.
- 이를 해결하기 위해 프레임 지정, 색상 저장 등 빈 공간을 채우는 방안을 토의했다.
- 상단에 round를 적용하고, 하단에 뷰를 추가하는 방법을 논의했다.
- 백그라운드 색상을 적용해 빈 공간을 채우는 방법을 시도했지만, 구현 결과가 만족스럽지 않았다.
- 뷰의 백그라운드 컬러를 회색으로 설정하고, 루트 뷰의 백그라운드 컬러를 회색으로 맞추는 방안을 선택했다.
- 뷰를 분리할 때 private 구조체로 정의하거나 @ViewBuilder를 사용하는 방법에 대해 논의했다.
- 구조체가 최적화에 더 유리하지만, @ViewBuilder는 별도의 프로퍼티 전달을 하지 않아도 된다.
- 구조체 분리와 @ViewBuilder의 애니메이션 차이가 있다.
- @ViewBuilder는 다른 뷰에서 재사용할 가능성이 없을 때 고려할 수 있다.
- SwiftUI와 UIKit의 장단점을 비교했다.
- SwiftUI는 선언형 문법으로 코드 양이 줄어들고, 직관적인 UI 설계가 가능하다.
- 일부 UI 구성 요소의 동작이 UIKit과 다르게 작동해 추가적인 고민이 필요하다.
- UIKit에서는 쉽게 해결할 수 있는 문제가 SwiftUI에서는 복잡해질 수 있다.
- 뷰 빌더를 사용하여 뷰를 최적화하고, 리스트 안에 여러 뷰를 효율적으로 배치하는 방법을 논의했다.
- 뷰 빌더를 사용하면 depth가 1인 구조로 작성할 수 있다. List의 재사용 최적화를 노릴 수 있다.
- 리스트 안에서 뷰 빌더를 사용해 배열 형태로 구성하는 것이 효과적이다.
- AnyView를 사용하면 뷰의 최적화가 저하될 수 있다. 따라서 AnyView 대신 @ViewBuilder를 사용해 최적화된 구조를 만드는 것이 좋다.
- 프로퍼티나 함수로 뷰를 구성할 때보다 구조체로 지정했을 때 최적화가 더 잘 이루어진다는 의견이 있다.
| 권승용 | 김대황 | 김인환 | 유정주 | 윤동주 | 이준복 | 이창준 | 홍승현 |
|---|---|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
| ericKwon95 | qwerty3345 | loinsir | jeongju9216 | yoondj98 | junbok97 | SwiftyJunnos | WhiteHyun |