Boost-SwiftUI-240716.txt

---

• 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를 사용해 최적화된 구조를 만드는 것이 좋다.
• 프로퍼티나 함수로 뷰를 구성할 때보다 구조체로 지정했을 때 최적화가 더 잘 이루어진다는 의견이 있다.