백그라운드에서 작업 완료하기

백그라운드에서 작업 완료하기

백그라운드 실행의 최신 기술을 알아보고 시스템이 런타임 일정을 조정하는 방법을 알아보세요. 앱이 뛰어난 포그라운드 경험을 유지하면서 백그라운드에 기능을 제공하도록 런타임을 최대한 활용하는 방법을 살펴보겠습니다. 또한 API가 앱에 백그라운드 런타임을 제공하는 방법과 앱이 포그라운드에서 백그라운드로 전환할 때 작업을 완료하게 해주는 iOS 및 iPadOS 26의 새로운 API를 비롯하여 각 API를 다양한 사용 사례에 맞춰 조정하는 방법도 소개합니다.

챕터
- 0:00 - 인사말
- 1:22 - 서론
- 2:09 - 행동 및 제약
- 7:29 - 백그라운드 작업 API
- 11:23 - 지속적 처리 작업
리소스
Apple 소프트웨어 엔지니어 Ryan입니다 앱이 백그라운드 런타임을 어떻게 활용하는지 다뤄봅니다
App Store에는 수많은 앱이 있습니다 각 앱은 고유한 가치를 지닙니다 앱이 가장 빛나는 순간은 화면 한가운데 있을 때입니다 모든 픽셀을 활용해 기억에 남는 경험을 만들 수 있습니다
그리고 사용자는 빠르고 유용하며 완성도 높은 앱을 당연히 기대합니다 하지만 앱이 백그라운드로 전환되면 어떻게 될까요?
이번 세션에서는 백그라운드 런타임을 다루고 앱에 적합한 툴킷을 어떻게 구축할지 살펴보겠습니다 목표는 단순히 앱을 살려두는 것이 아닙니다 미리 데이터를 불러오고 동기화 및 업로드하는 등 성공적인 다음 실행을 위한 준비를 하는 것이 중요합니다 백그라운드 런타임을 잘 활용하면 앱이 더 빠르고 자연스럽고 심지어 마법처럼 느껴질 수 있습니다
먼저 포그라운드와 백그라운드가 무엇인지 설명하고 시스템이 언제 얼마나 자주 백그라운드 실행을 허용하는지에 대한 원칙도 함께 공유하겠습니다
기존의 다양한 실행 방식과 포그라운드에서 시작한 작업을 계속 이어갈 수 있는 새로운 API도 소개하겠습니다
포그라운드 앱은 모두 같은 흐름을 따릅니다
앱 자체와 필요한 모든 것 프레임워크, 애셋 등이 메모리에 로드됩니다 이 상태에서 앱의 인터페이스는 기기의 중심이 되고 앱은 포그라운드로 정의됩니다
사용자가 앱을 나가고도 프로세스가 살아 있으면 앱은 백그라운드로 전환됩니다 기본적으로 백그라운드 앱은 일시 중단됩니다 CPU를 사용하지 않게 됩니다 이는 배터리를 보호하고 개인 정보를 지키며 포그라운드 앱에 리소스를 확보해 줍니다
경우에 따라 앱은 일시 중단 전 작업을 마무리할 수 있도록 백그라운드 실행 시간을 요청할 수 있습니다 사용자가 앱 전환기를 통해 앱으로 돌아오면 앱은 시스템에 의해 다시 포그라운드로 이동됩니다
백그라운드 런타임을 사용하기 전에는 시스템이 리소스를 어떻게 우선순위화하고 관리하는지 그리고 앱 안에서 무엇을 할 수 있을지 이해하는 것이 좋습니다
시스템의 핵심 목표는 명확합니다 배터리 수명을 보호하고 성능을 최적화하며 부드럽고 반응성 있는 사용 경험을 유지하는 것입니다 즉, 백그라운드 실행은 보장되지 않습니다 기회가 있을 때만 허용되고 대부분은 재량에 따라 엄격히 관리됩니다 성공적인 작업은 이런 시스템 맥락을 이해하고 시스템과 협력하는 방향으로 설계됩니다
가장 기본적인 제약은 에너지입니다
모든 작업, CPU 사이클 GPU 렌더링, 네트워크 요청 Neural Engine까지 모두 배터리를 소모합니다 배터리 수명은 한정된 리소스입니다 이를 지키기 위해 기기가 깨어날 때 작업을 묶어 처리하고 불필요한 백그라운드 활동을 줄입니다 백그라운드 런타임은 제한적이므로 앱이 백그라운드에서 할 일은 작고 명확한 개별 작업으로 구성해야 합니다 각 작업은 시스템의 우선순위와 제약을 고려해 효율적으로 하나의 일을 처리해야 합니다 백그라운드 작업은 배터리 설정에 표시되어 사용자는 어떤 앱이 배터리에 영향을 주는지 알 수 있습니다 iOS 26에서는 앱별 배터리 사용량 디바이스 배터리 성능에 대한 놀라운 통찰을 제공하죠
이제 가장 중요한 것은 효율성입니다 작업이 즉시 실행될 필요가 없다면 기기가 충전 중일 때 지연 실행하는 것도 고려해야 합니다 즉시 실행이 필요해도 가볍고 목적 중심적으로 구성하세요
시스템은 배터리 외에도 다른 공유 리소스도 관리합니다 메모리, CPU 시간 네트워크 대역폭 등이죠 사용자가 기기를 사용할 때는 포그라운드 앱이 우선입니다 백그라운드 앱이 과도한 메모리나 CPU를 사용하면 비효율적일 뿐 아니라 포그라운드 경험과도 충돌하게 됩니다 이 경우 시스템은 스로틀링, 일시 중단 심하면 프로세스 종료까지 진행할 수 있습니다
핵심은 간단합니다 백그라운드 작업을 최소화하세요 작업을 나눠서 일괄 처리하고 메모리 사용량을 줄여야 하죠
작업이 잘 설계됐더라도 항상 실행되는 것은 아닙니다 백그라운드 작업 대기열은 비어 있는 적이 없기 때문에 시스템은 다른 작업에 우선순위를 둘 수도 있습니다 하지만 우리는 시스템과 협력하는 팀입니다 시스템은 포그라운드 경험을 극대화하기 위해 제 역할을 수행합니다
작업 부하는 탄력적이어야 합니다 중간 결과를 자주 저장하고 만료 신호에 빠르게 반응하며 시스템이 작업을 재개할 것을 믿어야 하죠 시스템은 이러한 행동으로 협조적 프로세스를 우선 고려해 향후 스케줄에 영향을 줍니다 하지만 최종 결정권은 기기 사용자에게 있습니다 저전력 모드 및 백그라운드 앱 새로 고침 저데이터 모드 같은 설정을 통해 스케줄에 영향을 줍니다 시스템은 투명성을 제공해 사용자가 직접 결정을 내릴 수 있도록 합니다 예를 들어, 앱이 백그라운드에서 과도한 배터리를 소모한다면 사용자가 제한 조치를 취할 수 있습니다
그렇기에 백그라운드 작업은 가볍고 신중해야 하며 사용자의 설정과 선호를 존중해야 합니다 그 영향은 앱이 제공하는 가치에 비례해야 합니다 모든 프로세스가 이 원칙을 지키더라도 실행 환경은 여전히 복잡하고 유동적입니다
네트워크 상태 CPU 부하, 기기 활동 열 상태, 배터리 잔량 등이 맥락으로 작용해 스케줄 결정에 반영됩니다
다행히 시스템은 이런 조건들을 모두 고려해 최적의 경험을 항상 유지하려고 합니다 즉, 아무리 잘 설계된 작업도 상황이 맞지 않으면 연기될 수 있습니다 전체적인 균형을 위한 결정이죠 따라서 적응력이 매우 중요합니다 작업은 작고 가볍게 유지하고 필요 사항은 명확히 전달해야 합니다 작업을 이어받아 계속 수행할 수 있도록 설계하면 런타임 기회가 생길 때마다 점진적 진행이 가능합니다 시스템 조건과 우선순위를 이해하고 적응할수록 작업 성공률은 더 높아집니다
효율성, 최소성, 탄력성 신중함, 적응성 이 5가지가 백그라운드 작업을 플랫폼에 자연스럽게 통합하는 핵심입니다 개발 중엔 다음과 같은 질문을 스스로 던져보는 것도 좋습니다
이 작업은 누가 시작했는가? 명시적으로 시작된 작업인가 아니면 나중에 실행해도 되는 선택적 작업인가?
작업 소요 시간은 얼마나 되는가? 작업을 단기, 중기, 장기로 분류해 보세요 이 작업은 앱 상태나 최신도에 중요한가? 백그라운드 다운로드는 앱을 생동감 있게 만들지만 원격 측정 업로드는 기기 사용자에게 즉각적 이점이 없습니다 마지막으로 이 작업은 사용자의 동의나 입력이 필요한가?
그렇다면 백그라운드 런타임은 적절하지 않으므로 다른 방식으로 접근하는 것이 좋습니다 이제 이런 기반 위에서 작업을 효과적으로 설계하는 방법을 보겠습니다 iOS에는 백그라운드 런타임을 요청하는 다양한 API가 있고 각 API는 지원하려는 작업 특성에 따라 다른 유형과 조건을 가정합니다 이를 통해 시스템은 앱의 런타임을 앞서 설명한 제약과 조건에 맞게 조정할 수 있습니다 예를 들어 사용자는 자주 사용하는 앱이 최신 콘텐츠를 유지하길 바랍니다 시스템이 앱 사용 패턴을 이해하고 백그라운드 작업을 최적화하는 것도 합리적입니다
첫 번째 API가 BGAppRefreshTask입니다
앱은 이 기능을 사용해 사용 직전 서버에서 조용히 콘텐츠를 불러올 수 있습니다 시스템은 이 작업을 앱 사용 이력에 따라 스케줄링합니다 자주 사용하는 앱일수록 작업이 예약될 확률이 높아집니다 그 결과 실행할 때마다 콘텐츠가 신선하죠
SwiftUI에서 앱 새로 고침 작업을 만들려면 장면에 BackgroundTask 수정자를 추가하면 됩니다 앱이 백그라운드에서 실행될 때 시스템은 해당 클로저를 호출하고 종료 시 앱을 일시 중단합니다
새로 고침 작업이 콘텐츠 가져오기용이라면 자주 변경되지 않는 원격 문서를 유지할 경우엔 백그라운드 푸시 알림이 좋은 해결책이 됩니다 서버에서 새 콘텐츠 알림을 보내면 시스템이 적절한 시점에 앱을 깨워 콘텐츠를 가져오게 합니다 이 방식은 앱 새로 고침과는 다릅니다 이 경우는 데이터를 직접 요청하는 게 아니라 기기로 업데이트가 푸시됩니다
백그라운드 푸시 알림은 새로운 원격 콘텐츠가 있다는 신호로 쓰이므로 항상 선택적으로 취급되며
낮은 우선순위로 전송되고 병합되어 과부하와 배터리 소모를 최소화합니다
또한 사용자가 앱을 앱 전환기에서 종료하면 시스템은 그 의도를 존중해 앱이 다시 실행되기 전까지는 알림을 전달하지 않습니다
하지만 어떤 경우엔 앱이 다른 유형의 작업을 수행하길 원할 수도 있습니다 생성된 데이터를 바탕으로 ML 모델을 실행하거나 단순히 데이터베이스 정리를 하고 싶을 수도 있습니다
BGProcessingTask API는 이를 가능하게 합니다
등록 방법도 간단합니다 작업 식별자, 콜백 대기열 런타임에 호출될 클로저만 지정하면 됩니다
앱 실행 직후 즉시 BackgroundTasks를 등록해야 하죠 앱이 백그라운드에서 실행될 경우 시스템이 해당 작업을 바로 인식하고 처리기를 즉시 호출할 수 있습니다 처리 작업은 앞서 설명한 원칙을 반영할 수 있도록 추가 설정도 지원합니다 예를 들어, 작업이 지연에 민감하지 않다면 충전 중이면서 네트워크에 연결됐을 때만 작업이 실행되도록 설정해 배터리 소모를 최소화하고 앱의 배터리 사용량도 줄어들게 됩니다 지금까지는 백그라운드에서 시작되는 작업에 런타임을 부여하는 API를 살펴봤습니다 하지만 때로는 백그라운드로 전환되는 동안 조금 더 작업 시간을 확보하고 싶을 수 있습니다 백그라운드 작업 시작 및 종료 API는 중단되면 복구가 어려운 작업을 마무리할 수 있게 도와줍니다
예를 들어 단순한 상태 저장도 작업에 따라, 중단 시 앱 경험을 해칠 수 있습니다
이런 API로 코드를 감싸면 시스템에 중요한 작업이 진행 중임을 알릴 수 있고 중단을 피할 수 있습니다 파일 핸들을 정리하거나 데이터베이스 연결을 닫을 때 특히 유용합니다
iOS의 백그라운드 기능은 매우 폭넓으며 사용자가 시작한 작업도 포함해 다양한 작업을 처리할 수 있도록 설계됐습니다 사용자 주도 작업의 완료를 보장하는 것은 좋은 앱 경험의 핵심입니다 iPadOS, iOS 26는 BGContinuedProcessingTask가 바로 이러한 기능을 지원할 수 있게 해줍니다 이를 통해 앱은 백그라운드 전환 이후에도 작업을 계속 수행하고 시스템은 UI를 통해 진행 상황을 표시합니다 예를 들어, Journal 앱은 ContinueProcessingTask로 백그라운드에서 내보내기를 수행하고 진행 상황을 사용자에게 보여줍니다 작업이 완료되면 시스템은 잠시 업데이트한 후 UI를 자동으로 닫아줍니다 사용자가 여전히 주도권을 가집니다 진행 상황을 확인하고 언제든 작업을 취소할 수 있어 복잡한 기능도 제어 가능합니다
ContinueProcessingTask는 항상 명확한 사용자 행동으로 시작됩니다 버튼 클릭이나 다른 제스처처럼요 각 작업은 즉각적이고 명확한 목표를 가지고 있습니다 파일 내보내기 SNS 콘텐츠 게시 연결된 액세서리 업데이트 등처럼 말이죠 이러한 작업은 측정 가능한 진행률을 가지고 있으며 작업이 완료됐을 때 무엇을 의미하는지 알 수 있습니다
사용자는 작업이 자동으로 시작되리라 기대하지 않습니다 앱 설정에서 선호도를 지정했더라도 마찬가지입니다 유지관리, 백업 사진 동기화처럼 자동으로 실행되는 작업은 피해야 합니다 작업이 명확한 동작 없이 자동으로 시작되면 사용자는 그 목적이나 진행 상태를 이해하지 못할 수 있습니다 예상치 못한 작업은 작업 취소로 이어질 수 있습니다 이런 경우에는 보다 적절한 API를 고려해야 하죠
이 점들을 고려하면 지속적 처리 작업 도입이 도움이 될 수 있습니다 먼저 Info.plist에 작업 식별자를 추가합니다 이 식별자는 상태와 진행 상황을 관리하는 실행 처리기를 등록할 때 사용됩니다 그다음 요청이 필요할 때 작업 요청을 제출하면 됩니다 식별자는 이렇게 정의합니다 Info.plist의 Permitted background task scheduler identifiers 배열에 새 값을 추가하고 앱 번들 ID로 시작되도록 합니다
정적인 식별자 외에도 지속적 처리 작업은 동적 접미사를 지원하는 새 와일드카드 형식을 지원합니다
와일드카드 식별자는 항상 번들 ID로 시작하고 그 뒤에 의미 있는 맥락이 이어집니다 여기서 새로 추가된 구성 요소는 점 별표입니다 이는 등록 및 요청 시 동적 접미사가 추가된다는 의미입니다
등록 및 제출 시 사용할 완전한 식별자 형태는 다음과 같습니다
우선은 더 정적인 부분에 집중하겠습니다
이제 선택이 완료되었으니 스케줄러가 알아야 할 것은 지속적 처리 작업이 실행될 때 어떤 코드를 실행할지입니다 이전처럼 클로저를 스케줄러에 제공하면 작업 요청이 제출된 뒤 해당 클로저가 호출됩니다 하지만 여기서 중요한 변화가 있습니다 실행 처리기는 앱 실행이 끝나기 전 등록할 필요가 없습니다 대신 해당 작업을 사용하려는 시점에 동적으로 등록할 수 있습니다
Journal 앱처럼 진행 상황을 제때 보고하는 것도 중요합니다 진행 속도가 예상보다 느릴 경우 시스템은 사용자에게 작업을 계속할지 묻게 됩니다 시스템은 이런 진행 상황 보고에 의존해 작업을 관리합니다 결과적으로 진행 상황을 보고하지 않는 작업은 만료되어 시스템이 리소스를 회수하고 다른 작업에 재분배할 수 있습니다 앱은 Progress Reporting Protocol을 사용해 이런 업데이트를 직접 전달하며 시스템은 이를 실시간으로 감지하고 UI에 반영합니다 상황에 따라 작업을 시스템이 작업을 일찍 중단해야 할 수도 있다는 사실을 인지해야 합니다 이를 처리하기 위한 만료 처리기도 제공해야 합니다 이 처리기는 중단 신호를 받았을 때 변수를 전환해 작업을 우아하게 종료하고 불필요한 작업을 피할 수 있게 합니다
무엇보다 중요한 건 작업이 끝났을 때 setTaskCompleted를 반드시 호출해야 합니다 이는 시스템에 작업이 완료되었음을 알려줍니다 지금까지는 진행 상황 보고 중단 처리, 작업 완료 알림에 대해 살펴봤습니다 이제 이 모든 요소를 종합해 사용자가 시작한 작업을 정상적으로 빌드하고 제출하는 방법을 보겠습니다
먼저 작업 요청 객체를 초기화합니다 필요한 정보는 3가지입니다 Info.plist에 등록된 식별자 그리고 현지화된 제목과 부제입니다 이는 사용자가 시스템 UI에서 보는 내용입니다
그다음 시스템이 준수할 제출 전략을 지정합니다 기본적으로 지속적 처리 작업을 즉시 실행할 수 없을 경우 시스템이 대기열에 작업을 추가합니다 여기서는 추가로 아무것도 지정할 필요가 없습니다 하지만 어떤 경우엔 대기열 추가 방식이 적절하지 않습니다 해당 작업이 당장 시작되어야만 유용하다면 어떻게 할까요? 작업을 대기열에 넣는 대신 즉시 실행할 수 없으면 제출을 실패하게 할 수 있습니다 이를 통해 앱은 즉각적인 피드백을 받고 상황을 적절히 처리할 수 있습니다
전략을 정하고 요청 구성을 마치면 스케줄러에 요청을 제출하고 시스템이 작업을 관리하게 하죠 이것이 지속적 처리 작업의 핵심 흐름입니다 제목과 부제를 제공하고 제출 전략을 고려함으로써 시스템과 자연스럽게 통합되며 사용자 동의라는 중요한 원칙도 지킬 수 있습니다 이 API는 표면적으로 보이는 것보다 많은 기능을 제공합니다 iPadOS 및 iOS 26에서 지속적 처리 작업은 지원 기기에서 백그라운드 GPU 접근도 활용할 수 있습니다
이를 사용하려면 Xcode 프로젝트 설정에서 백그라운드 GPU 기능을 추가해야 합니다
추가한 후에는 스케줄러의 지원 리소스 속성을 동적으로 쿼리하는 것이 좋습니다 이를 통해 앱은 런타임에서 현재 기기가 무엇을 지원하는지 정확히 파악하고 작업 요구 사항을 적절히 조정할 수 있습니다 이 확인은 매우 중요합니다 시스템은 이러한 요구 사항을 적용합니다 사용할 수 없는 리소스를 요청하면 제출 시 거부되며 시스템과 작업 모두 안정적인 상태로 유지됩니다
마지막으로 시스템 우선순위의 전체 맥락을 기억해야 합니다 iOS는 포그라운드 경험을 최우선으로 합니다, 백그라운드 작업은 활성 상태보다 낮은 품질로 처리될 수 있습니다 하지만 시스템은 이를 똑똑하게 관리합니다 앱이 포그라운드로 돌아오면 작업 우선순위를 지능적으로 높여 부드럽고 반응성 있는 경험을 유지할 수 있도록 돕습니다 새로운 API는 가장 강력하고 자연스러운 백그라운드 실행 기능을 제공하며 BGContinueProcessingTask를 툴킷에 더해줍니다 이 작업의 구조와 시스템 내 역할을 완전히 이해했다면 도입을 시작할 준비가 된 것입니다 여러분이 이 도구들을 활용해 더 스마트하고 효율적인 백그라운드 경험을 어떻게 만들어갈지 기대하고 있습니다 시청해 주셔서 감사합니다!

import BackgroundTasks
import SwiftUI

@main
struct ColorFeed: App {
    var body: some Scene {
        WindowGroup {
            // ...
        }
        .backgroundTask(.appRefresh("com.colorfeed.wwdc25.appRefresh")) {
            await self.handleAppRefreshTask()
        }
    }
}

9:45 - Register a processing task

import BackgroundTasks
import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        BGTaskScheduler.shared.register(
            forTaskWithIdentifier: "com.example.apple-samplecode.ColorFeed.db_cleaning",
            using: nil
        ) { task in
            self.handleAppRefresh(task: task as! BGProcessingTask)
        }
    }

    func submitProcessingTaskRequest() {
        let request = BGProcessingTaskRequest(
            identifier: "com.example.apple-samplecode.ColorFeed.db_cleaning"
        )
        request.requiresNetworkConnectivity = true
        request.requiresExternalPower = true

        BGTaskScheduler.shared.submit(request)! 
    }
}

10:51 - Begin and end background task

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    var backgroundTaskID: UIBackgroundTaskIdentifier = .invalid
   
    func saveState() { /*  ... */ }

    func handlePersistence() {
        let app = UIApplication.shared
        guard backgroundTaskID != .invalid else { return }
        backgroundTaskID = app.beginBackgroundTask(withName: "Finish Export") {
            app.endBackgroundTask(self.backgroundTaskID)
            self.backgroundTaskID = .invalid
        }

        self.saveState()

        app.endBackgroundTask(backgroundTaskID)
        backgroundTaskID = .invalid
    }
}

14:00 - Continued processing task registration

import BackgroundTasks

func handleDialogConfirmation() {
    BGTaskScheduler.shared.register("com.colorfeed.wwdc25.userTask") { task in
        let task = task as! BGContinuedProcessingTask
                                                                      
        var shouldContinue = true
        task.expirationHandler = {
            shouldContinue = false
        }

        task.progress.totalUnitCount = 100
        task.progress.completedUnitCount = 0

        while shouldContinue {
            // Do some work
            task.progress.completedUnitCount += 1
        }

        task.setTaskCompleted(success: true)
    }
}

15:47 - Continued processing task submission

import BackgroundTasks

func submitContinuedProcessingTaskRequest() {
    let request = BGContinuedProcessingTaskRequest(
        identifier: "com.colorfeed.wwdc25.userTask",
        title: "A succinct title",
        subtitle: "A useful and informative subtitle"
    )

    request.strategy = .fail

    BGTaskScheduler.shared.submit(request)!
}

- 0:00 - 인사말
- 앱이 백그라운드 런타임을 사용하여 앱에서 프리페칭 및 동기화와 같은 작업을 수행하는 방법을 알아보세요.
- 1:22 - 서론
- 앱은 메모리에 로드되고, 포그라운드로 전환되며, 주요 초점이 됩니다. 누군가 앱에서 벗어나면 앱은 백그라운드로 이동하고 시스템은 배터리와 리소스를 절약하기 위해 앱을 일시 중지합니다. 앱은 작업을 완료할 수 있도록 잠시 시간을 요청할 수 있습니다. 돌아오면 다시 포그라운드에서 시작합니다.
- 2:09 - 행동 및 제약
- iOS 및 iPadOS에서는 배터리 수명을 우선시하고 성능을 최적화하기 위해 백그라운드 런타임이 엄격하게 관리됩니다. 백그라운드 실행은 기회가 있을 때만 허용되고 재량에 따라 결정되며 에너지가 가장 근본적인 제약 조건입니다. 앱의 백그라운드 작업은 효율적이고, 가벼우며, 목적에 맞게 설계해야 합니다. 시스템은 작업을 통합하고 리소스를 지나치게 많이 소모하는 프로세스를 제한, 일시 중단 또는 종료할 수 있습니다. 백그라운드 작업은 최소한으로 유지하고, 필수적이지 않은 작업은 충전될 때까지 연기하며, 작업이 작고 회복탄력적인지 확인합니다. 앱은 신중해야 하며 사용자의 선호도와 시스템 상황을 존중해야 합니다. 이 시스템은 사람들에게 투명성을 제공하여 일정을 결정하는 데 영향을 미칩니다. 백그라운드 작업 부하의 성공은 작업 부하의 적응성과 시스템 우선순위와의 일치성에 달려 있습니다.
- 7:29 - 백그라운드 작업 API
- iOS 및 iPadOS는 백그라운드에서 실행되는 작업을 설계할 수 있도록 다양한 API를 제공합니다. 시스템은 앱 사용량 패턴 및 기기 제약 조건에 따라 이러한 작업을 최적화합니다. ‘BGAppRefreshTask’를 사용하면 앱이 사용하기 전에 콘텐츠를 자동으로 가져올 수 있으며 자주 사용되는 앱의 일정은 빈번하게 예약됩니다. ‘백그라운드 푸시 알림’은 서버에서 알림을 보낼 때 앱을 깨워 새 콘텐츠를 가져오지만, 오버헤드를 최소화하기 위해 선택적이며 우선순위가 낮은 것으로 간주됩니다. ‘BGProcessingTask‘를 사용하면 앱이 ML 모델 실행이나 데이터베이스 유지 관리와 같은 더 복잡한 작업을 수행할 수 있습니다. 이 작업은 실행되는 동안 등록되어야 하며 기기가 충전기에 연결되어 있고 네트워크에 연결된 경우에만 실행되도록 구성할 수 있습니다. beginBackgroundTask 및 endBackgroundTask API는 앱이 백그라운드로 전환할 때 상태 저장 또는 연결 종료와 같은 중요한 작업을 완료할 수 있도록 추가 시간을 제공합니다.
- 11:23 - 지속적 처리 작업
- iPadOS 및 iOS 26에는 새로운 ‘BGContinuedProcessingTask’ API가 있는데, 이를 사용하면 앱에서 백그라운드에 있는 사람이 시작한 작업을 완료할 수 있습니다. 이 기능을 사용하면 앱을 열지 않고도 복잡한 작업을 완료할 수 있어 사용자 경험이 향상됩니다. 예를 들어, Journal 앱은 이 API를 사용하여 백그라운드에서 파일을 내보냅니다. 누군가 버튼을 탭하여 내보내기를 시작하면 앱은 시스템 UI를 통해 진행 상황 업데이트를 제공합니다. 작업 진행 상황을 모니터링하고 언제든지 작업을 취소할 수 있어 완전한 통제력을 유지할 수 있습니다. 이러한 작업은 항상 버튼 탭 또는 제스처와 같은 명시적인 동작으로 시작해야 합니다. 이러한 기능은 파일 내보내기, 소셜 미디어 콘텐츠 게시 또는 연결된 액세서리 업데이트 완료 등 명확하고 즉각적인 목표를 나타냅니다. 시스템은 이러한 작업이 측정 가능한 진전을 이룰 것으로 기대합니다. 상태 및 진행 상황 보고를 관리하려면 실행 처리기를 등록해야 합니다. 진행 보고 프로토콜을 사용하여 작업 부하 진행 상황에 대한 업데이트를 적시에 제공합니다. 예상보다 작업 진행 속도가 느리면 시스템은 계속 진행할지 결정하라는 메시지를 표시합니다. 작업이 완료되면 ‘setTaskCompleted’ 메서드를 사용하여 시스템에 알려야 합니다. 또한, 앱은 만료 처리기를 제공하여 잠재적인 중단을 원활하게 처리해야 합니다. 뿐만 아니라 API는 지원되는 기기에서 백그라운드 GPU 액세스를 지원하기 때문에 더욱 강력하고 효율적인 백그라운드 환경을 만들 수 있습니다. 하지만 iOS는 포그라운드 환경을 우선시하기 때문에 백그라운드 작업의 서비스 품질이 낮아질 수 있습니다. 그럼에도 불구하고, 앱이 포그라운드로 돌아오면 시스템은 지능적으로 작업 우선순위를 높입니다.

챕터

리소스