iOS 稳定性：App 被终止的原因

概述

本次 session 主要内容如下：

介绍了后台应用终止的常见原因，并提供了一些优化建议

介绍了 MetricsKit 提供的在代码中获取诊断和性能数据的方法

介绍了 Xcode Metrics Ogranizer 提供的关于线上用户性能数据的可视化报告

后台崩溃原因

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

Crash

Crash 常见原因包括：

segmentation faults

存储区块错误， 当程序企图访问 CPU 无法定址的存储器区块时出现。当错误发生时，硬件会通知操作系统产生了存储器访问权限冲突的状况。维基解释[1]

illegal instruction

进程中某句指令无法被 CPU 识别

asserts

程序运行时触发的断言

想要学习更多关于 Crash 知识，可以参看 WWDC18 Understanding Crashes and Crash Logs[2]。

CPU resource limit

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

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

援引 WWDC 2019 全新后台任务框架及最佳实践[3]关于 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) 原理探究[4]。

对此，苹果给出了两个优化建议：

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

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

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

这块功能可以参考苹果官方的文档 Preserving Your App's UI Across Launches[5] 和 Restoring Your App’s State[6]。

此外，苹果还提醒说，即使应用处于前台状态，也请尽量控制内存占用情况，这样子就可以避免后台应用终止。说到底，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[7] 这个 session 中介绍了可以使用该框架在三个不同阶段进行数据的收集和分析。

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

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

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

    ......

  // 内存情况
    open var memoryMetrics: MXMemoryMetric? { get }

  // 开发者自定义打点数据 对应前文提到的 mxSignpost
    open var signpostMetrics: [MXSignpostMetric]? { get }
}

@available(iOS 14.0, *)
open class MXDiagnosticPayload : NSObject, NSSecureCoding {

   ......

  /// CPU 异常
    open var cpuExceptionDiagnostics: [MXCPUExceptionDiagnostic]? { get }

  /// Watchdog
    open var hangDiagnostics: [MXHangDiagnostic]? { get }

  /// crash 诊断
    open var crashDiagnostics: [MXCrashDiagnostic]? { get }
}

这里看一下其中的 MXCrashDiagnostic 类，其提供了发生 crash 时的堆栈、crash 原因等信息，可以说信息非常齐全。

open class MXCrashDiagnostic : MXDiagnostic {
  /// 发生 crash 时的调用堆栈
    open var callStackTree: MXCallStackTree { get }

  /// crash 原因
    open var terminationReason: String? { get }

    open var virtualMemoryRegionInfo: String? { get }

    open var exceptionType: NSNumber? { get }

    open var exceptionCode: NSNumber? { get }

    open var signal: NSNumber? { get }
}

苹果甚至记录了后台应用，10 种不同异常退出情况出现的次数：

@available(iOS 13.0, *)
open class MXMetricPayload : NSObject, NSSecureCoding {
   // 内存退出情况
   @available(iOS 14.0, *)
   open var applicationExitMetrics: MXAppExitMetric? { get }
}

@available(iOS 14.0, *)
open class MXAppExitMetric : MXMetric {

    open var foregroundExitData: MXForegroundExitData { get }
  // 后台应用退出数据
    open var backgroundExitData: MXBackgroundExitData { get }
}

/// 不同原因造成后台应用退出的次数记录
@available(iOS 14.0, *)
open class MXBackgroundExitData : NSObject, NSSecureCoding {

    open var cumulativeNormalAppExitCount: Int { get }

    open var cumulativeMemoryResourceLimitExitCount: Int { get }

    open var cumulativeCPUResourceLimitExitCount: Int { get }

    open var cumulativeMemoryPressureExitCount: Int { get }

    open var cumulativeBadAccessExitCount: Int { get }

    open var cumulativeAbnormalExitCount: Int { get }

    open var cumulativeIllegalInstructionExitCount: Int { get }

    open var cumulativeAppWatchdogExitCount: Int { get }

    open var cumulativeSuspendedWithLockedFileExitCount: Int { get }

    open var cumulativeBackgroundTaskAssertionTimeoutExitCount: Int { get }
}

那开发者如何在代码中获取上面所说的所有这些数据呢？示例如下：

import MetricKit

class MySubscriber: NSObject, MXMetricManagerSubscriber {
    var metricManager: MXMetricManager?

    override init() {
        super.init()

        metricManager = MXMetricManager.shared

        metricManager?.add(self)
    }

    deinit {
        metricManager?.remove(self)
    }

   /// 系统每天至多调用该方法一次
    func didReceive(_ payloads: [MXMetricPayload]) {
        for payload in payloads {
          // upload data to your server
        }
    }

   /// 系统每天至多调用该方法一次
    func didReceive(_ payloads: [MXDiagnosticPayload]) {
        for payload in payloads {
            // upload data to your server
        }
    }
}

通过 MXMetricManagerSubscriber 的两个 didReceive 代理方法，可以获取到相关诊断信息。不过要注意，这两个代理方法，系统每天至多调用一次，每次会返回过去 24 小时内的数据。

关于 MetricKit 的使用，还可以参考 WWDC20 What's new in MetricKit[8]。

Xcode Metrics Ogranizer

什么是 Xcode Metrics Ogranizer？

1. 性能分析工具
2. 开箱即用，无需改动 App
3. 线上用户的诊断信息收集，符合用户数据隐私条款

其工作原理是：应用运行过程中，系统会记录各项指标，并发送到苹果服务器，自动生成可视化的报告供开发者查看。可以方便开发者快速查看线上用户的性能数据。

在全新的 Xcode 12 中，Ogranizer 包含如下指标：

其中的 Crashes、Energy、Hang Rate、Memory 等指标可以帮助查看后台应用终止的问题。

总结

Session 的末尾苹果给出了三条最重要的建议：

1. 找出应用终止的原因，并修复掉 bug
2. 减少应用的内存占用
3. 使用 UIKit 的 restoration API