ios 应用从后台到前台重启_WWDC19：全新后台任务框架及最佳实践

WWDC 2019 Session 707: Advances in App Background Execution

作者 | Vong 

来源 | WWDC19 内参(https://xiaozhuanlan.com/wwdc19)

2010年 iOS4 时代，iOS 的多任务系统面世，至今已经9个年头，期间后台模式及场景也逐渐增多，这为开发者和用户带来了很多可能性。随着 iOS 版本的迭代，慢慢的越来越多的后台运行场景被苹果所支持。与此同时为了改善用户体验以及延长电池寿命，苹果对于应用后台任务有着比较严苛的限制及审核规则，只有特定使用场景，应用才可能在后台持续运行，比如导航、音乐播放，VoIP 等。如果我们的应用恰好符合后台模式的场景，那么应该怎样利用好这一点来给用户好的体验呢？相信通过这一集 Session，你心中应该会有一个比较明确的答案~

概览

目前苹果支持9种后台模式，具体类型可使用 Xcode 的 Capabilities 来查看，如下图所示

通过上图对比可以看到 Xcode11 将 Newsstand downloads 这种后台模式移除，并新增了一个 Background processing(后面会具体说)。这些后台模式都有 API 与之对应，苹果在设计后台任务相关 API 时，将以下3点作为主要考虑因素来确保流畅的用户体验。

电池

电量几乎时刻都在被消耗，那么如何保证后台任务尽可能的减小电量的消耗呢？答案就是在后台任务完成时及时调用对应的 completion 通知系统任务已结束，以此来减小电量的消耗。

性能

在日常使用情况下，手机上通常同时运行着多个应用，某个应用在前台时，其它的应用在后台。在资源有限的情况下，为了保证设备尽可能的流畅，系统会为每个应用智能分配 CPU 及内存的阈值，一旦应用超过对应阈值，将会被系统终止。

我们日常开发中发生的 OOM(Out Of Memory) 以及主线程长时间未响应而触发系统的“看门狗”，都是由于应用耗尽了系统分配的资源而被系统终止。

延展阅读
触发“看门狗”通常会生成一份 Crash 日志，日志内容类似下面这样，经典的 0x8badf00d
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, process-launch watchdog transgression: com.xxxx exhausted real (wall clock) time allowance of 20.00 seconds | | ProcessVisibility: Unknown | ProcessState: Running | WatchdogEvent: process-launch | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 2.910 (user 2.910, system 0.000), 7% CPU", | "Elapsed application CPU time (seconds): 0.000, 0% CPU" | )
Triggered by Thread: 0
如果对系统 Crash 日志感兴趣，可以看看我去年写的这篇文章 WWDC 2018：理解崩溃以及崩溃日志

大部分 OOM 的情况下一般会生成一份 JetsamEvent 开头的日志文件，可在设备的 设置->隐私->分析 中查看到，里面的内容会有崩溃现场的一些进程信息以及内存分配情况。更多关于 JetsamEvent 的介绍，可以查看这篇文章 iOS内存abort(Jetsam) 原理探究。

隐私

由于应用在执行后台任务时，用户是无感的，但是用户对于自己的隐私信息是敏感的，所以在相关 API 的设计时会告知用户，哪些数据会被使用。

从今年的 WWDC 的动作来看，苹果对用户的隐私越来越重视，这点非常值得称赞，比如今年推出的 Sign In With Apple、地理位置权限的变更、后台地理位置访问的弹窗等。当然，这不是开始也不是结束，为苹果爸爸点赞?。

最佳实践

了解了后台任务相关 API 的设计初衷，是时候来看看如何实践才能保证流畅的用户体验以及延长电池寿命。

想象一下一个类似微信的即时通讯软件拥有的一些功能：即时消息、勿扰模式、VoIP、历史记录下载等，对于这些功能，结合系统提供的各种后台任务应用场景，该以何种姿势使用这些 API 呢？且往下看~

即时消息

即时消息肯定需要确保时效性，尽可能快的触达对方才能保证良好的用户体验。但是某些情况下(比如较差网络环境)，不一定能马上将消息发送到对方，此时用户可能切回到桌面或者其它应用，那么如何才能保证发送消息这个操作完成呢？答案就是使用 Background Task Completion 相关 API。

// Guarding Important Tasks While App is Still in the Foreg