扣丁书屋

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

本次 session 主要内容如下: 介绍了后台应用终止的常见原因,并提供了一些优化建议 介绍了 MetricsKit 提供的在代码中获取诊断和性能数据的方法 介绍了 Xcode Metrics Ogranizer 提供的关于线上用户性能数据的可视化报告

概述

本次 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 中,提供了更加全面的信息。MetricKitMXMetricPayloadMXDiagnosticPayload 两个类包含了大量诊断数据,下面截取了部分性能指标:

@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

https://mp.weixin.qq.com/s/l8KjyTxCJis-tFUitAj-0g

最多阅读

快速配置 Sign In with Apple 1年以前  |  4269次阅读
使用 GPUImage 实现一个简单相机 2年以前  |  2961次阅读
APP适配iOS11 2年以前  |  2888次阅读
开篇 关于iOS越狱开发 2年以前  |  2819次阅读
在越狱的iPhone设置上使用lldb调试 2年以前  |  2749次阅读
给数组NSMutableArray排序 2年以前  |  2713次阅读
App Store 审核指南[2017年最新版本] 2年以前  |  2710次阅读
所有iPhone设备尺寸汇总 2年以前  |  2636次阅读
UITableViewCell高亮效果实现 2年以前  |  2527次阅读
使用ssh访问越狱iPhone的两种方式 2年以前  |  2490次阅读
关于Xcode不能打印崩溃日志 2年以前  |  2362次阅读
使用ssh 访问越狱iPhone的两种方式 2年以前  |  2248次阅读
为对象添加一个释放时触发的block 2年以前  |  2005次阅读
UIDevice的简单使用 2年以前  |  1997次阅读
使用最高权限操作iPhone手机 2年以前  |  1995次阅读

手机扫码阅读