공간 컴퓨팅에 맞게 앱 전력과 성능 최적화하기

♪ 감미로운 인스트루멘탈 힙합 ♪ ♪ 안녕하세요 저는 로이입니다 성능 팀의 엔지니어죠 오늘은 여러분의 앱을 공간 컴퓨팅에 맞게 최적화하는 방법을 알아보겠습니다 이 새로운 플랫폼의 성능과 전력이 어떤 면에서 독특한지 먼저 살펴볼 겁니다 이어서 성능 계획 빌드도 검토해 보고요 앱 프로파일링부터 다뤄보죠 마지막으로는 이 플랫폼에서 성능 문제를 최적화할 최선의 방법을 두루 살펴보겠습니다 전력과 성능 측면에서 공간 컴퓨팅은 무엇이 다를까요? 우선 콘텐츠의 디스플레이가 앱 업데이트와 무관하게 항상 업데이트된다는 점입니다 사람들이 몸이나 손 혹은 눈을 움직일 때마다 콘텐츠는 업데이트되어야 합니다 그러니 시스템은 모든 프레임을 상시로 렌더링하고 있죠 이 플랫폼은 공간 알고리즘을 항상 실행해서 모든 앱에서 비주얼과 상호 작용을 만들어 냅니다 여러 앱을 동시에 실행할 수도 있고요 여러분의 앱은 다른 앱과 함께 사용될 텐데요 다중 작업과 추가 시스템 작업을 처리하려면 앱 리소스 사용을 최대한 최적화해야 합니다 멋진 사용자 경험을 전달하려면 앱의 성능이 핵심입니다 사람들은 앱이 입력에 즉시 반응하고 비주얼 업데이트가 매끄럽게 되기를 바랍니다 그래야 몰입감이 생기고 편안하게 느껴지죠 앱에서 성능 문제를 어떻게 프로파일링하고 분석할지 말씀드리겠습니다 성능 메트릭은 다른 Apple 플랫폼에서 익히 접하셨을 수도 있습니다 어떤 플랫폼이든 사람들은 앱이 빠르게 실행되고 디스크를 마모하지 않으며 배터리를 과하게 쓰지 않길 바라죠 비효율적인 메모리 사용으로 앱이 종료되는 것도 바라지 않습니다 공간 컴퓨팅 환경에서는 이런 메트릭 일부에 새로운 의미가 생기는데요 전력을 봅시다 사용자가 앱에서 전력 최적화를 원하는 건 배터리 사용 시간보다는 열 압력 때문입니다 훌륭한 성능을 유지하려면 앱의 시스템 전력 사용을 최적화해서 열 압력이 발생할 가능성을 줄여야 합니다 행을 봐도 그렇죠 행은 작업 중에 앱의 메인 스레드가 일정 시간 지연될 때 발생합니다 하지만 이 플랫폼에서는 사소하고 순간적인 지연으로도 반응성이 크게 타격을 입습니다 이제 렌더링을 봅시다 다른 플랫폼에서 렌더링 성능을 최적화하는 건 주로 매끄러운 UI와 3D 애니메이션을 제공하기 위해서일 텐데요 여기서는 시스템이 항상 렌더링 중이므로 정적 콘텐츠에서도 렌더링 성능이 중요합니다 이런 메트릭의 프로파일링 도구는 모든 Apple 플랫폼에서 제공됩니다 오늘은 공간 컴퓨팅 앱 위주로 성능 문제를 발견하는 법을 다루겠습니다만 Apple 플랫폼에서 수행하는 이런 메트릭 최적화에 대해 더 알고 싶으시다면 다음 세션을 확인해 주세요 '응용 프로그램 성능 최종 서바이벌 가이드'입니다 앱을 최적화하려면 개발하는 동안 프로파일링하세요 Instruments나 Xcode Gauges 등의 도구를 사용해서요 앱을 출시한 뒤에는 앱을 한층 더 최적화할 현장 데이터를 더 수집하시고요 개발 중 프로파일링을 더 살펴보겠습니다 RealityKit Trace는 Instruments의 최신 템플릿으로 모든 공간 컴퓨팅 앱에서 성능과 전력 프로파일링을 지원합니다 앱이 저조한 렌더링 성능을 보이거나 시스템 전력 사용량이 많아질 때 이를 확인할 수 있는 놀라운 도구인데요 사용하실 수 있는 Instruments 템플릿은 더 많습니다 이 새로운 템플릿이 사용되는 실제 모습을 더 살펴보려면 'RealityKit Trace 알아보기'를 시청해 주세요 여러분 앱의 성능과 전력은 상호 작용 방식에 따라 달라집니다 시뮬레이터는 실제 기기처럼 작업을 수행하지는 않으니 그 성능 데이터가 정확하지 않을 수 있습니다 프로파일링은 기기 내에서 하세요 오디오 혹은 영상을 재생하거나 FaceTime과 Persona 같은 기술을 사용할 때 생기는 앱 내 다양한 상호 작용으로 프로파일링하는 거죠 사용하는 동안 성능이 우수하고 시스템 전력이 적게 드는지를 반드시 검사해야 합니다 마지막으로는 다른 앱도 실행되어 리소스가 사용되는 동안 프로파일링하도록 하세요 호환이 가능한 iPad와 iPhone 앱을 가져온다면 기기에서 앱을 프로파일링해서 추가 최적화가 필요한지를 꼭 확인하시고요 개발이 끝나면 사람들은 여러분의 앱을 다양한 조건에서 실행할 겁니다 현장에서 얻는 데이터는 사람들이 실제로 겪는 문제를 찾아내기에 좋은 방법이죠 앱이 베타 릴리즈 상태거나 공개 출시가 되었을 때는 MetricKit로 사용자에게서 진단 보고서를 받으세요 Xcode Organizer는 동의한 사용자의 기기에서 집계된 성능 데이터를 제공하는데 전력 문제를 찾아내는 에너지 진단도 포함됩니다 이렇게 모은 데이터로는 병목 현상을 발견하고 앱의 성능 작업을 우선적으로 처리할 수 있습니다 이제 공간 컴퓨팅 앱 최적화를 살펴봅시다 성능 문제는 많은 영역에서 발생할 수 있는데요 오늘 최적화 전략을 세워볼 대상은 핵심 영역인 렌더링, 사용자 입력, ARKit와 오디오 및 비디오 재생과 SharePlay 시스템 압력에 의한 앱 종료입니다 뛰어난 렌더링 성능은 멋진 사용자 경험을 위해 특히 우선시되어야 할 사항인데요 함께 파고들어 봅시다 이 플랫폼에서는 앱과 함께 렌더링 파이프라인이 실행되어 앱 콘텐츠를 업데이트합니다 모든 Apple 플랫폼에서 그렇듯 앱 인터페이스는 메인 스레드에서 업데이트되며 즉시 업데이트를 제공해야 하죠 여러분의 앱은 다른 앱과 함께 3D 공간에 렌더링되니 업데이트는 시스템 렌더 서버로 전송됩니다 렌더 서버는 계속 실행되면서 앱과 사용자 입력 그리고 공간과 주변 환경의 업데이트를 처리합니다 모든 업데이트를 반영해 새 프레임을 렌더링해서 이를 컴포지터로 전송하죠 컴포지터는 언제나 렌더링 중입니다 디스플레이의 재생률에 매칭되는 속도로 디스플레이에 새 프레임을 공급하죠 이는 편안한 경험을 제공하는 데 도움이 됩니다 속도는 보통 초당 90프레임이지만 더 빠를 수도 있습니다 컴포지터가 지속적으로 디스플레이를 업데이트해도 멋진 사용자 경험을 위해서는 여전히 비주얼 업데이트가 앱에서 빠르게 이뤄져야 하는데요 앱 콘텐츠나 업데이트의 렌더링 시간이 너무 길면 렌더 서버가 최적 렌더링 지연 시간에 맞는 렌더링 데드라인을 놓칠 수도 있습니다 Y 프레임 컴포지터에 갔어야 할 앱의 비주얼이 그러지 못하고 대신 Y+1 프레임에 간다는 뜻이죠 이러면 디스플레이에서 보는 비주얼 업데이트가 지연되고 앱의 반응성이 떨어진다는 느낌이 듭니다 렌더링 지연이 유독 심하면 앱이 종료될 수도 있죠 SwiftUI, UIKit RealityKit, Metal 중에서 무엇으로 앱을 빌드했든 앱의 콘텐츠와 업데이트는 프레임 드롭과 렌더 서버 내의 작업이 줄도록 최적화하는 게 좋습니다 SwiftUI와 UIKit 사용 최적화를 먼저 살펴보죠 이 플랫폼에서 시스템은 앱 업데이트가 없더라도 정적 UI 콘텐츠에 렌더링 작업을 수행합니다 오버드로우 때문에 렌더링 작업이 늘어날 수 있는데요 오버드로우가 발생하는 건 투명한 콘텐츠가 다른 가상 콘텐츠 앞에 있을 때입니다 GPU가 동작해 두 콘텐츠를 모두 렌더링해야 하지만 그 투명한 콘텐츠가 완전히 불투명하다면 GPU는 그 뒤의 UI를 렌더링할 필요가 없겠죠 Z 오프셋이 있는 UI 뷰가 겹쳐 있으면 투명도를 더하지 않는 게 좋습니다 여러분의 앱 UI가 디스플레이에서 픽셀을 더 많이 차지할수록 윈도우 렌더링 작업도 더 많이 수행됩니다 기본 크기를 줄이는 것을 고려해 보세요 렌더 서버의 UI 리드로우를 트리거하는 건 보통 앱 업데이트지만 이 플랫폼에서는 Core Animation 레이어의 동적 콘텐츠 스케일링으로도 리드로우가 트리거됩니다 이 동작 덕분에 텍스트와 벡터 기반 UI 콘텐츠의 해상도가 사용자 시선에 따라 변하면서 비주얼이 더 선명해지죠 UI 콘텐츠 리드로우 역시 앱 업데이트가 없더라도 더 높은 스케일과 빈도로 일어날 겁니다 SwiftUI와 UIKit는 이 동작을 기본으로 활성화하지만 사용자 지정 Core Animation을 쓰거나 Core Graphics 렌더링을 하는 앱이 이 동작을 선택할 수도 있습니다 시각적인 이점과 포기할 점을 더 알아보려면 다음 세션을 시청해 주세요 '공간 컴퓨팅을 위한 렌더링 살펴보기'입니다 이런 리드로우 비용에는 오프스크린 렌더 패스가 막대한 영향을 미칩니다 섀도와 블러, 마스킹 같은 시각 효과가 원인이 될 수 있는데요 시스템에서 쉽게 렌더링되는 앱을 만들려면 이런 효과를 줄여 주세요 앱 리드로우를 최소화하려면 불필요한 뷰 업데이트를 가능한 한 피해야 합니다 SwiftUI를 쓴다면 @Observable을 사용하세요 @Observable로 변경 내용을 더 세밀하게 추적하고 불필요한 레이아웃 업데이트를 줄일 수 있습니다 이제 RealityKit를 사용하는 3D 렌더링 최적화를 알아보겠습니다 올해 SwiftUI는 RealityView를 공간 컴퓨팅을 위해 추가했습니다 RealityKit의 3D scene을 SwiftUI 계층에서 네이티브로 볼 수 있죠 모든 RealityKit 기능에 맞게 3D scene을 최적화하면 여러분의 앱은 이 플랫폼의 훌륭한 구성원이 될 겁니다 이런 3D scene에서는 포함된 에셋의 복잡도 때문에 각 프레임에 들어가는 렌더 서버 작업이 대폭 늘어날 수 있습니다 그러니 이런 에셋부터 최적화해 봅시다 Reality Composer Pro의 도움을 받으면 에셋으로 RealityKit scene을 만들 수 있습니다 메시 렌더링과 파티클 애니메이션 그리고 물리와 오디오 작업에서 이 도구가 전체 scene의 통계를 제공하니 성능 영향을 이해할 수 있죠 이 통계를 검토할 때는 보통 숫자가 작을수록 작업이 적어져 렌더링 성능이 좋아집니다 관련 세션인 'Quick Look 공간 경험을 위한 3D 모델 만들기'를 시청하시면 3D 에셋의 비주얼과 전력 사용에 대한 모범 사례를 더 알아보실 수 있습니다 특히 메시 렌더링은 3D 렌더링의 핵심입니다 복잡한 메시와 머티리얼은 순식간에 성능 병목 현상을 일으키거든요 메시 에셋의 지오메트리를 최적화해야 합니다 머티리얼을 공유하는 부분은 결합해서 분리된 메시의 양을 줄이고요 삼각형과 꼭짓점 수가 많은 메시 지오메트리도 비용이 많이 듭니다 이 수가 제일 적은 에셋을 필요에 따라 사용하세요 오버드로우의 영향은 3D 메시로 최소화해야 합니다 그러려면 UI 콘텐츠와 마찬가지로 투명도를 제한적으로 써 주세요 Reality Composer Pro의 Physically Based 머티리얼은 환경 조명이 있고 최적화가 잘되어 있으며 최소한의 투명도가 들어간 메시와 잘 어울립니다 하지만 콘텐츠가 투명하거나 아주 크다면 Custom 머티리얼을 언릿 표면으로 사용해 보세요 베이크드 조명 텍스처 등 비용이 적은 비주얼을 쓰고요 그러면 비용이 더 드는 조명 계산 때문에 혹시 생길지 모를 병목 현상을 피할 수 있습니다 RealityKit의 머티리얼 빌드와 사용에 대해 안내가 더 필요하시면 다음 두 세션을 시청해 주세요 런타임 렌더링에 콘텐츠를 최적화한 건 좋은 시작이지만 RealityKit로 앱을 최적화할 때 할 수 있는 일은 여기에 그치지 않습니다 앱이 RealityKit 콘텐츠를 업데이트하면 업데이트 내용이 렌더 서버로 전송됩니다 서버는 이를 적용하고 렌더링하죠 하지만 단시간에 업데이트가 너무 많아지면 렌더 서버에 병목 현상이 생길 수 있습니다 여러분의 앱에서 RealityKit 엔티티 생성 및 수정이 빠르게 이뤄지고 있다고 해 보죠 복잡한 애니메이션이 너무 많거나 SwiftUI 뷰를 너무 많이 업데이트하거나 한 프레임에 에셋을 너무 많이 로딩하고 있는 겁니다 엔티티는 미리 생성하고 필요에 따라 숨기거나 표시하세요 이걸 삭제하고 scene 계층에 추가하거나 isEnabled 플래그를 쓰면 됩니다 업데이트되는 엔티티의 양을 최소화하려면 메시 엔티티 계층을 평면화하면 됩니다 코드 기반 애니메이션이라면 업데이트율을 낮추거나 애니메이션이 업데이트하는 엔티티 수를 줄여 보시고요 RealityKit 엔티티를 업데이트할 때는 과도한 SwiftUI 리드로우를 트리거하지 않도록 주의하세요 어태치먼트를 사용할 때는 반드시 모든 SwiftUI 콘텐츠 최적화와 같은 방식으로 렌더링을 최적화해 주세요 복잡한 에셋을 로딩해도 렌더링 업데이트 비용이 높아질 수 있습니다 에셋이 복잡하면 앱 시작 시간과 콘텐츠 로딩 시간이 길어질 수도 있죠 런타임 중에는 비동기 로딩 API를 사용해서 메인 스레드 차단을 방지하고 필요해지기 한참 전에 에셋을 로딩하세요 동일한 에셋을 사용하는 엔티티는 그 에셋을 공유할 수 있어서 로딩도 한 번만 합니다 Reality Composer Pro에서 내보낸 파일을 사용하세요 이 파일은 로딩 시간과 메모리 비용이 최적화되어 있거든요 텍스처 압축도 비용 없이 가능합니다 에셋 사이즈를 줄이면 로딩 속도는 보통 올라가지만 텍스처 압축은 Reality Composer Pro 파일에서 이미 이뤄지므로 직접 할 필요가 없다는 걸 기억해 두세요 끝으로 RealityKit의 몰입형 경험을 살펴보겠습니다 앱에서 전용 풀 스페이스로 이동할 것을 요청하면 이게 유일하게 실행되는 포그라운드 경험이 됩니다 포털을 사용하거나 완전 몰입형 경험으로 이동할 때는 사용자 주변 환경도 일부나 전부가 시스템에서 숨겨집니다 앱에서 공간을 채울 환경은 RealityKit 콘텐츠로 만들 수 있습니다 완전 몰입형 콘텐츠의 렌더링은 디스플레이에서 공유 스페이스나 풀 스페이스의 scene보다 더 많은 픽셀로 이뤄져야 합니다 이는 GPU에서 콘텐츠 렌더링을 위한 작업이 더 많이 수행될 수 있다는 뜻이죠 GPU 전력 사용에 맞게 이 유형의 콘텐츠를 최적화하세요 최적의 전력 사용을 위해서는 먼저 Reality Composer Pro에서 언릿 표면의 Custom 머티리얼을 사용하시면 됩니다 그러지 않고 동적 조명의 느낌을 내려면 베이크드 조명 텍스처나 시간 기반 애니메이션 사용을 고려해 보시고요 머티리얼의 시스템 전원과 렌더링 성능을 프로파일링하세요 완전 몰입형 경험은 Metal로도 만들 수 있는데요 3D 엔진이나 경험을 Metal로 빌드할 때 최적화해야 할 사항을 말씀드리겠습니다 CompositorServices 프레임워크와 Metal을 함께 사용하면 렌더 서버를 우회하고 렌더링된 표면을 컴포지터에 바로 보낼 수 있습니다 '몰입형 앱을 위한 Metal 알아보기'를 보시면 이 과정을 제대로 수행하는 방법이 나옵니다 CompositorServices를 쓸 때는 Metal 프레임의 제출 속도를 유지해서 컴포지터가 업데이트 때마다 새 프레임을 받게 하세요 새 포비에이션 맵을 반드시 쿼리하고 각 프레임을 사후 예측 해 주고요 이 입력 데이터는 마지막에 쿼리하세요 GPU 작업 인코딩에 사용하기 전에요 세 가지를 모두 하면 사용자의 동작과 입력에 따른 반응형 가상 콘텐츠를 잘 만들 수 있습니다 앱의 새 프레임 제출이 너무 오래 걸리면 시스템이 앱을 종료합니다 프레임 지연이 길어지지 않게 하세요 앱을 실행하는 동안 GPU 성능은 Metal 시스템 트레이스의 Instruments 템플릿으로 프로파일링하시고요 Metal 앱이나 사용자 지정 머티리얼에서 Reality Composer Pro로 조각이 장기로 실행되거나 꼭짓점 셰이더가 실행되면 시스템 렌더링 시간에 막대한 영향을 미칠 수 있습니다 조각과 꼭짓점 시간을 줄이려면 먼저 ALU 명령어와 셰이더의 텍스처 접근을 줄이세요 Metal에서는 최대한 컴퓨트 셰이더로 대신하고요 GPU 성능 최적화를 더 알고 싶으면 아래 세션을 찾아보세요 UI와 3D 렌더링 성능을 위해 앱을 최적화하면 사용자 경험 전반에 유익하다는 걸 기억하시길 바랍니다 이제 입력 성능으로 넘어가 봅시다 이 플랫폼에서는 눈, 손, 음성 입력과 하드웨어 입력을 사용할 수 있습니다 입력에 대한 앱 업데이트는 메인 스레드에서 처리되는데요 이 작업이 너무 오래 걸리면 앱의 속도가 느리고 반응성이 떨어진다는 느낌이 들죠 메인 스레드의 입력값 업데이트는 디스플레이 재생률에 따른 데드라인에 맞춰 완수돼야 합니다 이런 플랫폼의 하드웨어는 대개 재생률이 90Hz 이상입니다 재생률이 90Hz일 때 지연 시간을 최적화하려면 입력값 업데이트를 8밀리초 미만으로 유지하세요 공간 콘텐츠와 상호 작용할 때는 시스템이 적중 테스트를 수행해서 사용자가 상호 작용하려는 UI나 3D 콘텐츠를 확인합니다 RealityKit 콘텐츠에서 상호 작용을 하려면 물리 콜라이더를 추가해야 합니다 이런 콜라이더를 추가할 때는 가능하면 동적 콜라이더보다는 정적 콜라이더를 쓰는 게 좋습니다 정적 콜라이더가 비용이 적게 들거든요 앱의 적중 테스트 작업에서 중복을 줄이려면 상호작용형 콘텐츠가 겹치는 걸 최소화하세요 이제 ARKit로 넘어가겠습니다 이 플랫폼에서는 ARKit 알고리즘이 항상 실행되면서 모든 앱의 비주얼과 상호 작용을 만듭니다 앱이 영향을 미치는 시스템 전원과 비주얼의 매끄러움 정도는 ARKit 데이터 사용과 가상 콘텐츠 앵커링 방식에 달렸죠 예를 들어 앱에서는 ARKit나 RealityKit로 사용자의 주변 환경이나 머리 혹은 손에 앵커 콘텐츠가 배치됩니다 모든 앵커는 시스템에 작업을 추가합니다 콘텐츠를 앵커링할 때는 사용자의 공간에서 앵커의 지속 추적이 필요한지 생각해 주세요 RealityKit에서 AnchorComponent를 쓸 때는 지속적인 추적 비용이 들지 않게 once 추적 모드를 씁니다 영구 앵커와 임시 앵커의 총량을 앱에서 최소화해야 하는데요 특히 영구 앵커는 모든 앱에서 추가될 수 있으니 여러분의 앱에서 과하게 추가되지 않게 하세요 ARKit 데이터를 사용하는 동안 수행할 수 있는 최적화는 더 많습니다 너무 오래된 ARKit 데이터가 앱 콘텐츠에 적용되면 앱의 비주얼이 입력과 동기화되지 않는 것처럼 보입니다 ARKit 데이터는 사용 필요 시점 직전에 쿼리하고 즉시 업데이트에 적용하세요 사후 예측 연산에는 비용이 많이 듭니다 이는 대개 사용자가 지정한 Metal 렌더링 엔진에만 필요한 데이터인데요 scene에 앱 콘텐츠를 배치하기만 한다면 RealityKit가 훌륭한 대안이 됩니다 scene 이해 메시를 위한 충돌 데이터 생성에도 비용이 많이 들어갑니다 이 데이터를 사용한다면 필요하지 않을 때는 기능을 꺼 두세요 이제 오디오 및 비디오 재생을 공간 컴퓨팅에 최적화하는 과정을 알아봅시다 이 플랫폼에서는 공간 음향이 기본으로 사용됩니다 시스템은 사용자의 위치 및 주변 환경 정보와 오디오를 출력하는 오디오 소스의 정보를 실시간으로 처리하죠 앱에서 공간 음향 작업이 과도하게 유발되면 시스템 전력 사용에 문제가 생기거나 오디오 출력이 지연될 수 있습니다 이런 문제를 발견하면 공간 음향 작업을 줄이기 위해 크게 세 가지 사항을 살펴봐야 합니다 동시 재생 중인 오디오 소스와 움직이는 오디오 소스의 수 그리고 사운드스테이지의 크기죠 모두 연산 작업을 증가시키는 변수입니다 이제 비디오를 살펴보죠 공유 스페이스에서는 동시에 여러 비디오를 재생할 수 있습니다 시스템은 비디오마다 디코딩을 진행하고 이를 렌더 서버에서 렌더링해야 합니다 새로 렌더링된 비디오 프레임이 각각 일정한 간격으로 디스플레이에 전달되어야 멋진 비디오 시청 경험이 가능합니다 렌더링 데드라인을 맞출 전력과 시간을 렌더 서버에 주려면 앱은 비디오가 재생되는 동안 UI와 3D 콘텐츠 업데이트를 최소화해야 합니다 비디오의 프레임률은 수행된 작업에도 영향을 주죠 최적의 성능과 전력을 위해서는 24Hz나 30Hz 비디오 사용을 고려해 보세요 끝으로 어느 시점에든 여러분의 앱에서 동시에 재생되고 기기 내에서 렌더링되어야 할 비디오의 수를 줄여야 합니다 비디오를 보여 줄 방식을 선택할 때는 각종 기능과 성능을 어떻게 최적화할지를 생각하시고요 더 알아보실 분은 '훌륭한 공간 재생 경험 만들기'를 보시면 좋습니다 이제 SharePlay를 살펴봅시다 이 플랫폼 덕분에 협업과 연결의 경험에 완전히 새로운 장이 열렸는데요 멋진 SharePlay 그룹 경험을 만들려면 앱이 오랜 시간 동안 뛰어난 성능을 유지하며 구동되어야 합니다 SharePlay를 쓸 때 공간 컴퓨팅 성능이 잘 나오려면 기본부터 갖춰져야 합니다 우선 로컬 성능에 맞게 앱을 프로파일링하고 최적화한 뒤 SharePlay 중에 앱 성능을 검사해서 비용이 많이 드는 렌더링 업데이트가 기기에 동기화되지 않게 하세요 앱 전력을 프로파일링해서 시스템 전력 요구로 열 압력이 발생하지 않게 하고요 열 압력은 앱이 뛰어난 성능을 지속하는 데 방해가 될 수 있습니다 이를 개선하려면 세심한 고민이 필요합니다 여러분 앱의 SharePlay 경험에 어떤 작업과 기능이 필수인지를 생각하시고 필요하지 않은 건 모두 꺼 주세요 마지막으로 열이나 메모리 압력 때문에 앱이 종료되는 경우를 살펴봅시다 따뜻한 곳에서 기기를 사용할 때가 있을 텐데요 시스템은 모든 Apple 플랫폼에서 그렇듯 열 압력하에서 사용 가능한 연산 리소스를 관리합니다 사용하는 동안 기기를 시원하고 편안하게 유지하기 위해서죠 연산 리소스가 적으면 앱 성능이 영향을 받습니다 심지어는 시스템이 앱을 종료할 수도 있죠 열 압력이 치명적이라거나 렌더링 데드라인이 더는 맞지 않는다는 이유로요 열 압력하에서는 좋은 성능이 유지되도록 앱에서 작업을 덜 수행하고 열 압력이 그보다 더 높아지지 않게 하세요 이를 수행할 때 구독할 것이 thermalStateDidChange Notification입니다 압력이 높아지면 앱 콘텐츠를 조정하고 거기에 맞게 업데이트해야 합니다 열 압력이 있을 때 앱이 어떻게 작동하는지 보려면 Xcode에서 thermal inducer를 사용해서 기기의 열이 높아진 상태를 시뮬레이션하세요 열 압력을 더 알아보시려면 아래 세션을 확인하세요 '불리한 네트워크와 온도 조건에서 디자인하기'입니다 다음으로는 메모리 압력을 살펴봅시다 기기에 있는 메모리의 양은 한정적이며 시스템과 실행 중인 모든 앱이 그 메모리를 나눠 씁니다 기기의 사용량이 한도에 가까워지면 시스템이 앱을 종료하기 시작합니다 활발하게 사용되지 않는 앱이 먼저 대상이 되죠 앱 하나가 메모리를 과하게 사용하면 그 앱은 사용 중이라도 종료될 수 있습니다 여러분의 앱이 이렇게 되는 건 바라지 않으시겠죠 이를 방지하려면 앱의 메모리 사용을 최대한 줄여야 합니다 이 플랫폼의 앱에서 다량의 메모리가 할당될 가능성이 큰 작업은 UI 및 3D 렌더링과 오디오 및 비디오 재생입니다 앱에 UI 콘텐츠가 있으면 오프스크린 랜더 패스와 윈도우의 총량과 미디어 콘텐츠를 최소화해서 렌더링 메모리 할당을 줄이세요 RealityKit의 3D 메모리라면 텍스처 해상도와 메시 및 파티클의 지오메트리 크기 조절기가 메모리 사용에 큰 영향을 줄 수 있습니다 이걸 최대한 줄여 주세요 오디오와 비디오를 재생할 때는 앱 내 모든 오디오, 비디오 파일의 총 메모리 로드를 평가해야 합니다 해상도, 비트레이트, 파일 형식 지속 시간을 변경할 때는 사용자 경험과 성능이 메모리 절감과 균형을 이룰 수 있는 방법을 고민해 보면 좋습니다 아래 세션들을 보시면 모든 Apple 플랫폼에서 메모리 풋프린트를 줄이는 팁을 얻을 수 있습니다 이 플랫폼에서 멋진 사용자 경험을 제공하려면 성능이 매우 중요하다는 걸 명심하세요 우선 개발하는 동안 앱을 활발히 프로파일링해서 성능과 전력 문제를 찾아야 합니다 공간 컴퓨팅의 주요 메트릭 위주로 성능 계획을 빌드하고요 렌더링과 전력을 비롯해 오늘 다룬 모든 영역에서 여러분의 앱을 최적화해야 합니다 마지막으로, MetricKit와 Xcode Organizer 등의 도구로 성능 현장 데이터도 수집해야 하고요 여러분이 이 플랫폼에서 만들어 내실 멋진 앱과 경험을 얼른 보고 싶네요 시청해 주셔서 감사합니다 ♪