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

it2025-06-13  25

作者:作者:郑一一,iOS 开发者,目前就职于一家少儿英语在线教育公司

Sessions: https://developer.apple.com/videos/play/wwdc2020/10078/

概述

本次 session 主要内容如下:

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

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

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

后台崩溃原因

Crash

CPU resource limit:CPU 占用率过高

Watchdog:主线程长时间未响应

Memory limit exceeded:内存使用超出上限

Memory pressure exit:Jetsam

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:

应用启动

应用进入后台,然后重新进入前台

其常见原因包括:

Dead lock:死锁

代码中存在无限循环

主线程存在一直无法完成的任务

注意:处于调试下是不会出现 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 仍旧有可能发生,可以采取的补救措施是:

在应用进入后台时,将必要的数据持久化到磁盘中

当后台应用终止后,应用重新启动的时候,我们可以使用之前保存在磁盘中的数据,搭配 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 中介绍了可以使用该框架在三个不同阶段进行数据的收集和分析。

XCTest Metrics(开发和测试阶段):在 Unit Test 和 UI Test 中使用

MetricsKit(Beta 和 Public Release 阶段):在代码中,引入框架使用

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?

性能分析工具

开箱即用,无需改动 App

线上用户的诊断信息收集,符合用户数据隐私条款

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

在全新的 Xcode 12 中,Ogranizer 包含如下指标:

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

总结

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

找出应用终止的原因,并修复掉 bug

减少应用的内存占用

使用 UIKit 的 restoration API

推荐阅读

✨ iOS 性能优化:使用 MetricKit 2.0 收集数据

✨ iOS 性能优化:优化 App 启动速度

✨ iOS 性能优化:用电池和性能 API 识别性能趋势

关注我们

我们是「老司机技术周报」,每周会发布一份关于 iOS 的周报,也会定期分享一些和 iOS 相关的技术。欢迎关注。

关注有礼,关注【老司机技术周报】,回复「2020」,领取学习大礼包。

支持作者

这篇文章的内容来自于 《WWDC20 内参》。在这里给大家推荐一下这个专栏,专栏目前已经创作了 108 篇文章,只需要 29.9 元。点击【阅读原文】,就可以购买继续阅读 ~

WWDC 内参 系列是由老司机周报、知识小集合以及 SwiftGG 几个技术组织发起的。已经做了几年了,口碑一直不错。 主要是针对每年的 WWDC 的内容,做一次精选,并号召一群一线互联网的 iOS 开发者,结合自己的实际开发经验、苹果文档和视频内容做二次创作。

参考资料

[1]

维基解释: https://en.wikipedia.org/wiki/Segmentation_fault

[2]

WWDC18 Understanding Crashes and Crash Logs: https://developer.apple.com/videos/play/wwdc2018/414/

[3]

WWDC 2019 全新后台任务框架及最佳实践: https://xiaozhuanlan.com/topic/1806594273

[4]

iOS 内存 abort (Jetsam) 原理探究: https://satanwoo.github.io/2017/10/18/abort/

[5]

Preserving Your App's UI Across Launches: https://developer.apple.com/documentation/uikit/view_controllers/preserving_your_app_s_ui_across_launches

[6]

Restoring Your App’s State: https://developer.apple.com/documentation/uikit/uiviewcontroller/restoring_your_app_s_state

[7]

WWDC2019 Improving Battery Life and Performance: https://developer.apple.com/videos/play/wwdc2019/417/

[8]

WWDC20 What's new in MetricKit: https://developer.apple.com/videos/play/wwdc2020/10081/

最新回复(0)