서론 SwiftUI는 함수형 프로그래밍으로 직관적이고 가독성 높게 UI 로직을 작성할 수 있습니다. 특히 View의 구조를 바깥에서 안쪽으로 쉽게 파악할 수 있어 디버깅이 쉬우며 순수 함수로 로직을 구성하여 body 외부에서 발생할 수 있는 부작용을 최소화할 수 있습
앞선 포스팅에서 랜더링이 다시 일어남을 확인하는 방법, 모듈화를 통해 이를 해결하는 방법을 알아보았습니다.이번에는 이를 좀 더 깊이 알아보는 시간입니다.
1. 랜더링이 다시 일어남을 확인하는 방법 2. 모듈화를 통해 랜더링이 다시 일어나지 않도록 하는 방법 3. @State 값 변화에 랜더링이 다시 일어난다는 점을 활용하여 computed property를 @State 처럼 활용하는 방법
이를 통해 의미 없이 소모되던 **메인 스레드 점유 시간 104ms**와 **CPU 사용률 2.8%**를 절감할 수 있었습니다. 이 수치는 특히 애니메이션이나 반복 작업이 많은 환경에서 성능 향상에 큰 영향을 미쳤습니다.
부모 View에 카운터, 자식 View에도 카운터가 있는 View를 만들어 보았습니다.부모 View는 @State로 number 값을 변경하여 View를 업데이트합니다.자식 View는 @StateObject로 ViewModel을 가지고 있고, viewModel의 num
SwiftUI의 View는 Dynamic property의 상태값이 변하면 View를 다시 렌더링한다는 특징이 있습니다. 그러나, 값이 변하더라도 View를 다시 그리지 않아도 되는 경우에는 이런 특성이 오히려 불필요한 렌더링을 초래해 성능에 영향을 줄 수 있습니다.
SwiftUI는 새로운 View와 기존 View를 비교하고 변경된 부분만을 업데이트하여 성능을 최적화합니다.그렇다면, SwiftUI는 어떻게 비교하고 렌더링 여부를 결정할까요?이 글에서는 SwiftUI가 뷰를 어떻게 비교하고, 변경된 부분만 업데이트하는지에 대해 자세히
SwiftUI에서 View를 다시 그리기 위해 Dynamic property의 상태를 변경시켰습니다. 우리는 View의 렌더링 성능을 향상시키기 위해 각각의 Dynamic property를 담은 View로 모듈화 시키기도 했으며