24fa4ab988099c656ee4d25480746f46
WWDC20 10078 - 为什么我的 app 被终止了?

概述

本次 session 主要内容如下:

  1. 介绍了后台应用终止的常见原因,并提供了一些优化建议
  2. 介绍了 MetricsKit 提供的在代码中获取诊断和性能数据的方法
  3. 介绍了 Xcode Metrics Organizer 提供的关于线上用户性能数据的可视化报告

后台崩溃原因

  1. Crash
  2. CPU resource limit:CPU 占用率过高
  3. Watchdog:主线程长时间未响应
  4. Memory limit exceeded:内存使用超出上限
  5. Memory pressure exit:Jetsam
  6. Background task timeout:后台任务超时

一、Crash

Crash 常见原因包括:

  1. segmentation faults:存储区块错误, 当程序企图访问 CPU 无法定址的存储器区块时出现。当错误发生时,硬件会通知操作系统产生了存储器访问权限冲突的状况。维基解释
  2. illegal instruction:进程中某句指令无法被 CPU 识别
  3. asserts:程序运行时触发的断言

想要学习更多关于 Crash 知识,可以参看 WWDC18 Understanding Crashes and Crash Logs

二、CPU resource limit

当应用在处于后台的状态下执行任务,如果 CPU 占用率过高,系统会生成电量异常报告(可在 Xcode - Organizer 中查看),时间持续过长,系统甚至会将后台应用终止。

不过,如果后台应用确实需要执行这些繁重任务,可以考虑使用 iOS 13 推出的 BGProcessingTask

援引 WWDC 2019 全新后台任务框架及最佳实践关于 BGProcessingTask 的描述:

  • 这种后台模式会给应用几分钟的时间来处理相关任务,相比之前的几十秒有了比较大的提升。因此我们可以将一些可延迟到后台执行的任务放到这种模式下执行,也可以将一些 Core ML 的训练放到这种模式下执行。
  • 最重要的一点是,新框架允许我们关掉 CPU 的检测,因为之前系统出于对电池寿命的考虑,会将后台 CPU 占用较高的应用“杀死”,所以新框架的这个特性对于那些 CPU 占用较高的后台任务可以说是及时雨了,而要做到这个,仅仅只需要设置 bgProcessingTaskRequest.requiresExternalPower = true,系统就会在充电情况下,触发对应任务。
  • 同时我们只要需应用在前台时提交了对应请求,系统就会在适当的时机触发相应的任务。

三、Watchdog

Session 中特别提到在下面的场景,卡顿时间超过 20s 的情况下会发生 Watchdog

  1. 应用启动
  2. 应用进入后台,然后重新进入前台

其常见原因包括:

  1. Dead lock:死锁
  2. 代码中存在无限循环
  3. 主线程存在一直无法完成的任务

注意:处于调试下是不会出现 Watchdog 的。

四、Memory limit exceeded

内存占用过大,同样会造成后台应用终止。

使用 Instruments 的 Allocations、Leaks 和 Memory Graph Debugger 查看内存应用情况。

注意:不同设备的内存的使用上限也是不同,比如你的测试设备是 iPhone 6s 之前的机型,最好把内存占用控制在 200 MB 以内。

五、 Memory pressure exit:Jetsam

后台应用终止的原因,最常见的是 Jetsam

这里简单介绍一下 Jetsam。在 Linux 系统中,交换空间(swap space)可以用来存放内存中不常用的临时数据。而 iOS 系统因为闪存容量和读写寿命的原因,并没有引入交换空间,取而代之的是 Compressed memory 技术,即当内存紧张时,压缩一些内存内容,并在需要时解压。但副作用是会造成较高的 CPU 占用甚至卡顿,手机耗电量也会随之增加。

为了解决上面的问题,苹果设计了 Jetsam 机制。 其工作方式是当内存不足时,系统会通知前台应用去释放内存(通过 applicationDidReceiveMemoryWarning 方法和 UIApplicationDidReceiveMemoryWarningNotification 通知),如果内存压力依然存在,将会终止一些后台应用。最终内存还不够的话,就会终止当前应用(FOOM),并且上报日志。

可以在手机的“设置->隐私->分析->分析数据”中,找到开头是 “JetsamEvent” 的日志。想要进一步了解 Jetsam,请参看五子棋的这篇 iOS 内存 abort (Jetsam) 原理探究

对此,苹果给出了两个优化建议:

一方面,为了尽量避免后台应用终止,请将应用内存控制在 50 MB 以内,常见手段包括清理缓存和其它资源。

另一方面,即使应用内存控制在 50 MB 以内, Jetsam 仍旧有可能发生,可以采取的补救措施是:

  1. 在应用进入后台时,将必要的数据持久化到磁盘中
  2. 当后台应用终止后,应用重新启动的时候,我们可以使用之前保存在磁盘中的数据,搭配 UIKit 提供的 restoration API,恢复应用在上一次进入后台时的状态,用户可能都不会感知到应用已经重启,这样可以极大提升用户体验。

这块功能可以参考苹果官方的文档 Preserving Your App's UI Across LaunchesRestoring Your App’s State

此外,苹果还提醒说,即使应用处于前台状态,也请尽量控制内存占用情况,这样子就可以避免后台应用终止。说到底,iOS 系统良好的用户体验,需要所有应用共同去维护。

六、Background task timeout:后台任务超时

除了 Jetsam 之外,第二常见的后台终止原因是后台任务执行超时。

在进入后台时,应用如果马上需要执行一些任务,需要使用 beginBackgroundTask API。其处理的时长上限是 30 s。如果在 30 s 后没有调用 endBackgroundTask,系统会判定执行超时并将应用终止。

iOS 13.4 之后,Xcode 控制台会输出这个信息

我们还可以使用 iOS 13 推出的 mxSignpost API 进行自定义打点,收集指标数据进行检查,代码如下:

let handle = MXMetricManager.makeLogHandle(category: "DatabaseExpirationHandler")
// enter
mxSignpost(.event, log: handle, name: "Entered")
cancelOperations()
closeDatabase()
// exit
mxSignpost(.event, log: handle, name: "Exited")
UIApplication.shared.endBackgroundTask(backgroundTaskIdentifier)

可以得到如下结果:

上面的结果图显示,缺少一次 end 方法调用。
为了保证 begin 和 end 的成对出现,苹果推荐的使用方式如下:

class ArchiveViewController: UIViewController {
    @IBAction func beginDataExport(sender: UIButton) {
        var taskIdentifier: UIBackgroundTaskIdentifier = .invalid

        taskIdentifier = UIApplication.shared.beginBackgroundTask(expirationHandler: {
            ...
        })

        ArchiveUtility.exportUserData(completion: () -> ()) {
            UIApplication.shared.endBackgroundTask(taskIdentifier)
        }
    }
}

Swift 中闭包会捕获局部变量 taskIdentifier。利用这个机制,每次触发 beginDataExport ,taskIdentifier 都是不同的。这样就可以确保每个taskIdentifier 对应的 endBackgroundTask 方法的调用不会遗漏。

此外,还可以在上面代码中的 expirationHandler 中调用 endBackgroundTask 作为最后一层保险。但也需要记住,在这个闭包中千万不要再执行新的繁重任务。

MetricsKit

MetricKit 是在 iOS 13 中提出的一个全新诊断框架,可以用于收集和处理包括电池和性能指标。在 WWDC2019 Improving Battery Life and Performance 这个 session 中介绍了可以使用该框架在三个不同阶段进行数据的收集和分析。

  1. XCTest Metrics(开发和测试阶段):在 Unit Test 和 UI Test 中使用
  2. MetricsKit(Beta 和 Public Release 阶段):在代码中,引入框架使用
  3. Xcode Metrics Organizer (Public Release 阶段):Organizer 的 Metrics 中查看线上用户的数据

MetricKit 的出现,让开发者有能力在代码中直接获取到诊断信息,并直接上传到自家的服务器,进行收集和分析。在最新的 iOS 14 中,提供了更加全面的信息。MetricKitMXMetricPayloadMXDiagnosticPayload 两个类包含了大量诊断数据,下面截取了部分性能指标:

```swift
@available(iOS 13.0, *)
open class MXMetricPayload : NSObject, NSSecureCoding {

......

    // 内存情况
top Created with Sketch.