[번역] Performance analysis of SwiftUI and UIKit (SwiftUI와 UIKit의 성능 분석)

 

원문 (Performance analysis of SwiftUI and UIKit)

소개

스마트폰은 우리 일상 생활의 중요한 부분이며 다양한 작업을 위해 이러한 장치에 의존하고 있습니다. 모바일 폰의 인기가 계속 증가함에 따라, 프리미엄 사용자 경험을 제공하는 고품질 애플리케이션에 대한 수요가 증가하고 있으며, 이는 앱 개발 환경에서 매우 경쟁적인 분위기를 조성하고 있습니다. 사용자 인터페이스(UI) 프레임워크는 애플리케이션이 점점 더 복잡해짐에 따라 현대적이고 사용자 친화적인 앱을 개발하는데 중요한 역할을 합니다. 높은 성능의 애플리케이션을 만드는 도전은 고성능 UI 프레임워크의 사용을 필요로 합니다. iOS 생태계는 계속해서 확장되고 진화해왔으며, 개발자를 위한 다양한 프레임워크와 도구가 등장했습니다. 이 중에서 UIKit과 SwiftUI는 iOS 개발을 위한 두 가지 네이티브 UI 프레임워크입니다. UIKit은 버튼과 이미지와 같은 포괄적인 UI 요소 세트와 이벤트 처리 기능을 제공합니다. 반면에 SwiftUI는 애플 플랫폼에서 소프트웨어 개발 과정을 혁신적으로 단순화하는 새로운 접근 방식을 통해 UI를 디자인하는 방법을 크게 간소화했습니다. 그럼에도 불구하고 SwiftUI의 성능 특성은 상대적으로 알려지지 않았습니다. 따라서 본 연구에서는 iOS에서 UIKit과 비교하여 SwiftUI의 성능을 분석하고 잠재적인 병목 현상 및 최적화 기회를 찾아내고자 합니다.

문제

성능은 사용자 경험의 중요한 부분입니다. 긴 로딩 시간이나 사용자 상호작용 중 지연과 같은 성능 저하로 인해 경험이 저하되면 애플리케이션이 느리거나 반응하지 않는 것처럼 느껴져 사용자 불만을 초래하고 사용자가 앱을 포기할 수도 있습니다. 예를 들어, 전자상거래 애플리케이션의 시나리오를 고려해 보세요: 제품 페이지가 로딩하는 데 시간이 너무 오래 걸리면 판매 기회를 놓칠 수 있습니다. 마찬가지로, 소셜 미디어 애플리케이션에서 새 게시물이 표시되는 데 지연이 발생하면 사용자의 경험이 방해받아 사용자 참여율이 감소할 수 있습니다. 따라서 효과적인 UI 프레임워크는 기능이 풍부하고 사용자 친화적일 뿐만 아니라 좋은 성능도 제공해야 합니다. 이에 따라, 본 연구의 주요 목표는 SwiftUI와 UIKit의 성능 능력을 깊이 탐구하는 것이며, 텍스트, 버튼, 이미지 등과 같은 일반적인 UI 요소에 대한 중앙 처리 장치(CPU) 시간과 메모리 사용량과 같은 지표에 특히 초점을 맞춥니다. CPU 시간을 성능 지표로 선택하는 것은 UI의 유동성과 반응성과의 직접적인 관계 때문입니다. 높은 CPU 시간은 애니메이션의 끊김이나 지연을 유발할 수 있어 만족스럽지 못한 사용자 경험을 초래할 수 있습니다. 마찬가지로 버튼과 같은 대화형 요소가 반응하지 않게 되어 UI의 품질이 더욱 저하될 수 있습니다. 메모리 사용량은 프레임워크의 메모리 사용량이 높으면 복잡한 뷰를 가진 앱이 메모리 제한으로 인해 구형 기기에서 실행되지 않을 수 있기 때문에 메트릭으로 사용됩니다. SwiftUI가 탄력을 받고 업계 전반에 걸쳐 계속해서 채택됨에 따라 UIKit과 비교하여 그 성능을 평가하는 것이 더욱 중요해졌습니다. SwiftUI의 장단점을 조사함으로써 개발자는 앱 개발 요구에 가장 적합한 프레임워크를 선택할 수 있습니다. 이 프로젝트의 주요 목표는 아래에 제시된 연구 질문을 해결하면서 SwiftUI와 UIKit의 성능을 탐구하는 것입니다:

목적

SwiftUI의 인기가 높아지고 있음에도 불구하고, 그 성능 특성에 초점을 맞춘 학술 연구는 부족합니다. 따라서, 이 논문의 목표는 SwiftUI와 UIKit의 성능을 평가하고 개선할 영역을 찾는 것입니다. SwiftUI는 UIKit(2008년)에 비해 더 최근의 프레임워크(2019년)로, 더 나은 성능을 보일 것으로 예상됩니다. 이 연구는 iOS 앱 개발을 둘러싼 지속적인 대화에 기여하고자 하며, 모바일 애플리케이션의 끊임없이 변화하는 세계에서 SwiftUI와 UIKit을 사용함으로써 얻는 비교적 장단점에 대해 논의합니다. 이 정보는 iOS 앱 개발에 참여하거나 관심이 있는 개발자, 조직 및 연구자들에게 특히 유익합니다. SwiftUI와 UIKit 사이의 성능 차이에 대한 철저한 이해를 통해, 그들은 특정 프로젝트에 가장 적합한 프레임워크를 선택하는 데 있어 정보에 근거한 결정을 내릴 수 있을 뿐만 아니라 기존 애플리케이션을 최적화하는 방법에 대한 지침을 제공할 수 있습니다. 이 연구의 결과는 Apple과 다른 개발자들에 의한 미래 UI 프레임워크의 개발에 영향을 미치고 정보를 제공할 수 있습니다. 한 프레임워크가 다른 프레임워크보다 우수한 성능을 보이는 영역을 강조함으로써, 이 연구는 미래의 프레임워크 발전과 혁신을 안내하는 통찰력을 제공합니다.

목표

이 연구의 주요 목표는 CPU 시간과 메모리 사용량이라는 두 가지 중요한 성능 측면에 초점을 맞춰 SwiftUI와 UIKit의 성능을 검토하는 것입니다. 이 목표는 다음과 같은 부목표로 나뉩니다:

1. 일반적인 UI 요소 식별: iOS 애플리케이션에서 일반적으로 사용되는 UI 요소를 이해하는 것은 SwiftUI와 UIKit을 비교하는 데 중요합니다. 이를 위해 이 프로젝트가 진행되는 호스팅 회사에서 iOS 개발자들과의 인터뷰를 실시하여, 해당 회사가 개발한 iOS 앱에서 자주 사용되는 UI 요소를 파악합니다.
2. 두 개의 벤치마킹 iOS 앱 개발: 일반적인 UI 요소를 포함하는 두 개의 벤치마킹 앱을 만듭니다. 하나의 앱은 UIKit을 사용하여 독점적으로 설계되며, 다른 하나는 전적으로 SwiftUI로 제작됩니다. 이 앱들은 UIKit과 SwiftUI에 대한 성능 데이터를 측정하고 수집하는 기반을 제공합니다.
3. 개발된 벤치마킹 앱에서 성능 데이터 수집: 벤치마킹 앱을 대상으로 한 자동화된 UI 테스트를 다양한 iOS 기기에서 실행하여 성능 데이터를 수집합니다. 호스팅 회사는 개발된 벤치마킹 앱을 실행하고 프레임워크에 대한 성능 정보를 수집할 수 있는 다양한 iOS 테스트 기기에 대한 접근을 제공합니다.
4. 획득한 데이터 분석 및 평가: 수집된 측정값은 호스팅 회사의 감독자 및 엔지니어와 논의됩니다. 이 과정에서 그들의 통찰력과 권장 사항을 고려하여 정보에 입각한 결론을 도출합니다.

윤리 및 지속 가능성

SwiftUI가 iOS 개발의 최신 프레임워크를 대표함에 따라, 기업들이 이 기술을 채택하려는 움직임은 자연스러운 일입니다. 그러나 SwiftUI의 성능이 UIKit에 미치지 못한다면, 이보다 최근의 프레임워크를 사용하여 개발된 앱은 특히 구형 기기에서 느리게 실행될 수 있습니다. 그 결과, 소비자들은 현재의 기기가 SwiftUI 기반 애플리케이션을 지원하는 데 필요한 하드웨어 성능을 갖추지 못했기 때문에 새로운 기기를 구매해야 할 수도 있습니다. 프레임워크 채택만으로 새 휴대폰을 구입하는 것은 증가된 생산, 이어지는 CO2 배출 및 지구 온난화에 기여하기 때문에 지속 가능한 관행이 아닙니다. 또한 사용자에게 새 휴대폰 구매를 강요하는 것은 모든 사람이 비용을 감당할 수 있는 것은 아니므로 기술 접근성을 떨어뜨릴 수 있는 윤리적 문제를 제기합니다. 프레임워크의 성능은 지속 가능성에도 중요합니다. SwiftUI가 UIKit보다 더 많은 계산 자원을 요구한다면, SwiftUI를 사용하여 개발된 앱이 더 많은 에너지를 소비할 수 있음을 의미할 수 있습니다. 이 증가된 에너지 사용은 전 세계 수백만 대의 iOS 기기를 고려할 때 지속 가능하지 않습니다. 에너지 소비의 소폭 증가조차도 환경에 영향을 미칠 수 있습니다. 이 연구에서 얻은 발견은 다양한 방식으로 이러한 지속 가능성 및 윤리적 문제를 해결하는 데 사용될 수 있습니다. 결과가 SwiftUI가 특정 계산 측면에서 UIKit을 능가하지 못한다고 나타난다면, 이는 Apple 엔지니어들의 관심을 끌 수 있습니다. 이러한 관심은 성능 문제를 해결하는 SwiftUI 프레임워크의 개정을 이끌어낼 수 있으며, 이는 프레임워크와 그 애플리케이션을 더 빠르고 더 넓은 대중에게 접근 가능하게 만들 수 있습니다. 이 연구는 미래의 UI 프레임워크가 더 에너지 효율적이고 환경 친화적이도록 개발될 수 있도록 기여할 수 있으며, 개선 영역을 식별함으로써 모바일 애플리케이션 생태계의 전체 탄소 발자국을 줄일 수 있습니다. 또한 이 연구는 개발자와 조직이 iOS 애플리케이션을 생성할 때 지속 가능성 및 윤리적 목표와 가장 일치하는 프레임워크를 선택하는 데 더 많은 정보를 제공합니다.

연구 방법론

이 연구를 수행하기 위해 사용된 방법론은 기술 벤치마크 평가입니다. SwiftUI와 UIKit 간의 종합적인 성능 비교를 수행하기 위해, iOS 애플리케이션에서 일반적으로 사용되는 UI 요소를 강조하는 UI 벤치마킹 앱 한 쌍이 개발되었습니다. 이 앱들은 호스팅 회사의 감독자 및 개발자들에 의해 검토되어, 프레임워크 간의 공정한 비교를 보장하며, 성능에 영향을 줄 수 있는 구현 방법에서 비롯된 잠재적인 영향을 제거하는 데 주의를 기울입니다. 벤치마킹 앱의 코드 리뷰를 마친 후, 이 앱들은 호스팅 회사에서 빌린 iOS 장치 세트에서 실행됩니다. 이 앱들의 주요 목표는 UI 구성 요소의 CPU 시간과 메모리 사용량에 관한 메트릭을 생성하는 것으로, 이러한 메트릭은 추가 분석을 위해 수집됩니다. CPU 시간은 이 연구에서 주요 성능 측정 메트릭으로 사용되며, 성능이 빠른 UI 프레임워크는 애플리케이션의 CPU 시간을 줄입니다. 메모리 사용량도 오래된 장치의 제한된 메모리 용량을 고려하여 메트릭으로 평가됩니다. 자동화된 테스트는 두 벤치마킹 앱에 대한 구체적인 메트릭을 수집하기 위해 개발되었습니다. 이 테스트들은 더 정확하고 신뢰할 수 있는 메트릭을 얻고 추가 데이터를 수집하기 위해 각 앱에 대해 여러 번 수행됩니다. 벤치마킹 앱에서 수집된 메트릭은 나중에 감독자와 협력하여 잘 알려진 결론에 도달하기 위해 분석됩니다. 이 협력적 접근 방식은 다양한 관점과 통찰력을 고려하여 보다 포괄적인 성능 차이 이해를 제공하며, 개발자들이 특정 프로젝트에 사용할 프레임워크를 결정하는 데 도움을 줍니다.

제한 사항

이 연구는 해당 프레임워크 내의 비-UI 알고리즘의 성능을 탐구하지 않습니다. 강조점은 데이터 처리와 같은 다른 측면을 고려하지 않고 UI 요소의 성능에만 머물러 있습니다. 둘째, 이 연구는 iPhone 장치에서의 iOS에만 한정됩니다. iPad, Apple TV, Apple Watch를 포함한 다른 iOS 장치는 이 연구의 범위에 포함되지 않습니다.

이 연구는 연구 당시 가장 최신 버전인 iOS 16 버전으로 제한되며, UIKit과 SwiftUI 앱 모두를 지원합니다. 연구는 SwiftUI 4 및 iOS 16용 UIKit을 기반으로 하며, 두 프레임워크의 향후 업데이트나 변경 사항은 고려하지 않습니다. 또한, 성능 데이터는 오직 실제 장치에서만 수집됩니다. 이 연구에서는 iOS 시뮬레이터에서의 SwiftUI와 UIKit의 성능은 분석되지 않습니다. 이 결정은 시뮬레이터의 성능이 실제 장치의 성능과 크게 다를 수 있기 때문에 결과가 실제 사용을 정확하게 반영하도록 하기 위해 내려졌습니다.

이 연구에서 성능 분석에 GPU 측정이 포함되지 않습니다. 렌더링 성능 평가에 GPU 사용의 중요성을 인정하면서도, 자동 테스트를 통해 iPhone GPU 사용량을 측정할 수 있는 간단한 방법이 없다는 점을 언급해야 합니다. 따라서 연구는 주로 CPU 시간과 메모리 사용량을 성능 메트릭으로 집중합니다.

구체적으로 이 연구는 뷰의 초기 렌더링 성능을 분석하는 데 집중하며, 사용자 상호작용 중의 성능은 포함하지 않습니다. 사용자 상호작용 성능은 전반적인 사용자 경험을 평가하는 데 중요한 역할을 하지만, 시간 제한으로 인해 포함되지 않았습니다. 사용자 상호작용 중의 성능 특성이 초기 렌더링 성능과 다를 수 있다는 점을 언급할 가치가 있습니다.

연구에 부과된 시간 제한은 연구 범위와 깊이에 영향을 미쳤습니다. 제한된 시간으로 인해 연구는 호스팅 회사가 개발한 앱에서 공통적으로 사용되는 다섯 가지 UI 요소만 벤치마킹했습니다. 이 요소들은 앱 개발에서의 관련성을 바탕으로 신중하게 선정되었지만, 제한된 수는 모든 가능한 시나리오와 사용 사례를 완전히 대표하지 않을 수 있습니다. 다른 UI 요소와 벤치마킹 과정에 포함되지 않은 복잡한 뷰에 대한 성능 결과는 다를 수 있다는 점을 인정하는 것이 중요합니다.

논문의 구조

제2장에서는 SwiftUI와 UIKit에 관한 관련 배경 정보를 제시합니다. 제3장에서는 문제를 해결하기 위해 사용된 방법론과 방법이 소개됩니다. 제4장에서는 수집된 데이터를 제시하고 분석합니다. 제5장에서는 수집된 데이터에 대해 논의합니다. 마지막으로 제6장에서 결론을 제시합니다.

배경

이 장에서는 SwiftUI와 UIKit에 대한 기본적인 배경 정보를 제공합니다. 이 장에서는 성능 분석 분야에서 이전에 수행된 작업도 소개합니다. 이 장에서는 성능 측정에 사용되는 용어, 개념, 도구도 소개합니다.

UI 프레임워크

UI 프레임워크는 요즘 소프트웨어 개발 분야에서 중요한 역할을 하며, 개발자들이 다양한 플랫폼에서 시각적으로 매력적이고 사용자 친화적인 앱을 만드는 데 도움을 줍니다. UI 프레임워크는 다양한 도구, 컴포넌트, 추상화를 제공함으로써 UI 요소의 디자인과 개발을 더 쉽게 관리할 수 있도록 합니다. UI 컴포넌트는 상호 작용 객체의 모음으로, 조작 가능한 사용자 인터페이스 시각 요소이며 사용자가 수행하고자 하는 상호 작용 작업과 관련된 정보를 전달하는 데 사용될 수 있습니다 [6]. 대부분의 UI 프레임워크는 컴포넌트 기반 아키텍처를 선호하며, 이는 UI 요소를 재사용 가능한 컴포넌트로 취급합니다. 이 방법은 모듈성, 유지 관리 가능성 및 재사용성을 향상시켜 개발자가 컴포넌트를 쉽게 혼합하고 사용자 정의하여 복잡한 UI를 만들 수 있도록 합니다 [7]. UIKit, SwiftUI, React, Angular, Vue.js는 컴포넌트 기반 프레임워크의 예입니다. 다음 절에서는 iOS의 두 가지 네이티브 UI 프레임워크인 UIKit과 SwiftUI에 대해 자세히 살펴보겠습니다.

UIKit

Apple이 제공하는 공식 프레임워크인 UIKit은 iOS용 UI 개발에 크게 기여하고 있습니다. 애니메이션, 그리기, 텍스트 및 리소스 관리를 지원하면서, UIKit은 iOS 애플리케이션을 위한 UI를 조립할 수 있는 다양한 컴포넌트를 제공합니다. 이벤트 처리 인프라는 개발 중인 앱에 멀티 터치 입력을 전달합니다. 이 장에서 나중에 자세히 살펴볼 SwiftUI 뷰는 UIKit 내에서 통합될 수 있습니다. 이러한 통합은 SwiftUI와 UIKit에서 구현된 요소들을 결합한 UI를 만드는 것을 용이하게 합니다 [1]. 개발자들은 보통 UIKit과 SwiftUI를 Xcode에서 사용하여 iPhone 디바이스를 위한 앱을 만듭니다. Xcode는 Apple의 공식 통합 개발 환경(IDE)으로, Apple 플랫폼 전반에 걸쳐 앱을 개발하고 테스트할 수 있는 필요한 도구들을 제공합니다. 또한 앱의 성능을 측정하는 도구인 Instruments도 Xcode 내에 통합되어 있습니다 [8].

아래 코드는 UIKit에서 버튼을 생성하는 예시 코드를 보여줍니다. 버튼의 텍스트는 "Tap Me"로 설정되어 있으며, 글꼴 크기는 20포인트입니다. 버튼이 탭되면 "buttonTapped" 함수가 호출되어 Xcode의 콘솔에 "Button tapped!"라고 출력됩니다. 버튼의 너비와 높이는 각각 200과 80으로 설정되어 있으며, 그 다음 중앙에 위치시켜 뷰에 추가됩니다.

import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // Create a button
        let button = UIButton(type: .system)
        button.setTitle(”Tap Me”, for: .normal)
        button.titleLabel?.font = UIFont.systemFont(ofSize: 20)
        button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside)
        // Set button frame and center it
        let buttonWidth: CGFloat = 200
        let buttonHeight: CGFloat = 50
        let buttonX = (view.frame.width - buttonWidth) / 2
        let buttonY = (view.frame.height - buttonHeight) / 2
        button.frame = CGRect(x: buttonX, y: buttonY, width: buttonWidth, height: buttonHeight)
        // Add the button to the view
        view.addSubview(button)
    }
    
    @objc func buttonTapped() {
        // Handle button tap event
        print(”Button tapped!”)
    } 
}

SwiftUI

SwiftUI는 Apple 플랫폼 전반에 걸쳐 UI를 구축하기 위해 설계되었으며, 개발자가 UI의 의도된 기능을 명확하게 표현하는 간결한 코드를 작성할 수 있도록 지원합니다. 라이브 프리뷰 기능은 개발자가 디자인 변경 사항을 실시간으로 단일 또는 다중 프리뷰에서 확인하고 Xcode에서 실행 중인 앱과 동시에 상호 작용할 수 있는 능력을 제공합니다. 이러한 기능은 반복 및 개선 과정을 단순화하여 더욱 만족스러운 UI를 만드는 데 기여합니다. [2]

아래 코드는 SwiftUI에서 버튼을 생성하는 예시 코드를 보여줍니다. 이 코드는 SwiftUI의 코딩 스타일이 UIKit에 비해 동일한 UI 컴포넌트를 생성하는 데 필요한 코드를 어떻게 단순화하는지 보여줍니다. 앞서 설명한 UIKit 버튼과 마찬가지로 이 버튼의 텍스트는 "Tap Me"로 설정되어 있으며, 글꼴 크기는 20포인트입니다. 버튼이 탭되면 Xcode 콘솔에 "Button tapped!"라고 출력하는 버튼에 추가된 액션이 호출됩니다. 버튼의 너비와 높이는 각각 200과 80으로 설정되어 있으며, 주변에 Spacers를 사용하여 화면 중앙에 배치됩니다.

import SwiftUI
struct ContentView: View {
    var body: some View {
        VStack {
            // Add space above the button to center it
            Spacer()
            Button(action: {
                // Handle button tap event
                print(”Button tapped!”)
            }) {
                Text(”Tap Me”)
                    .font(.system(size: 20))
                    .frame(width: 200, height: 50)
            }
            // Add space below the button to center it
            Spacer() 
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

 

서론 생략..

방법론

이 장에서는 이 연구에서 사용된 벤치마크의 구체적인 사항에 대해 심층적으로 다루며, 기술적 측면을 중점적으로 논의하고 다양한 시나리오, 벤치마킹 과정, 그리고 UIKit과 SwiftUI 비교를 안내하는 메트릭을 강조합니다. 이 장은 다음과 같이 구성됩니다: "실험 설계" 및 "벤치마킹 앱 구현" 섹션에서, 우리는 일곱 가지 다른 테스트 시나리오를 소개합니다. 이 시나리오들은 다양한 UI 컴포넌트와 상호작용을 포함하도록 세심하게 설계되어 두 프레임워크의 균형 잡힌 비교를 보장합니다. 검토된 시나리오는 다음과 같습니다: • 시나리오 1: 텍스트 뷰 • 시나리오 2: 이미지 뷰 • 시나리오 3: 버튼 • 시나리오 4: 블러 뷰 • 시나리오 5: 컬렉션 뷰 • 시나리오 6: 일반 앱 시나리오 • 시나리오 7: 앱 시작 시간 다음으로 "벤치마킹 앱 코드 리뷰" 섹션에서, UIKit과 SwiftUI 모두에 대한 벤치마킹 앱의 코드를 검토하는 과정을 설명합니다. 여기에서의 주요 목표는 앱 구현에서의 차이점을 정확히 파악하고 해결하여 공정한 비교를 확보하는 것입니다.

"데이터 수집" 파트에서는 성능 데이터 수집을 위한 저희 방법론을 공유합니다. 초점은 초기 다섯 시나리오에서 다양한 컴포넌트 수를 테스트하는 데 있으며, 컴포넌트 수가 변함에 따라 SwiftUI와 UIKit의 성능 사이에 비선형 관계가 있는지를 밝히려는 의도입니다.

"벤치마크 메트릭" 섹션은 연구에서 SwiftUI와 UIKit의 성능을 결정하기 위해 사용된 두 가지 주요 메트릭인 CPU 시간과 메모리 사용량에 초점을 맞춥니다. CPU 시간은 CPU가 명령을 실행하는 동안의 시간을 정량화합니다. 반면, 메모리 사용량은 애플리케이션에 의해 점유된 전체 물리적 메모리를 반영합니다. 또한 이러한 메트릭 선택 뒤에 있는 동기에 대해서도 자세히 설명합니다.

"자동 테스트" 섹션은 다양한 테스트 시나리오를 실행하기 위해 개발된 자동 UI 테스트를 설명합니다. "웜업 단계"는 소프트웨어 벤치마킹에서 웜업 단계의 존재를 인정합니다. 이 단계는 사용 중인 테스트 프레임워크에 의해 자동으로 고려되고 성능 데이터에서 제외됩니다.

"벤치마킹 장치"에서는 이 연구에서 사용된 다섯 개의 벤치마킹 장치를 소개합니다. 이 장치들은 고사양 및 저사양 장치를 모두 포함합니다. 여기서의 목표는 다양한 장치 범위에서 두 프레임워크의 성능 특성에 대한 통찰력을 얻는 것입니다.

마지막으로 "벤치마킹 환경"에서는 수집된 데이터의 신뢰성을 강화하는 통제된 테스트 환경을 설정합니다. 이 섹션에서는 벤치마킹 전 iPhone 장치의 테스트 설정을 소개합니다.

실험 설계

SwiftUI와 UIKit의 성능 데이터를 수집하기 위해 두 프레임워크 모두를 위한 전용 벤치마킹 애플리케이션을 개발했습니다. 벤치마킹 애플리케이션에 통합될 수 있는 많은 UI 컴포넌트가 있지만, 프로젝트의 시간 제한으로 인해 다양한 앱에서 자주 사용되는 UI 요소를 선택하는 데 중점을 두었습니다.

호스팅 회사의 엔지니어들은 다양한 모바일 애플리케이션 개발 경험이 풍부하며 이러한 앱에서 일반적으로 사용되는 UI 컴포넌트에 대한 깊은 이해를 가지고 있습니다. 이 엔지니어들과의 인터뷰를 통해 호스팅 회사가 만든 앱에서 가장 일반적인 UI 컴포넌트는 텍스트, 버튼, 이미지, 블러 뷰, 컬렉션 뷰임이 밝혀졌습니다. 따라서 벤치마킹 애플리케이션은 이러한 UI 컴포넌트 각각에 대한 독특한 시나리오를 포함하도록 설계되었습니다.

우리의 연구 질문에 답하기 위해 "SwiftUI의 성능이 UIKit에 비해 CPU 시간과 메모리 사용량 측면에서 어떻게 다른가?"에 대해, 컴포넌트 수가 다양한 성능 데이터가 수집되었습니다. 이 접근 방식의 주된 동기는 다양한 작업 부하와 실제 사용 사례에서 SwiftUI와 UIKit이 어떻게 수행되는지에 대한 더 포괄적인 이해를 만들어내는 것입니다. 다양한 컴포넌트 수량을 테스트함으로써 SwiftUI와 UIKit의 성능에서 비선형 관계를 식별할 수 있으며, 이는 고정된 수의 컴포넌트를 검토할 때 명백하지 않을 수 있습니다. 이를 달성하기 위해 개발된 애플리케이션은 표시된 UI 컴포넌트 수를 입력할 수 있는 텍스트 필드를 갖추고 있었습니다. 이 유연한 기능은 소수의 컴포넌트가 포함된 상황부터 많은 수의 UI 컴포넌트가 포함된 상황까지 프레임워크의 성능에 관한 데이터 수집을 용이하게 했습니다. 이 검토는 최소 및 광범위한 UI 컴포넌트가 포함된 상황에서 프레임워크의 성능에 대한 더 세밀한 관점을 제공합니다.

벤치마킹 앱 내의 마지막 시나리오는 일상적인 애플리케이션에서 일반적으로 발견되는 컴포넌트의 혼합을 통합하는 전형적인 앱을 모방하는 데 전념하고 있습니다. 벤치마킹 앱의 마지막 버튼은 "전형적인 앱"으로 레이블이 붙어 있으며, 탭하면 텍스트, 버튼, 이미지 및 컬렉션 뷰와 같은 다양한 요소로 구성된 소셜 미디어 프로필을 표시합니다. 이 시나리오는 더 현실적이고 대표적인 환경에서 SwiftUI와 UIKit의 성능을 평가할 기회를 제공합니다. 각 테스트 시나리오는 다음 섹션에서 자세히 논의됩니다.

벤치마킹 앱 구현

이 연구에서는 그림 3.1에서 보여지듯이 UIKit과 SwiftUI의 성능을 평가하고 비교하기 위해 벤치마킹 애플리케이션을 설계하고 개발했습니다. 앱의 두 버전은 배경색으로 시각적으로 구분됩니다: 그림 3.1a의 UIKit 버전은 녹색, 그림 3.1b의 SwiftUI 버전은 주황색입니다. 그림에서 보여지는 것처럼, 앱은 사용자가 테스트할 UI 컴포넌트의 원하는 수를 입력할 수 있는 입력 필드를 특징으로 합니다. 입력 필드 아래에는 다양한 UI 컴포넌트에 해당하는 버튼들이 있습니다. 이 버튼들을 탭함으로써 사용자는 선택한 UI 요소에 대해 지정된 수의 컴포넌트를 로드하고 표시할 수 있습니다. 이 특정 컴포넌트의 세부 사항과 각각의 벤치마크는 다음 소단락에서 철저히 논의됩니다.

텍스트 시나리오

이 특정 시나리오에서는 다양한 수의 텍스트 컴포넌트가 행과 열로 배열됩니다. 동시에 표시되는 텍스트 컴포넌트의 수를 최대화하기 위해 각 컴포넌트의 글꼴 크기는 6포인트로 줄어듭니다.

iOS에서 동일한 글꼴 크기를 가진 텍스트 요소는 다양한 장치에서 일관된 모습을 보여줍니다. 이는 글꼴 크기가 6인 텍스트 요소가 작은 iPhone 화면부터 큰 iPad 디스플레이까지 모든 iOS 장치에서 비슷하게 크게 보일 것임을 의미합니다.

각 행은 행 내 위치를 나타내는 텍스트가 표시된 50개의 텍스트 컴포넌트로 구성된 수평 스택입니다. 그런 다음 수평 스택들이 수직 스택에 배치되어 여러 행의 텍스트 컴포넌트를 생성합니다. 그림 3.2는 이 시나리오를 예시로 보여주며, 단일 수직 스택 뷰에 포함된 8개의 수평 스택 뷰에서 400개의 텍스트 컴포넌트를 표시합니다.

버튼 시나리오

이 시나리오는 이전 시나리오와 유사하며, 버튼들이 수평 스택 뷰(행)로 배열되어 있고, 이는 다시 하나의 수직 스택 뷰 내에 포함되어 있습니다. 여기에서의 차이점은 버튼이 제대로 표시되기 위해 더 많은 공간이 필요하기 때문에 각 행에 50개 대신 10개의 버튼이 있다는 것입니다. 각 버튼의 글꼴 크기는 기본값으로 유지됩니다. 그림 3.3은 이 시나리오의 예시로, 하나의 수직 스택 뷰 내에 포함된 4개의 수평 스택 뷰에서 40개의 버튼을 보여줍니다.

이미지 시나리오

이 시나리오에서는 프레임워크의 주요 목표가 앱의 내부 저장소에서 이미지를 효율적으로 불러와 원하는 크기인 16x16 포인트로 조정한 후, 각각 20개의 이미지 컴포넌트를 포함하는 행으로 구성된 체계적인 방식으로 표시하는 것입니다. 이미지의 원래 크기는 2048×2048 픽셀이며, 각 이미지에 필요한 저장 공간은 2메가바이트(MB)에서 5MB까지 다양합니다.

앱 저장소에 10개의 이미지만 제한적으로 사용 가능한 상황에서, 프레임워크는 이미지를 장치의 랜덤 접근 메모리(RAM)에 캐싱함으로써 성능을 추가로 향상시킬 기회를 가집니다. 이 접근 방식은 프레임워크가 저장소에서 이미지를 지속적으로 다시 불러올 필요 없이 필요한 이미지에 접근할 수 있게 함으로써, 장치의 자원에 대한 전반적인 부하를 줄입니다. 그림 3.4는 이 시나리오의 한 예를 보여주며, 여기서 400개의 이미지가 20개의 수평 스택 뷰에 배열되어 있고, 이들은 모두 하나의 수직 스택 뷰 내에 함께 배치되어 있습니다.

블러 시나리오

이 시나리오에서는 종종 상단에 추가 UI 컴포넌트가 겹쳐진 배경으로 사용되는 흐림 효과가 있는 뷰를 표시하는 방법을 탐구합니다. 시각적으로 일관된 레이아웃을 만들기 위해, 각 행은 10개의 흐린 뷰를 수용하도록 설계되었습니다. 이전 시나리오와 유사하게, 각 행에 대해 수평 스택 뷰를 사용하여 배열이 이루어지며, 이들은 다시 하나의 수직 스택 뷰 내에서 종합적으로 조직됩니다. 그림 3.5는 이 시나리오의 한 예를 보여주며, 여기서 400개의 흐린 뷰가 40개의 수평 스택 뷰에 배열되어 있고, 이들은 모두 하나의 수직 스택 뷰 내에 함께 배치되어 있습니다.

컬렉션 뷰 시나리오

이 시나리오에서는 모바일 애플리케이션에서 자주 사용되는 UI 컴포넌트인 테이블 셀을 포함하는 컬렉션 뷰의 성능을 탐구합니다. UIKit의 컬렉션 뷰는 유연하고 사용자 정의 가능한 레이아웃에서 아이템 컬렉션을 표시하기 위해 사용되며, iOS 16에서 작업할 때 SwiftUI에는 이와 직접적으로 동등한 컴포넌트가 없습니다. 따라서 우리는 같은 기능을 모방하고 비슷한 결과를 얻기 위해 SwiftUI에서 리스트 뷰와 수평 및 수직 스택의 조합을 채택합니다.

그림 3.6은 이 시나리오의 시각적 표현을 제공하며, 각 셀에 카드 덱이 포함된 3개의 행과 6개의 테이블 셀로 구성된 레이아웃을 보여줍니다. 그림 3.6b는 앞서 언급한 요소를 사용하여 UIKit 컬렉션 뷰를 SwiftUI로 적용한 예를 보여주며, 그림 3.6a에서와 같이 직접적인 동등한 컴포넌트가 없는 상황에서도 SwiftUI로 비슷한 결과를 달성할 수 있는 능력을 강조합니다.

전형적인 앱 시나리오

이 시나리오에서는 일반적으로 사용되는 다양한 컴포넌트를 결합하여 일관된 인터페이스를 형성하는 전형적인 앱의 생성을 탐구합니다. 전형적인 앱은 일반적으로 텍스트, 이미지, 버튼, 스크롤 가능한 뷰의 조합으로 구성됩니다. 이를 모방하기 위해, 이 시나리오에서는 전형적인 앱을 대표하는 소셜 미디어 프로필 페이지를 구현했습니다. 소셜 미디어 프로필 페이지는 모든 중요 컴포넌트를 포함하고 이러한 요소들을 단일 사용자 친화적 인터페이스로 통합하는 것을 효과적으로 보여줍니다.

그림 3.7은 전형적인 앱 시나리오의 결과 인터페이스를 보여주며, 시각적으로 매력적인 소셜 미디어 프로필 페이지를 형성하기 위해 텍스트, 이미지, 버튼, 스크롤 가능한 뷰의 혼합을 보여줍니다. 이 시나리오는 실용적이고 일상적인 애플리케이션 맥락에서 다양한 UI 컴포넌트를 처리할 때 SwiftUI와 UIKit의 기능과 잠재적 성능에 대한 귀중한 통찰력을 제공합니다.

벤치마킹 앱 코드 리뷰

UIKit과 SwiftUI를 위한 벤치마킹 앱 개발을 완료한 후, 해당 구현 코드는 호스팅 회사의 경험 많은 두 명의 엔지니어에게 공유되었습니다. 이들은 각각 UIKit과 SwiftUI 모두에서 수년간의 전문성을 가지고 있습니다. 이 코드 리뷰 과정의 주요 목표는 앱 구현 간의 차이점을 식별하고 제거하여 두 프레임워크의 공정한 비교를 보장하는 것이었습니다. 코드 리뷰는 다양한 코드 수정으로 이어졌으며, 대부분의 변경 사항은 SwiftUI 구현에 적용되었습니다. 앞서 언급한 바와 같이, UIKit의 컬렉션 뷰와 같은 특정 컴포넌트는 SwiftUI에서 직접적인 동등물이 없습니다. 리스트, 수평 스택, 및 수직 스택의 조합을 사용한 컬렉션 뷰의 구현은 신중하게 검토되었으며, 이를 적절하고 동등한 해결책으로 간주한 검토 엔지니어들에 의해 최종적으로 승인되었습니다.

데이터 수집

첫 5개 시나리오는 다양한 요소 수를 가지고 검토되었습니다. 이는 다양한 컴포넌트 수량으로 테스트함으로써 고정된 수의 컴포넌트를 검사할 때는 명확하지 않을 수 있는 SwiftUI와 UIKit의 성능에 비선형 관계가 있는지 식별할 수 있게 도와줍니다. 이를 달성하기 위해, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 요소를 포함하는 12개의 요소 수를 가지고 이 5개 시나리오를 벤치마크하기로 결정되었으며, 이는 총 5x12=60개의 고유 테스트 케이스를 결과로 하였습니다. 이 60개의 테스트 케이스 외에도, 각 앱의 시작 시간과 전형적인 앱 시나리오도 벤치마크되었습니다. 이로써 총 고유 테스트 케이스 수는 62개가 되었습니다.

벤치마크 테스트를 설계하는 과정에서, 요소 수를 두 배로 늘리는 전략을 사용했습니다. 이 선택 뒤에 있는 이유는 특히 작은 수의 컴포넌트에 대해 더 넓은 범위의 메트릭을 수집할 수 있게 해주기 때문입니다. 이 접근 방식은 앱 뷰에 16개와 같은 적당한 수의 컴포넌트를 포함할 가능성이 더 높은 것을 고려할 때 특히 관련이 있습니다. 이 두 배 증가 기법을 사용함으로써, 실제 애플리케이션을 더 잘 대표하는 시나리오에 초점을 맞춘 성능 데이터의 포괄적인 평가를 보장할 수 있습니다.

SwiftUI와 UIKit의 성능 차이에 대한 종합적인 이해를 추구하며, 첫 5개 시나리오 각각을 최대 2048 컴포넌트로 테스트하기로 결정되었습니다. 이 선택의 이유는 CPU 또는 메모리 사용 측면에서 한 프레임워크가 다른 프레임워크보다 중요한 이점을 보이는 잠재적 임계값을 식별하고자 하는 욕구에 있습니다. 이 접근 방식은 비교의 깊이와 견고함을 강화시켜, 개발자들이 특정 사용 사례와 애플리케이션의 컴포넌트 수에 따라 어떤 프레임워크를 선택할지에 대한 귀중한 지침을 제공합니다.

이 테스트를 단 한 번만 수행하면 데이터가 일관성이 없을 수 있습니다. 이 위험을 완화하고 결과의 신뢰성을 높이기 위해 62개의 테스트 케이스가 각각 10번씩 실행되기로 결정되었습니다. 테스트를 여러 번 반복함으로써, 각 케이스에 대한 평균 메트릭을 계산할 수 있게 되어, 다양한 시나리오 및 요소 수에 걸친 앱 성능의 보다 정확하고 신뢰할 수 있는 표현을 보장할 수 있습니다. 이러한 철저한 벤치마킹 접근 방식은 수집된 데이터의 무작위 변동 및 잡음의 영향을 최소화했습니다.

벤치마크 메트릭

CPU 시간은 이 연구에서 측정을 위해 선택된 주요 메트릭 중 하나로 사용되었습니다. 초 단위로 표현되는 CPU 시간은 측정 대상에 대해 CPU가 명령을 활발하게 실행하는 동안의 지속 시간을 나타냅니다. 중요하게도, CPU가 다른 프로세스나 스레드의 실행으로 컨텍스트를 전환하거나 유휴 상태에 들어갈 때 이 값은 변경되지 않습니다 [5]. iOS는 가비지 콜렉터가 없고 메모리 관리를 위해 ARC를 사용하기 때문에, 이 값은 여러 번 실행을 통한 메모리 할당 및 해제에 영향을 받지 않습니다 [34]. CPU 시간은 뷰가 표시되는 데 필요한 시간을 보여주기 때문에 사용자 경험의 중요한 측면이므로 메트릭으로 선택되었습니다. 또한, CPU 관련 메트릭은 사용자 경험과 직접적인 상관 관계가 있고 작업 실행의 지연이 애플리케이션의 전반적인 인식에 부정적인 영향을 미칠 수 있기 때문에 연구된 문헌에서 인기가 있습니다 [4].

메모리 사용량도 이 연구에서 측정을 위해 선택된 다른 메트릭입니다. iOS 생태계 내에서, Absolute Memory Physical 메트릭은 테스트 과정 중 애플리케이션이 소비하는 물리적 메모리의 총량을 나타냅니다. 이는 애플리케이션 자체에 의해 사용되는 메모리뿐만 아니라 관련 시스템 프로세스나 리소스에 의해 사용되는 메모리도 포함합니다. 메모리 사용량은 메모리 한도를 초과하면 메모리 용량이 낮은 장치에서 충돌을 일으킬 수 있기 때문에 중요한 메트릭입니다. 메모리 사용량을 분석함으로써 개발자들은 잠재적인 성능 병목 현상을 더 잘 이해하고 애플리케이션을 최적화하여 궁극적으로 더 안정적인 사용자 경험을 제공할 수 있습니다 [4].

자동 테스트

iOS IDE는 "XCTest"라는 테스트 프레임워크를 갖추고 있습니다. 이 프레임워크는 개발자가 자동 테스트를 작성하고 실행하면서 동시에 다양한 중요 메트릭을 수집할 수 있도록 합니다. 이전에 언급했듯이, UIKit과 SwiftUI의 성능을 평가하기 위해 첫 5개 시나리오 각각에 대해 12개의 테스트 함수가 개발되었으며, 다양한 요소 수를 포괄합니다.

이 12개의 테스트 함수는 12개의 구별된 요소 수에 대해 각 시나리오의 메트릭을 수집하도록 특별히 설계되었습니다. 이는 하나의 요소에서 시작하여 각 테스트마다 요소 수를 두 배로 늘리고, 최종적으로 2048개의 요소에 도달합니다. 예를 들어, 텍스트 컴포넌트의 성능을 평가하기 위해 작성된 테스트는 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048개의 컴포넌트를 가진 텍스트 시나리오를 실행합니다. 그림 3.8은 텍스트 컴포넌트 시나리오가 512개의 요소로 실행될 때 발생하는 일련의 사건을 보여주며, 다음 코드는 이 시나리오에 대해 생성된 자동 XCTest 함수를 보여줍니다:

let repetitionCount = 10;

func typeNumber(app: XCUIApplication, number: String) {
  app.textFields[”Enter number of elements”].tap()
  let moreKey = app.keys[”more”].tap()
  for char in number{
    let key = app.keys[”\(char)”]
    key.tap() 
  }
  app.buttons[”Return”].tap()
}

func testTextPerformance_512() throws {
  // Options to control the gathering of performance measurements during tests.
  let measureOptions = XCTMeasureOptions()
  // Test measurement options that control how measurement starts and stops.
  measureOptions.invocationOptions = [.manuallyStart,
                                      .manuallyStop]
  // The number of times the performance test measures its block.
  measureOptions.iterationCount = repetitionCount
  typeNumber(app: app, number: ”512”)
  // Measures the performance of a block of code.
  measure(metrics: [XCTCPUMetric(application: app),
                    XCTMemoryMetric(application: app)],
                    options: measureOptions) {
    startMeasuring()
    app.staticTexts[”Texts”].tap()
    app.navigationBars[”UIKit”].buttons[”UIKit”].tap()
    stopMeasuring()
  } 
}

이 XCTest 코드에서, typeNumber 함수는 사용자 입력을 모방하여 앱의 텍스트 필드에 지정된 수의 요소를 입력하는 역할을 합니다. 화면의 키들과 상호작용하여 원하는 숫자를 입력하고 "Return" 버튼을 눌러 입력을 확인합니다. 주요 함수인 testTextPerformance_512는 측정 옵션을 설정하고 "512"라는 값으로 typeNumber 함수를 호출하여 512개 요소를 가진 텍스트 컴포넌트의 성능을 테스트합니다. measure 함수는 "Texts" 버튼을 탭하고 "UIKit" 화면으로 이동한 다음 원래 화면으로 돌아가는 시나리오 실행 중에 CPU 시간 및 메모리 사용 메트릭을 캡처합니다. 테스트는 반복 횟수인 repetitionCount에 지정된 대로 10회 실행되어 성능 메트릭의 더 신뢰할 수 있고 정확한 평균을 보장합니다.

웜업 단계

벤치마킹 애플리케이션의 과정에서, 소프트웨어가 초기에 장치의 RAM에 로드되고 아직 성능 평가에 최적화되지 않은 웜업 단계를 경험하는 것이 일반적입니다. XCTest는 웜업 단계의 측정값을 자동으로 고려하고 벤치마킹 값에서 제외합니다. 예를 들어, 애플리케이션의 평균 성능이 자동 테스트를 10회 실행하여 측정된 경우, XCTest는 총 11회 테스트를 수행하고 첫 번째 실행에서의 데이터를 버립니다. 이 접근 방식은 수집된 성능 데이터가 애플리케이션의 진정한 능력을 더 잘 반영하도록 보장하며, 웜업 단계 동안의 초기 비효율성이나 지연에 의해 왜곡되지 않도록 합니다.

벤치마킹 장치

이 연구에서 포괄적인 성능 데이터 수집을 위해 저사양 장치 두 대와 고사양 장치 세 대가 선택되었습니다. 이 접근법은 SwiftUI와 UIKit이 다양한 장치에서 어떻게 수행되는지에 대한 광범위한 이해를 제공하는 것을 목표로 했습니다. 이는 저사양 및 고사양 장치에서 프레임워크의 성능 특성에 대한 통찰력을 얻고, 어느 한 프레임워크가 저사양 또는 고사양 장치에서 다른 프레임워크보다 더 잘 수행되는지를 밝힐 수 있는 가능성을 탐구하려는 것이었습니다. 벤치마킹에 선택된 장치들은 처리 능력과 성능 능력의 다양한 수준을 가지고 있었습니다. 표 3.1은 이 연구에서 벤치마킹을 위해 선택된 장치의 상세 목록을 제시합니다.

벤치마킹 환경

벤치마킹 테스트를 실행하기 전에, 통제된 테스트 환경이 만들어졌습니다. 애플리케이션은 디버그 모드가 아닌 릴리스 모드에서 테스트되어 벤치마킹 앱의 실제 사용과 가장 유사한 데이터를 수집할 수 있도록 했습니다. 이는 Xcode에서 각 벤치마킹 앱의 테스트 대상 모드를 릴리스로 설정함으로써 달성되었습니다.

테스트 준비를 위해 iOS 장치들은 테스트를 위한 깨끗한 상태를 제공하기 위해 재시작되었습니다. 그런 다음 장치들은 비행기 모드로 설정되어 모바일 데이터, 셀룰러 네트워크, 블루투스 연결을 효과적으로 비활성화하여 잠재적인 간섭을 최소화했습니다. 애플이 테스트를 위해 애플리케이션을 검증하고 승인하는 데 필요했기 때문에 Wi-Fi 연결은 활성화되었습니다.

자동 잠금 모드는 테스트 과정 중에 장치가 잠기지 않도록 "절대로"로 조정되었습니다. 또한, 위치 서비스는 비활성화되었고 모든 백그라운드 앱은 닫혀 GPS 및 기타 프로세스가 결과에 미치는 영향을 더욱 최소화했습니다. 일관성을 유지하기 위해, 테스트 설정은 62개의 자동 테스트 기능을 실행하기 전에 벤치마킹 앱을 자동으로 재시작하도록 구성되었습니다.

테스트 단계 동안, 장치들은 테이블 위에 놓이고 만질 수 없도록 되어 있어 자이로스코프 센서가 실수로 작동되지 않도록 했습니다. 장치들은 USB-C 케이블을 통해 MacBook 랩톱에 연결되어 Xcode가 테스트를 실행하고 성능 데이터를 수집할 수 있도록 했습니다. 수집된 데이터는 표와 그래프로 정리되어 이후 장에서 검토 및 논의될 것입니다.

연구의 타당성에 대한 위협

성능 벤치마킹을 위한 공통 UI 요소의 선택은 주로 호스팅 회사에서 개발된 앱에 의해 영향을 받았으며, 이는 일반 앱 개발 커뮤니티의 앱과 완벽하게 일치하지 않을 수 있습니다. 이로 인해 연구 결과의 일반화 가능성에 대한 잠재적 제한이 발생할 수 있습니다. 또 다른 고려사항은 벤치마킹 앱의 구현 코드가 호스팅 회사의 엔지니어들에 의해 검토되었다는 점입니다. 이 부분은 강점이자 잠재적인 편향의 원천으로 볼 수 있습니다. 경험이 풍부한 엔지니어들의 참여는 구현 코드가 고품질이며 최선의 관행을 반영하도록 보장합니다. 반면에, 호스팅 회사의 엔지니어들과의 긴밀한 협력은 그들의 관점과 선호가 구현 방식에 영향을 줄 수 있으며, 이는 편향의 가능성을 도입합니다. 이러한 잠재적 편향을 인식하고 결과를 이러한 맥락에서 해석하는 것이 좋습니다.

결과 및 분석

결과는 표와 시각적으로 정보를 제공하는 그래프로 추출되어 조직되었습니다. 이전에 "데이터 수집" 섹션에서 언급한 바와 같이, 62개의 테스트 각각이 10회 실행되어 분석되는 지표에 대해 더 신뢰할 수 있는 평균을 제공합니다. 모든 테스트에 걸쳐 10회 실행된 데이터에서 수집된 데이터의 상대 표준 편차가 10% 미만이라는 점이 관찰되었기 때문에, 각 테스트를 총 10회 실행하기로 한 결정은 적절했습니다. 62개의 각 테스트 평균은 이 장의 그래프를 사용하여 제공됩니다. 이 연구에서 제시된 그래프는 각 그래프 위에 설명적인 제목이 배치되어 있으며, 제시된 시나리오와 벤치마크된 기기의 이름, 데이터 수집 시 설치된 iOS 버전에 대한 정보를 제공합니다. 예를 들어, "IPHONE-8.PLUS-16"이라는 제목은 벤치마킹된 기기가 iPhone 8 Plus이며, 벤치마킹 과정 중에 설치된 iOS 버전이 iOS 16임을 나타냅니다. 결과는 테스트 시나리오에 따라 구성된 섹션으로 제시됩니다. 모든 종합적인 결과는 부록에서 찾을 수 있으며, 벤치마킹 앱과 관련된 GitHub 리포지토리(부록 A 참조)를 통해 연구 전반에 걸쳐 얻은 데이터에 대한 완전한 투명성과 접근성을 보장합니다.

텍스트 시나리오

그림 4.1은 다양한 iOS 기기에서 텍스트 시나리오에 대한 CPU 시간 플롯을 보여줍니다. 각 플롯의 데이터 포인트는 각 구성 요소 수에 대해 10회 실행에서 계산된 평균 CPU 시간을 나타냅니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 데이터는 UIKit과 SwiftUI 모두에서 3% 미만의 표준 편차를 가집니다. 이 시나리오에 대한 종합적으로 수집된 CPU 시간 데이터는 부록의 표 B.2에 제시되어 있습니다. UIKit과 SwiftUI를 비교할 때, UIKit은 SwiftUI보다 약 30%에서 37% (60에서 100 밀리초(ms)) 더 빠르게 수행되며, 구성 요소 수가 32개 미만일 때 이 차이가 나타납니다. 구성 요소 수가 64개를 초과하면 이 성능 격차가 좁혀지고, 구성 요소 수가 512개를 초과하면 CPU 시간 차이가 무시할 만큼 작아집니다. 두 프레임워크의 동작은 다양한 iOS 기기에서 비슷하게 보입니다. 예를 들어, iPhone 14에서 다양한 수의 텍스트 구성 요소를 표시하는 것이 iPhone 8에서보다 대략 두 배 빠릅니다만, UIKit과 SwiftUI의 상대적 성능은 기기 간에 일관되게 유지됩니다. 두 경우 모두 UIKit이 SwiftUI보다 약간 더 빠른 성능을 보이지만, 구성 요소 수가 증가함에 따라 이 차이는 덜 중요해집니다. 그림 4.2는 다양한 iOS 기기에서 텍스트 시나리오의 벤치마킹 앱 메모리 사용량을 보여줍니다. 각 플롯의 데이터 포인트는 각 구성 요소 수에 대해 10회 별도 실행에서 얻은 평균 메모리 사용량을 나타냅니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 메모리 사용 데이터는 UIKit과 SwiftUI 모두에서 7% 미만의 표준 편차를 가집니다. 그림 4.2의 메모리 플롯을 면밀히 검토하면, SwiftUI가 UIKit보다 더 많은 메모리를 소비한다는 것을 알 수 있습니다. 평균적으로 SwiftUI의 메모리 사용량은 구성 요소 수에 관계없이 UIKit보다 약 20%에서 23% (4에서 5MB) 더 높습니다. 이 시나리오에 대한 종합적으로 수집된 메모리 사용 데이터는 부록의 표 B.1에 제시되어 있습니다.

버튼 시나리오

그림 4.3은 다양한 벤치마크된 iOS 기기에서 버튼 시나리오에 대한 CPU 시간 플롯을 보여줍니다. 각 플롯의 데이터 포인트는 각 구성 요소 수에 대해 10회 실행에서 계산된 평균 CPU 시간을 나타냅니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 데이터는 UIKit과 SwiftUI 모두에서 10% 미만의 표준 편차를 가집니다. 이 시나리오에 대한 종합적으로 수집된 CPU 시간 데이터는 부록의 표 B.4에 제시되어 있습니다. 텍스트 시나리오와 유사한 패턴에서, UIKit은 구성 요소 수가 32개 미만일 때 SwiftUI에 비해 약간의 성능 우위를 보이며, 평균적으로 UIKit이 SwiftUI보다 약 28%에서 35% (50에서 100 밀리초(ms)) 더 빠릅니다. 이 차이는 구성 요소 수가 64개를 초과함에 따라 점차 줄어들어, 구성 요소 수가 256개를 초과할 때 거의 무시할 수 있게 됩니다. 특히, iPhone 12 Pro Max와 iPhone 14와 같은 고급 기기에서는 구성 요소 수가 많을 때 UIKit의 성능이 SwiftUI보다 느린 것으로 보입니다. 구체적으로, 2048개의 구성 요소를 표시할 때 UIKit은 iPhone 12 Pro Max에서 약 16% (500 밀리초(ms)), iPhone 14에서 약 24% (1000 밀리초(ms)) 더 느립니다. 이 관찰은 SwiftUI가 고급 기기에서 많은 수의 버튼을 처리하는 데 더 나은 성능을 발휘할 수 있음을 시사하며, 더 진보된 하드웨어 플랫폼에서의 최적화 및 적응성 가능성을 보여줍니다. 그림 4.4는 다양한 벤치마크된 iOS 기기에서 버튼 시나리오의 메모리 사용량을 보여줍니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 메모리 사용 데이터는 UIKit과 SwiftUI 모두에서 10% 미만의 표준 편차를 가집니다. 텍스트 시나리오와 마찬가지로, SwiftUI는 UIKit보다 더 많은 메모리를 사용하며, 구성 요소 수가 32개 미만일 때 SwiftUI의 평균 메모리 사용량은 UIKit보다 약 23% (4 MB) 더 높습니다. 이 차이는 테스트된 모든 iOS 기기에서 요소 수가 64개를 초과함에 따라 급격히 증가하며, 결국 2048개의 버튼 구성 요소를 표시할 때 SwiftUI가 UIKit의 거의 두 배에 해당하는 메모리를 소비하는 지점에 도달합니다. 이 시나리오에 대한 종합적으로 수집된 메모리 사용 데이터는 부록의 표 B.3에 제시되어 있습니다.

이미지 시나리오

그림 4.5는 다양한 벤치마크된 기기에 대한 CPU 시간 플롯을 보여줍니다. 각 플롯의 데이터 포인트는 각 구성 요소 수에 대해 10회 실행에서 계산된 평균 CPU 시간을 나타냅니다. 이 시나리오에서, 각 구성 요소 수에 대해 수집된 CPU 시간 및 메모리 사용 데이터의 표준 편차는 UIKit과 SwiftUI 모두에서 3% 이하입니다. 이 시나리오에 대한 종합적으로 수집된 CPU 시간 데이터는 부록의 표 B.6에 제시되어 있습니다.

이전 시나리오와 유사하게, 구성 요소 수가 32개 이하일 때 UIKit이 SwiftUI보다 빠르게 나타납니다. 벤치마크된 기기에서, UIKit은 평균적으로 약 29%에서 37% (60에서 90 밀리초) SwiftUI보다 빠릅니다. 그러나 구성 요소 수가 증가함에 따라 두 프레임워크 간의 차이는 줄어들기 시작하며, 이 추세는 SwiftUI와 UIKit이 1024개의 구성 요소를 표시하는 데 대략 동일한 시간이 필요할 때까지 계속됩니다.

그림 4.6은 다양한 벤치마크된 기기에서 이미지 시나리오에 대한 메모리 사용 플롯을 보여줍니다. 이 특정 시나리오에서, SwiftUI와 UIKit의 메모리 소비는 매우 근접하게 유지되며, 구성 요소 수가 32개 이하일 때 SwiftUI는 UIKit보다 평균적으로 약 4% (3.5 MB) 더 많은 메모리를 사용합니다. 이 차이는 구성 요소 수가 64개를 넘어서면서 약간 더 두드러지며, 이미지 수가 2048개에 이르면 약 16% (32 MB)의 최고점에 도달합니다. 이 시나리오에 대한 종합적으로 수집된 메모리 사용 데이터는 부록의 표 B.5에 제시되어 있습니다.

블러 시나리오

그림 4.7은 다양한 벤치마크된 기기에서 블러 시나리오의 CPU 시간 플롯을 보여줍니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 및 메모리 사용 데이터의 표준 편차는 UIKit과 SwiftUI 모두에서 10% 이하입니다. 이 시나리오에 대한 종합적으로 수집된 CPU 시간 데이터는 부록의 표 B.8에 제시되어 있습니다.

이전 시나리오와 마찬가지로, 구성 요소 수가 32개 미만일 때 UIKit이 SwiftUI보다 약간 빠른 성능을 보입니다. 이 경우, UIKit은 평균적으로 약 20%에서 30% (40에서 85 밀리초) 더 빠르게 수행합니다. 흥미롭게도, 블러 뷰의 수가 32개를 초과하면 성능에서 눈에 띄는 변화가 발생하여 SwiftUI가 UIKit을 능가하기 시작합니다. 이 성능 우위는 점점 더 두드러지며 2048개 요소에 이르기까지 지속되며, 평균적으로 SwiftUI가 UIKit보다 약 35% (1200 밀리초) 더 빠르게 수행됩니다.

그림 4.8은 다양한 iOS 기기에서 블러 시나리오의 메모리 사용 플롯을 보여줍니다. SwiftUI의 CPU 시간이 32개 요소 이후로 감소하더라도, 메모리 사용량은 UIKit에 비해 모든 테스트된 구성 요소 수에서 일관되게 더 높습니다. 평균적으로 SwiftUI는 UIKit보다 약 13% (4 MB) 더 많은 메모리를 소비합니다. 이 시나리오에 대한 종합적으로 수집된 메모리 사용 데이터는 부록의 표 B.7에 제시되어 있습니다.

컬렉션 뷰 시나리오

그림 4.9는 다양한 벤치마크된 iOS 기기에서 컬렉션 뷰를 표시할 때 SwiftUI와 UIKit 간의 성능 차이를 강조하는 CPU 시간 플롯을 보여줍니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 데이터는 UIKit과 SwiftUI 모두에서 4% 이하의 표준 편차를 가집니다. 이 시나리오에 대한 종합적으로 수집된 CPU 시간 데이터는 부록의 표 B.10에 제시되어 있습니다.

이전 시나리오와 마찬가지로, UIKit은 SwiftUI보다 빠른 성능을 보여주며, 행의 수가 증가함에 따라 격차가 넓어집니다. 평균적으로 UIKit은 SwiftUI보다 약 3배 빠른 성능을 보여줍니다. 그림 4.10은 벤치마크된 기기에서 컬렉션 뷰의 메모리 사용 패턴을 보여주며, 다양한 행 수를 가진 컬렉션 뷰를 표시할 때 SwiftUI가 UIKit보다 대략 두 배 많은 메모리를 소비한다는 것을 보여줍니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 및 메모리 사용 데이터는 UIKit과 SwiftUI 모두에서 7% 이하의 표준 편차를 가집니다. 구성 요소의 4-8 행 이후 플롯이 평탄화되는 현상은 컬렉션 뷰의 지연 로딩 특성에 의해 설명될 수 있습니다. 사용자에게 보이는 행만 메모리에 로드되므로 메모리 사용이 안정화되어 행의 수가 증가해도 추가 메모리 소비가 방지됩니다. 이 시나리오에 대한 종합적으로 수집된 메모리 사용 데이터는 부록의 표 B.9에 제시되어 있습니다.

전형적 앱 시나리오

그림 4.11은 다양한 iOS 기기에서 전형적 앱 시나리오에 대한 CPU 시간 및 메모리 사용 플롯을 보여줍니다. CPU 시간 그래프의 각 막대는 전형적 앱 시나리오를 10회 실행하여 수집된 평균 CPU 시간을 보여주며, UIKit과 SwiftUI 모두 2% 이하의 표준 편차를 가집니다. 전형적 앱 시나리오에 대해 제시된 플롯은 이 특정 시나리오에서 관여하는 구성 요소의 수가 일관되기 때문에 이전 시나리오와 다르며, 그림 4.11에서 보여지는 바와 같이 막대 그래프로 결과를 표시할 수 있습니다. 이 시나리오에 대한 종합적으로 수집된 데이터는 부록의 표 B.11과 표 B.12에 제시되어 있습니다.

CPU 시간 플롯을 검토하면 SwiftUI가 전형적 앱 시나리오를 표시하는 데 더 많은 시간이 필요함이 분명해집니다. UIKit의 성능은 평균적으로 SwiftUI보다 약 20%에서 25% 더 빠르며, 이는 대략 50에서 75 밀리초의 지연을 의미합니다. 이 시나리오의 메모리 사용 플롯은 SwiftUI가 UIKit보다 약간 더 많은 메모리를 사용함을 보여주며, 평균적으로 약 2.5% 더 많은 메모리를 사용하며, 이는 대략 3.5 MB의 메모리에 해당합니다.

런치 타임 시나리오

그림 4.12에서는 다양한 iOS 기기에서 벤치마킹 앱의 런치 중 CPU 시간 및 메모리 사용이 제시됩니다. 이 시나리오에서 각 구성 요소 수에 대해 수집된 CPU 시간 및 메모리 사용 데이터는 UIKit과 SwiftUI 모두에서 3% 이하의 표준 편차를 가집니다. 이 시나리오에 대한 종합적으로 수집된 데이터는 부록의 표 B.13과 표 B.14에 제시되어 있습니다.

CPU 시간 플롯을 살펴보면, UIKit이 SwiftUI에 비해 약간 빠른 성능을 보임을 관찰할 수 있습니다. UIKit은 평균적으로 SwiftUI보다 대략 5%에서 15% 더 빠르게 수행되며, 이는 다양한 벤치마크된 기기에서 대략 20에서 90 밀리초의 차이에 해당합니다. 메모리 사용 플롯을 고려해보면, SwiftUI가 UIKit에 비해 약간 더 많은 메모리를 소비함을 볼 수 있습니다. 특히 메모리 사용 플롯은 평균적으로 SwiftUI가 UIKit보다 약 25%에서 30% 더 많은 메모리를 사용하며, 이는 2.5에서 3 MB의 증가된 메모리 소비에 해당합니다. 다음 장에서는 결과의 결과에 대한 논의가 제시되며 이어서 결론 및 향후 작업을 중심으로 한 장이 제시됩니다.

토론

이 장에서는 결과를 분석하고 트렌드를 식별하며 이를 더 큰 맥락에서 고찰합니다. 우리는 SwiftUI와 UIKit을 평가하기 위해 두 가지 유형의 테스트 시나리오를 사용했습니다. 첫 번째 유형의 테스트 시나리오는 텍스트, 버튼, 이미지 구성 요소 등 개별 UI 구성 요소를 대상으로 했습니다. Maleszewski와 Janusz Sosnowski [36]의 연구에 따르면, 구성 요소 수가 32개 미만일 때 벤치마크된 UI 구성 요소가 일반적으로 UIKit에서 SwiftUI보다 빠르게 수행되었습니다. Maleszewski와 Janusz Sosnowski [36]는 또한 실제 시스템 사용을 기반으로 전체 시스템 성능을 평가하는 데 중점을 둔 테스트 시나리오를 제안했습니다. 이는 일반적으로 앱이 하나의 UI 구성 요소만을 포함하지 않고 여러 UI 구성 요소를 혼합하고 있기 때문에 실제 앱에서 다양한 UI 구성 요소를 혼합하여 보여주는 전형적인 앱 시나리오를 통해 달성되었습니다. 전형적인 앱 시나리오의 결과는 UI 구성 요소의 혼합을 사용하는 앱에서 UIKit으로 만든 앱이 일반적으로 SwiftUI로 만든 앱보다 더 빠르다는 것을 보여줍니다. 각 시나리오의 구체적인 발견 사항은 다음 섹션에서 자세히 논의됩니다. 또한, 이 연구의 한계에 대한 일반적인 토론이 마지막에 진행됩니다.

텍스트, 버튼 및 이미지 시나리오

결과를 검토한 결과 텍스트, 버튼, 이미지 시나리오에서 UIKit의 CPU 시간은 SwiftUI의 CPU 시간과 비슷하거나 약간 낮은 값을 보여줍니다. iPhone 14와 iPhone 12 Pro Max에서 2048개의 버튼을 표시하는 특정 시나리오에서는 다른 기기와 비교했을 때 이례적으로 UIKit의 성능이 SwiftUI보다 느리게 나타납니다. 이 특정 버튼 수에 대한 UIKit의 CPU 시간 값은 각각 언급된 기기에서 7.4%, 6.6%의 표준 편차를 보여줍니다. 반면, 이러한 기기에서 동일한 버튼 수에 대한 해당 SwiftUI의 CPU 시간 값은 각각 0.6%, 0.8%의 낮은 표준 편차를 보여줍니다. 이러한 발견은 특정 버튼 수에 대해 지정된 기기에서 SwiftUI보다 UIKit의 성능 측정이 덜 안정적임을 시사합니다. 이 안정성 차이는 다른 세 기기에서 관찰된 반대 추세에도 불구하고 iPhone 14와 iPhone 12 Pro Max에서 UIKit이 SwiftUI보다 느리게 수행되는 예상치 못한 사건을 설명할 수 있습니다.

이미지 시나리오에서 얻은 결과는 이미지를 표시할 때 UIKit이 비슷하게 또는 약간 더 빠르게 수행됨을 보여줍니다. Wiertel과 Skublewska-Paszkowska [37]의 연구에서는 이미지, 지도, 텍스트 구성 요소를 포함하는 뷰가 제시되며, 이 UIKit 버전의 뷰가 iPad Pro 11 (2020)에서 32ms, iPhone 12 mini에서 88ms 더 빠르게 수행됨을 밝힙니다. 단일 뷰에 여러 구성 요소가 존재하는 상황에서 어떤 특정 구성 요소가 앱의 성능 저하에 기여하는지 구별하는 것은 도전적일 수 있습니다. 그러나 연구에서 이미지 구성 요소가 SwiftUI와 UIKit에서 비슷하게 수행되고, 성능 차이는 SwiftUI에서 느리게 동작하는 지도 및 텍스트 구성 요소에서 발생할 수도 있습니다. 그러나 그들의 뷰에 있는 모든 구성 요소가 SwiftUI의 느린 성능에 비슷하게 기여한다고 가정한다면, 우리의 이미지 시나리오에서의 발견 사항은 Wiertel과 Skublewska-Paszkowska의 [37] 연구에서 보고된 결과와 일치합니다. 이 시나리오는 우리 연구의 전형적인 앱 시나리오와 더 밀접하게 일치하며, 여기서 다양한 구성 요소들이 프로필 페이지를 구성합니다. 따라서 그들의 시나리오와 전형적인 앱 시나리오를 비교할 것입니다.

블러 시나리오

블러 시나리오에서 얻은 결과는 구성 요소 수가 32개 미만일 때 UIKit이 SwiftUI보다 더 빠른 성능을 보여주며, 텍스트, 버튼, 이미지와 같은 다른 시나리오에서 관찰된 결과를 확인시켜 줍니다. 그러나 구성 요소 수가 64개를 초과할 때 흥미로운 현상이 나타납니다: 예상치 못하게 SwiftUI가 성능 면에서 UIKit을 뛰어넘습니다. 이 관찰은 성능 변화에 영향을 미치는 기본 요인에 대한 질문을 제기합니다. 구성 요소 수가 64개를 초과하면 어떤 일이 발생합니까? 이 질문에 대한 답을 얻기 위해 벤치마킹 앱에서 흐린 배경이 어떻게 구성되는지 보여주는 두 개의 코드 조각을 살펴보겠습니다. 첫 번째 코드 조각은 UIKit 구현에 해당합니다. 여기에서는 먼저 블러 효과(UIBlurEffect)가 생성된 다음 블러 뷰(UIVisualEffectView)에 추가됩니다. 마지막으로 블러 뷰는 크기가 조정(자르기)되어 화면에 표시되기 위해 수평 스택뷰에 추가됩니다. 블러 효과와 블러 뷰를 생성하는 메모리 할당은 UIKit 내의 힙 메모리에서 이루어집니다.

두 번째 코드 조각은 SwiftUI 구현에 해당합니다. 여기에서는 흐린 배경이 있는 사각형이 생성됩니다. SwiftUI에서 사각형은 구조체로, 값 유형을 나타냅니다. SwiftUI의 값 유형은 불변이며 스택 메모리에 할당됩니다.

구성 요소 수가 64개를 초과할 때 SwiftUI의 성능이 우수한 한 가지 가능한 설명은 SwiftUI에서 각 블러 구성 요소가 값 유형을 나타내는 구조체라는 점입니다. 값 유형은 스택 메모리에 할당되므로 할당하기에 더 비용 효율적이며, UIKit에서 필요한 힙 할당과 비교하여 메모리 관리를 단순화합니다. 여기서 iOS 런타임 시스템이 힙 메모리의 영역을 잠그고 할당을 위한 여유 공간을 찾아야 합니다 [43]. UIKit에서 흐린 배경을 생성하는 과정은 효과 생성, 블러 뷰 추가, 크기 조정 등의 추가 단계를 포함하며, 이러한 단계가 성능 오버헤드에 기여할 수 있습니다. 이 단계들과 힙 메모리 할당은 구성 요소 수가 낮을 때는 무시할 수 있는 영향을 미칠 수 있지만, 특히 64개를 초과하는 경우 UIKit의 느린 성능의 잠재적 원인이 될 수 있는 이러한 단계들과 메모리 할당의 누적 효과가 발생할 수 있습니다.

CollectionView 시나리오

UIKit 플롯에서 주목할만한 점은 컬렉션 뷰에서 4개 이상의 행이 표시될 때 눈에 띄게 평탄화되는 현상입니다. 이러한 동작은 컬렉션 뷰의 고유한 지연성과 관련이 있을 가능성이 크며, 현재 사용자의 화면에 보이는 행만 표시하는 것을 우선시하고 나머지 행은 필요할 때까지 표시를 지연시킵니다. SwiftUI에서도 행의 수가 4개를 초과하고 때로는 8개를 초과할 때 유사한 추세가 관찰됩니다. 이는 이 시나리오의 메모리 플롯에서도 볼 수 있습니다.

두 번째 코드 조각에서는 SwiftUI 구현에 해당하여, 흐린 배경이 있는 사각형이 생성됩니다. SwiftUI에서 사각형은 구조체로, 값 유형을 나타냅니다. SwiftUI의 값 유형은 불변이며 스택 메모리에 할당됩니다.

Wiertel과 Skublewska-Paszkowska [37]의 연구에서는 컬렉션 뷰를 처리하는 데 있어 UIKit과 SwiftUI의 성능을 평가하기 위해 비교 분석이 수행되었습니다. SwiftUI는 컬렉션 뷰 구성 요소에 직접 대응하는 것을 제공하지 않기 때문에 연구자들은 콘텐츠 스크롤 기능이 있는 ScrollView 구성 요소를 사용하여 콘텐츠를 표시하였습니다. 그들의 조사 결과는 UIKit이 SwiftUI에 비해 느린 성능을 보여주며, iPad Pro 11 (2020)에서 98ms, iPhone 12 mini에서 45ms의 시간 차이를 보였습니다. 이러한 결과는 우리가 사용한 컬렉션 뷰 시나리오의 결과와 다릅니다. 우리의 컬렉션 뷰 시나리오 결과는 UIKit이 컬렉션 뷰를 표시하는 데 SwiftUI보다 최대 3배 더 빠르며, 이 시나리오에서 비슷한 콘텐츠를 표시하는 데 SwiftUI가 사용하는 메모리의 약 절반만을 사용합니다.

Wiertel과 Skublewska-Paszkowska [37]의 연구와 달리, 이 연구에서 사용된 SwiftUI 컬렉션 뷰는 List 뷰와 수평 및 수직 스택 뷰를 기반으로 합니다. 구체적으로, 이 시나리오에서는 하트 이미지를 나타내는 이미지 구성 요소를 포함하는 List 뷰로 구성된 카드가 있습니다. 또한, 이 List 뷰는 여러 카드를 포함하여 카드 덱을 구성하기 위해 다른 List 뷰 내에 중첩됩니다. 최종적으로 이 덱들은 화면에 표시되는 최종 List 뷰에 포함됩니다. 이 연구에서 컬렉션 뷰 시나리오는 행과 열의 테이블 셀의 복잡한 배열로, 성능 한계를 식별하기 위한 벤치마크로 사용됩니다. 그러나 실제 앱에서 이렇게 복잡한 컬렉션 뷰를 특징으로 하는 것은 매우 드뭅니다.

현재 이 연구 시점에서 SwiftUI는 여전히 UIKit의 컬렉션 뷰에 정확히 해당하는 구성 요소를 갖추고 있지 않습니다. 따라서 컬렉션 뷰가 앱의 주요 구성 요소가 아닌 경우, UIKit을 SwiftUI보다 선호하는 결정적인 요인으로 UIKit 컬렉션 뷰의 성능만을 고려해서는 안 됩니다. 또한, SwiftUI에는 곧 UIKit의 컬렉션 뷰에 비교할 수 있는 대안이 등장할 수 있으며, 이를 통해 더 정확하게 비교할 수 있을 것입니다.

전형적 앱 및 런치 타임 시나리오

Wiertel과 Skublewska-Paszkowska [37]의 연구는 이미지, 지도, 텍스트 구성 요소를 포함하는 뷰를 표시할 때 SwiftUI와 UIKit의 성능을 탐구합니다. 그들의 결과는 UIKit 버전의 이 뷰가 SwiftUI 버전에 비해 더 나은 성능을 보여주며, iPad Pro 11 (2020)에서 32ms, iPhone 12 mini에서 88ms의 시간 차이를 보였습니다. 이 뷰는 다양한 구성 요소의 성능 차이를 평가하기 위해 다양한 구성 요소를 제시하는 전형적 앱 시나리오와 밀접하게 관련이 있습니다.

전형적 앱 시나리오의 성능 평가는 우리 연구에서 제시된 이전 결과와 일치하며, CPU 시간 면에서 약 20%에서 25% 정도 UIKit이 SwiftUI를 능가하는 것을 보여줍니다. 이 결과는 Wiertel과 Skublewska-Paszkowska [37]의 조사 결과와 조화를 이루고, 구성 요소의 조합을 처리할 때 UIKit이 일반적으로 SwiftUI보다 우수하다는 개념을 강화합니다. 또한, 우리의 결과는 UIKit이 구성 요소의 혼합을 다룰 때 일반적으로 더 메모리 효율적이며, 더 낮은 메모리 소비를 보여준다는 것을 나타냅니다.

SwiftUI에서 관찰된 더 높은 CPU 시간은 호스팅 회사의 엔지니어들이 지적한 대로 UIKit 주위에 래퍼로서의 SwiftUI의 특성에 기인할 수 있습니다. 결과적으로 SwiftUI의 CPU 시간은 UIKit 작업에 필요한 CPU 시간과 SwiftUI 자체의 래퍼로 인해 발생하는 추가 CPU 시간을 모두 포함할 수 있습니다. 이 경향은 런치 타임 시나리오에서도 분명히 나타나며, 여기에서는 UIKit이 SwiftUI에 비해 약 5%에서 25%의 평균 성능 우위를 보여줍니다. 심지어 Wiertel과 Skublewska-Paszkowska [37]의 연구에서도 단일 텍스트 구성 요소를 포함하는 초기 뷰가 UIKit에서 더 빠른 런치 타임을 보여주었으며, iPad Pro 11 (2020)에서 44ms, iPhone 12 mini에서 149ms의 차이가 나타났습니다. 따라서, 우리의 발견은 Wiertel과 Skublewska-Paszkowska의 [37] 연구 결과를 뒷받침하며, 일반적으로 UIKit 앱이 SwiftUI 앱보다 더 빠른 런치 시간을 달성한다는 것을 나타냅니다.

프레임워크 성능과 다양한 기기 비교

벤치마킹 앱의 메모리 사용과 관련하여 다양한 벤치마크된 기기의 맥락에서 흥미로운 관찰이 있습니다. 특히 SwiftUI와 UIKit 앱의 메모리 소비는 기기의 화면 크기와 해상도에 관계없이 일관되게 유지됩니다. 예를 들어, iPhone 8 Plus에서 UIKit 버전의 앱으로 64개의 버튼을 표시하는 데 약 17MB의 메모리가 필요하며, 이 기기는 1080 x 1920 (2073600) 픽셀의 화면 해상도를 가지고 있습니다.

놀랍게도 메모리 소비는 일정하게 유지되며, 해상도가 1179 x 2556 (3013524) 픽셀인 iPhone 14에서도 64개의 버튼을 표시하는 데 동일한 17MB의 메모리가 사용됩니다. 이는 iPhone 8 Plus에 비해 약 30% 더 많은 픽셀임에도 불구하고 그렇습니다.

또 다른 주목할 만한 관찰은 다양한 iOS 기기에 걸쳐 일관되게 유지되는 UIKit과 SwiftUI 간의 성능 차이와 관련이 있습니다. SwiftUI가 2019년에 출시되었음에도 불구하고, 2019년 이후에 출시된 iOS 기기들이 SwiftUI에 대해 특별히 최적화된 하드웨어를 가지고 있을 것이라고 가정할 수 있으며, 이는 두 프레임워크 간의 성능 격차를 좁힐 수 있을 것입니다. 그러나 다양한 기기에서의 벤치마킹 결과를 통해 UIKit과 SwiftUI 간의 성능 차이가 상대적으로 안정적으로 유지됨을 알 수 있습니다. 예를 들어, iPhone 8 Plus에서 UIKit 버전의 앱으로 64개의 버튼을 표시할 때 SwiftUI 버전에 비해 약 14%의 성능 우위를 보여줍니다. 마찬가지로 iPhone 14에서 같은 수의 버튼을 표시하는 UIKit 버전의 앱은 SwiftUI 버전에 비해 약 22%의 성능 우위를 보여주는데, iPhone 14가 iPhone 8 Plus 출시 6년 후에 출시된 것을 고려하면 그리 큰 차이가 아닙니다. 이 관찰은 일반적으로 UIKit이 사용된 특정 iOS 기기에 관계없이 SwiftUI보다 약간 우수한 성능을 보인다는 추세를 보여줍니다.

윤리적 측면

SwiftUI의 도입으로 전형적인 앱 시나리오에서 UIKit에 비해 SwiftUI가 약 25% 느린 것을 볼 수 있습니다. 이러한 성능 차이는 특히 수백만 대에 달하는 iOS 기기의 전 세계적인 사용을 고려할 때 에너지 소비에 영향을 줄 수 있습니다. SwiftUI 기반 애플리케이션으로 인한 에너지 사용은 환경에 미치는 영향에 대한 우려를 불러일으킵니다. 배터리 사용량의 증가는 자주 배터리를 충전해야 하는 수요를 증가시킵니다. 이러한 배터리 충전 주기는 배터리의 노화 과정을 가속화시켜 결국 배터리 폐기물의 증가로 이어집니다. 배터리 폐기물에는 환경에 해로운 물질이 포함되어 있다는 점을 주목할 가치가 있습니다[44].

이전에 논의된 바와 같이, 32개 미만의 구성 요소를 포함하는 디스플레이 시나리오는 저가형 및 고가형 기기에서 비교적 일관된 성능을 보여줍니다. 이는 흥미로운 질문을 불러일으킵니다: 이러한 기기의 속도와 메모리 능력을 고려할 때, 배터리를 교체할 수 있다면 새로운 iOS 기기를 구매하는 최적의 시기는 언제일까요? 배터리 교체가 가능한 옵션이라면, 이 기기들의 수명은 강력한 하드웨어의 내구성 덕분에 상당히 연장될 수 있습니다. 결과적으로, 새로운 iOS 기기에 대한 수요가 감소하여 생산 감소를 이끌고 지구 온난화를 완화하는 데 도움이 되는 환경적인 긍정적 영향을 미칠 수 있습니다. 이 연구의 결과는 저가형 iOS 기기가 교체 가능한 배터리를 갖춘다면 여전히 적절한 성능을 제공할 수 있으며, 이는 생산율을 낮추고 궁극적으로 모바일 기기 사용에 있어 더 지속 가능한 접근 방식을 이끌 수 있음을 제안합니다.

요약

연구 결과에 따르면, 대부분의 시나리오에서 UIKit이 SwiftUI보다 약간 더 우수한 성능을 보인다는 것이 분명합니다. 예외는 구성 요소 수가 32를 초과할 때 UIKit의 CPU 시간이 SwiftUI보다 높았던 블러 시나리오입니다. 배경 블러는 앱에서 자주 사용되는 UI 요소이지만, 다른 구성 요소들에 비해 사용 빈도는 낮습니다. 예를 들어, 다양한 액션을 갖는 열 개의 버튼이 각기 다른 배경 블러를 가진 뷰에 있을 가능성이 더 높습니다. 따라서 구성 요소 수가 32를 초과하는 경우 배경 블러를 표시하는 데 있어 SwiftUI의 성능이 더 우수함에도 불구하고, 다른 UI 구성 요소의 표시 속도가 느린 것이 UIKit이 SwiftUI보다 더 빠르다는 결론에 기여합니다.

이전 장의 결과에 따르면, 모든 시나리오에서 SwiftUI가 UIKit보다 약간 더 많은 메모리를 사용하는 것으로 나타났습니다. 이 차이는 중요하지 않게 보일 수 있습니다. 버튼 및 컬렉션 뷰 시나리오는 SwiftUI의 메모리 사용량이 UIKit보다 현저히 높은 두 가지 시나리오입니다. 버튼 시나리오에서 구성 요소 수가 64를 초과할 때 SwiftUI의 메모리 사용량은 UIKit의 두 배가 됩니다. 컬렉션 뷰 시나리오에서는 SwiftUI가 UIKit의 컬렉션 뷰에 대한 직접적인 대응 부재로 인해 UIKit에 비해 두 배의 메모리를 소비합니다.

구성 요소 수가 32 미만인 경우, 다양한 시나리오에서 SwiftUI와 UIKit 사이의 메모리 사용 차이는 최대 5MB로, 테스트된 모든 iOS 기기에 있는 메모리 양을 고려할 때 실제 애플리케이션에서는 중요하지 않은 차이입니다. 이 연구에서 저가형 벤치마킹 기기로 사용된 iPhone 8 Plus조차 3GB의 RAM을 가지고 있습니다. 따라서 5MB의 메모리 사용 증가는 중요하지 않으며 메모리 부족으로 인한 앱 충돌을 일으킬 가능성은 낮습니다.

단일 뷰에서 2048개의 이미지를 표시하는 이미지 시나리오와 같은 복잡한 시나리오에서조차, SwiftUI 벤치마킹 앱은 총 250MB의 메모리만을 사용합니다. 이 양은 기기의 사용 가능한 메모리 용량을 훨씬 밑돌며, 극단적인 경우에도 실제 앱 사용에서 SwiftUI와 UIKit 간의 메모리 사용 차이는 일반적으로 무시할 수 있음을 강조합니다.