Notice
Recent Posts
Recent Comments
Link
NewGen
Background Task 2 본문
중단에서 응용 프로그램을 방지 할 수 있습니다. 관련된 API는 매우 작지만 여전히주의해야 할 사항이 많이 있습니다.
- 이름 백그라운드 작업 은 다소 부적절합니다. 특히, beginBackgroundTask(expirationHandler:)실제로 백그라운드 작업의 모든 종류의를 시작하지 않고, 그 시스템 알려주 는 앱이 백그라운드에있는 경우에도 계속하려면 몇 가지 진행중인 작업을 시작합니다. 해당 작업을 만들고 관리하려면 코드를 작성해야합니다. 따라서 백그라운드 작업 API를 "Do n't suspend me"주장을 제기하는 것으로 생각하는 것이 가장 좋습니다.
- 시작하는 모든 백그라운드 작업을 종료해야합니다. 그렇게하지 않으면 워치 독에 의해 앱이 종료됩니다. 이러한 이유로 시작하는 각 백그라운드 작업에 이름을 첨부하는 것이 좋습니다 ( beginBackgroundTask(withName:expirationHandler:)대신 호출 beginBackgroundTask(expirationHandler:)). 일이 잘못되었을 때 문제를 추적하려면 좋은 이름이 중요합니다.
경고 백그라운드 작업 종료 실패는 iOS에서 백그라운드 작업 문제의 # 1 원인입니다. 여기에는 일반적으로 앱이 백그라운드 작업을 시작하고 종료하지 않는 부기의 간과하기 쉬운 오류가 포함됩니다. 예를 들어 현재 백그라운드 작업 식별자 (유형 UIBackgroundTaskIdentifier) 를 저장하는 속성이있을 수 있습니다 . 실수로 두 번째 백그라운드 작업을 만들고 호출하지 않고 해당 속성에 저장 한 경우endBackgroundTask 현재 거기에 저장된 식별자에서 앱은 백그라운드 작업을 '누수'하여 감시자에 의해 죽게됩니다. - 백그라운드 작업은 다음 두 가지 방법 중 하나로 끝날 수 있습니다
. 앱이 설정 한 작업을 완료했을 때.
비. 시스템이 작업의 만료 처리기를 호출 할 때. 두 경우 모두
코드가 호출 endBackgroundTask(_:)을 담당합니다 . - 모든 백그라운드 작업에는 시스템이 작업을 '호출'하는 데 사용할 수있는 만료 처리기가 있어야합니다. 백그라운드 작업 API를 사용하면 시스템에서 언제든지이를 수행 할 수 있습니다.
- 만료 처리기는 정리할 수있는 기회입니다. 모든 것이 실제로 정리 될 때까지 반환되지 않아야합니다. 즉, 1 초 이내에 빠르게 실행되어야합니다. 시간이 너무 오래 걸리면 워치 독에 의해 앱이 종료됩니다.
- 만료 처리기가 기본 스레드에서 호출됩니다.
- 모든 스레드에서 백그라운드 작업을 시작하고 종료하는 것은 합법적이지만 보조 스레드에서이 작업을 수행하는 것은 항상 주 스레드에서 호출되는 만료 처리기로 작업을 조정해야하기 때문에 까다로울 수 있습니다.
- 시스템은 백그라운드 작업을 사용하여 일시 중단을 방지 할 수있는 총 시간에 엄격한 제한을 둡니다. iOS 13 베타는 포 그라운드 값을 30 초로 줄였습니다. 현재 시스템에서는 다음과 같은 값을 기대할 수 있습니다
. 앱이 포 그라운드에서 백그라운드로 이동 한 경우 3 분
b. 30 초, 앱이 백그라운드에서 재개되었을 때
경고 : 예상되는 사항에 대한 대략적인 아이디어를 제공하기 위해이 수치를 인용했습니다. 목표 값은 과거에 변경되었으며 미래에도 변경 될 수 있으며 실제로 얻는 시간은 시스템 상태에 따라 다릅니다. 여기서 기억해야 할 것은 백그라운드 작업에 기능적 만료 처리기가있는 한 정확한 값은 중요하지 않다는 것입니다. - UIApplication의 backgroundTimeRemaining재산 을 살펴보면 이용 가능한 대략적인 시간을 알 수 있습니다.
중요 :에서 반환 된 값 backgroundTimeRemaining은 추정치이며 언제든지 변경 될 수 있습니다. 반환 된 값에 관계없이 올바르게 작동하도록 앱을 디자인해야합니다. 디버깅에이 속성을 사용하는 것이 합리적이지만 앱 논리의 일부로 사용하지 않는 것이 좋습니다.
경고 :에서 반환 된 값에 기반한 앱 동작 backgroundTimeRemaining은 iOS에서 백그라운드 작업 문제의 # 2 원인입니다. - 이 시스템은 보장하지 않습니다 모든 백그라운드 작업의 실행 시간을. 백그라운드 작업을 생성하지 못할 가능성이 있습니다 (다음 요점에서 다룰 가능성은 낮지 만). 그리고 생성을 관리하더라도 만료 처리기를 언제든지 호출 할 수 있습니다.
- beginBackgroundTask(expirationHandler:)UIBackgroundTaskInvalid시스템이 백그라운드 작업을 생성 할 수 없음을 나타 내기 위해 실패 할 수 있습니다 . 이것은 일부 장치가 멀티 태스킹을 지원하지 않는 백그라운드 작업이 처음 도입되었을 때 실제 가능성 이었지만 최신 시스템에서는이를 볼 가능성이 거의 없습니다.
- 백그라운드 시간 '시계'는 백그라운드 작업이 적용될 때만 시작됩니다. 예를 들어 앱이 포 그라운드에있는 동안 백그라운드 작업을 시작한 다음 포 그라운드에있는 경우 앱이 백그라운드로 이동할 때까지 백그라운드 작업이 휴면 상태로 유지됩니다. 이를 통해 백그라운드 작업 추적 논리를 단순화 할 수 있습니다.
- 백그라운드 실행 시간은 백그라운드 작업 자체의 속성이 아니라 앱의 속성입니다. 예를 들어 두 개의 백그라운드 작업을 연속으로 시작하면 6 분의 백그라운드 실행 시간이 제공되지 않습니다.
- 이전 요점에도 불구하고 추적 논리를 지원하기 위해 여러 백그라운드 작업을 만드는 것이 합리적 일 수 있습니다. 예를 들어 앱에서 수행중인 각 작업에 대해 백그라운드 작업을 만들고 작업이 완료되면 작업을 종료하는 것이 일반적입니다.
- 백그라운드 작업을 너무 많이 생성하지 마십시오. 너무 많아요? 수십 개의 백그라운드 작업을 만드는 것은 절대적으로 좋지만 수천 개의 작업을 만드는 것은 좋은 생각이 아닙니다.
중요 : iOS 11은 프로세스가 가질 수있는 백그라운드 작업 어설 션 수에 대한 엄격한 제한을 도입했습니다 (현재 약 1000 개이지만 특정 값은 향후 변경 될 수 있음). 예외 코드 0xbada5e47이 포함 된 충돌 보고서가 표시되면 해당 제한에 도달 한 것입니다.
참고 : 여기서 가장 많이 볼 수있는 실제 제한은 만료 처리기를 호출하는 데 걸리는 시간입니다. 워치 독에는 백그라운드 작업 만료 처리기를 실행하는 데 걸리는 총 시간에 대해 엄격한 제한 (몇 초)이 있습니다. 수천 개의 핸들러가있는 경우이 한계에 도달 할 수 있습니다. - 액세스 할 수없는 컨텍스트 UIApplication(앱 확장 또는 watchOS)에서 작업하는 경우 performExpiringActivity(withReason:using:).
- 앱이 백그라운드 작업을 '누수'하면 워치 독에 의해 종료 될 수 있습니다. 이로 인해 예외 코드 0x8badf00d ( "먹은 음식")가 포함 된 충돌 보고서가 생성됩니다.
중요 : 유출 된 백그라운드 작업이 0x8badf00d 충돌의 유일한 이유 는 아닙니다 . 예를 들어 동기 네트워킹 요청에서 메인 스레드가 코드에 멈춰 있는지 확인하려면 메인 스레드의 역 추적을 확인해야합니다. 그러나 주 스레드가 실행 루프에서 행복하게 차단되면 유출 된 백그라운드 작업이 주요 용의자가되어야합니다. - iOS 11 이전에는 해결되지 않은 백그라운드 작업에 대한 정보가 결과 충돌 보고서에 표시되었습니다 (텍스트 찾기 BKProcessAssertion). 이 정보는 iOS 11 이상에 포함되지 않지만 시스템 로그에서 동등한 정보를 찾을 수 있습니다.
- macOS에서 콘솔 앱을 사용하여 장치의 시스템 로그를 대화식으로 모니터링 할 수 있습니다. 시스템 로그는 sysdiagnose 로그에도 포함되어 있으므로 필드에만 나타나는 문제가있는 경우 사용자에게 보내달라고 요청할 수 있습니다. sysdiagnose 로그에 대한 자세한 내용은 버그보고 > 프로필 및 로그 페이지를 참조하세요.
- 시스템 로그는 매우 시끄럽기 때문에 각 백그라운드 작업에 찾기 쉬운 이름을 지정하는 것이 중요합니다.
- 백그라운드에서 시작된 작업은 시간 제한이 훨씬 짧습니다. 정확한 제한은 문서화되어 있지 않지만 (과거에 변경되었으며 나중에 다시 변경 될 수 있음) 현재 값은 위에서 언급 한대로 약 30 초입니다. 그래서 다음과 같은 일이 발생합니다.
- 사용자가 지역에 들어가기 때문에 시스템은 백그라운드에서 앱을 다시 시작 (또는 다시 시작)합니다.
- 3 분 동안 타이머를 예약하고 앱이 일시 중단되지 않도록 백그라운드 작업을 시작합니다.
- 30 초 후에 백그라운드 작업이 만료됩니다. 이 시점에서 다음 두 가지 중 하나가 발생
합니다. 만료 처리기가 있으면 호출됩니다. 앱이 일시 중지되는 시점 (A)에서 백그라운드 작업을 종료해야합니다.
비. 만료 처리기가 없거나 백그라운드 작업을 즉시 종료하지 못하면 워치 독이 앱을 종료합니다 (B). - 이는 타이머가 3 분 후에 실행되지 않음을 의미합니다. 앱이 일시 중지되거나 (이로 인해 타이머가 실행되지 않음) 앱이 종료됩니다.
- 이 상태는 사용자가 지역을 떠날 때까지 계속됩니다. 이 시점에서 다음 두 가지 중 하나가 발생
합니다. A의 경우 시스템이 백그라운드에서 앱을 다시 시작합니다. 타이머가 오래 지연되었으므로 지금 실행됩니다.
비. B의 경우 시스템은 백그라운드에서 앱을 다시 시작합니다. 이것은 새로운 프로세스이므로 타이머가 더 이상 존재하지 않습니다.
중요 : 이를 테스트하려면 Xcode가 아닌 홈 화면에서 앱을 실행해야합니다. Xcode 디버거는 워치 독을 비활성화하고 앱이 일시 중단되는 것을 방지합니다.
참조
medium.com/swlh/handling-background-tasks-in-ios-13-67f717d94b3d
'IOS' 카테고리의 다른 글
wkWebview 에서 javascript bridge 처리 후, 페이지 느려지는 원인중 하나 (0) | 2020.12.11 |
---|---|
Create Custom UIView and Use in ViewController / 사용자 커스텀 뷰 (닙생성) 만들고 뷰컨트롤러에서 불러쓰기 (0) | 2020.11.24 |
swift background 처리 (0) | 2020.10.22 |
ios swift project , Azure notification hub 구현 (0) | 2020.10.21 |
Download mp3 from youtube on your MAC. (0) | 2020.05.31 |
Comments