SwiftUI - View를 구조체로 생성하는 이유

안녕하세요. 그린입니다🍏

저번 포스팅에서는 SwiftUI의 View 프로토콜에 대해 알아봤어요!

혹시 안보셨다면 아래 포스팅을 먼저 보고 오시면 더 도움이 됩니다🙌

https://green1229.tistory.com/314

SwiftUI - View

 

저번 포스팅 말미에 우리가 SwiftUI에서 View를 정의할때 구조체로 정의하는 이유에 대해 알아본다고 했었습니다😄

오늘 그거 한번 알아보시죠 :D

 

오늘 포스팅은 구조체와 클래스가 무엇인지 그리고 차이를 알고 있다는 가정하에 진행됩니다.

혹시 둘의 개념이 오랜만이라 헷갈린다면 아래 포스팅을 간단히 참고해주세요!

https://green1229.tistory.com/17

구조체와 클래스

 

그럼 진짜 짧지만 알차게 바로 ㄱㄱ🕺🏻

 

View를 구조체로 생성하는 이유

우선 당연하겠지만 성능 이슈가 있습니다.

 

UIKit에서의 클래스 뷰

UIKit 세상과 같이 비교해보겠습니다🙋🏻

UIKit에서 UIView는 제약, 배경, 렌더링을 위한 레이어, 정렬 방법 등 수많은 속성과 메서드가 있는 클래스의 서브 클래스입니다.

그런데 우리가 실제 사용하는 UIKit에서의 뷰들은 또 UIView를 상속받은 서브 클래스죠.

당연하게도 이렇다보니 간단한 뷰를 만들더라도 사용하던 안하던 그 안에 담긴 속성들은 이미 많은 상태인것이죠.

즉 크기가 커지게 되죠.

 

SwiftUI에서의 구조체 뷰

그럼 반대로 SwiftUI에서는 구조체로 뷰를 생성합니다.

SwiftUI 내 기본 제공되는 모든 뷰 컴포넌트들은 작던 크던 구조체이며 자유롭게 생성할 수 있죠.

UIKit과 반대로 상위로 부터 오는 어떠한 상속된 값도 없이 딱 생성하려는 그 구조체만큼의 크기를 가집니다.

배경 및 색상과 같이 속성을 가져야 한다면 SwiftUI에서는 상속으로 다 들고 있는것이 아니라 ViewModifier를 사용합니다.

뷰 모디파이어를 통해 속성을 부여해 새로운 뷰를 만드는것이죠.

 

이 근본적인 클래스와 구조체의 성능 차이가 SwiftUI에서 View를 구조체로 생성하는 첫번째 이유입니다.

(아주 뷰 자체가 라이트해집니다!)

 

두번째로, 클린한 상태를 유지할 수 있습니다.

어떻게 다른곳에서도 변경될 수 있는지 없는지에 대한 의견입니다.

UIKit은 클래스의 뷰를 생성함으로 어떤곳에서 같이 참조한다면 내부 값을 쉽게 바꿀 수 있는 형태죠.

즉, 모든 뷰 상태를 체크하며 변화가 일어날지 신경써야 합니다.

반면 SwiftUI는 구조체로 딱 해당 뷰를 정의하고 생성하는곳에서만 사용될것이라 그 부분만 신경쓰면 되죠.

값 타입이기에 가능합니다.

그렇기에 단위적으로 쉽게 확인 할 수 있고 수정 및 테스트에 용이합니다.

SwiftUI에서는 값이 변경되는 시점도 기능적인 디자인 접근 방식으로 이동하는걸 애플은 권장합니다.

쉽게 말해 독립적인 뷰 단위를 가지고 판단할 수 있는것이 편리하죠.

 

이에 더불어 추가적으로 메모리 관리도 효율적입니다.

클래스는 ARC를 통해 메모리 관리가 되지만 참조 타입임으로 인스턴스 생성 시 메모리를 잡게 되죠.

그러니 사용되지 않는데 실제 해제가 되지 않고 메모리 누수가 나는 경우가 있을겁니다.

반면 SwiftUI의 뷰는 구조체로 값 타입의 특성으로 실제 사용이 될때 COW(Copy On Write)되어 메모리가 할당됨으로 메모리에도 효율적이고 참조가 아님으로 메모리가 누수 될 경우가 없습니다.

즉, 메모리 성능에서도 이러한 차이를 보이게 됩니다.

 

결국 이 모든 차이와 효율을 가지고 SwiftUI의 뷰는 구조체로 정의되어 있습니다.

만약 SwiftUI에서 클래스를 사용해 뷰를 생성한다면 컴파일 혹은 런타임 시 충돌이 발생할 것입니다⚠️

 

가장 중요한 부분

"물론 여기서 가장 중요한 점!"

SwiftUI가 UIKit보다 성능이 빠르다는건 아닙니다.
실제로 대부분의 경우에서는 UIKit이 SwiftUI보다 성능적인 측면에서 이점을 가져간다고 아래 연구 결과도 있더라구요.
https://kth.diva-portal.org/smash/get/diva2:1789094/FULLTEXT01.pdf
(관심 있으면 보시길...)

그래서 결론적으로는 해당 포스팅에서 알아본건 SwiftUI를 왜 클래스가 아닌 구조체로 만들었을까에 대한 고찰입니다.
실제로 SwiftUI는 UIKit을 조금 더 사용하기 쉽게 래핑해놓은 느낌으로 볼 수 있고 그 근간에는 UIKit을 기반으로 개발되었으니까요 😃

근데 사실 애플에서 WWDC를 통해 발표하는걸 보면 SwiftUI를 UIKit보다 성능적으로 더 뛰어나도록 설계했다곤 하는데, 실제 실험 결과가 그렇지 않으니 더 발전해나가야되지 않을까라는 생각도 듭니다.

그런데 애니메이션이 많거나 상태 관리에 관해서는 SwiftUI가 더 높은 성능을 가질 수 있습니다.

즉, SwiftUI하고 UIKit의 성능에서는 상황마다 우수한게 다르지만 일반적으로 대부분의 경우는 UIKit이 좀 더 성능적 이점을 가지는 느낌입니다.
UIKit은 수년간 계속 최적화가 되고 했기에 당연한 결과일것 같지만, 앞으로는 SwiftUI 업데이트가 더 빠르게 일어나고 있기에 점차 실제로 성능 차이가 줄어들고 있고 머지않아 따라잡지 않을까? 라는 생각도 듭니다.

결론적으로 프로젝트 상황과 개발자의 니즈들에 따라 선택을 하는것이 좋겠습니다 😀

 

마무리

이번 포스팅에서는 왜? 2탄으로 막연히 당연하게 인지했던 부분을 조금 글로 정리해봤습니다!

왜? 3탄은 어떤걸로 정할지 아직은 못정했어요

 

[참고 자료]

https://www.hackingwithswift.com/books/ios-swiftui/why-does-swiftui-use-structs-for-views

Why does SwiftUI use structs for views? - a free Hacking with iOS: SwiftUI Edition tutorial

https://developer.apple.com/videos/play/wwdc2019/216/

SwiftUI Essentials - WWDC19 - Videos - Apple Developer