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 中,提供了更加全面的信息。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

iOS中的内嵌汇编

写一篇在iOS上使用汇编的文章的想法在脑袋里面停留了很久了,但是迟迟没有动手。虽然早前在做启动耗时优化的工作中,也做过通过拦截objc_msgSend并插入汇编指令来统计方法调用耗时的工作,但也只仅此而已。刚好最近的时间项目在做安全加固,需要写更多的汇编来提高安全性(文章内汇编使用指令集为ARM64),也就有了本文

发布于:11天以前  |  58次阅读  |  详细内容 »

不会吧,这也行?iOS后台锁屏监听摇一摇

一般情况下,出于省电、权限、合理性等因素考虑,给人的感觉是很多奇怪的需求安卓可以实现,但是iOS就无法实现!今天要介绍的需求也有这种感觉,就是“当 APP 处于后台或锁屏状态时,依旧可以监听到摇一摇,进而触发某些功能,比如:语音播报”。

发布于:1月以前  |  126次阅读  |  详细内容 »

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

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

发布于:1月以前  |  155次阅读  |  详细内容 »

Vue中Axios的封装和API接口的管理

在vue项目中,和后台交互获取数据这块,我们通常使用的是axios库,它是基于promise的http库,可运行在浏览器端和node.js中。他有很多优秀的特性,例如拦截请求和响应、取消请求、转换json、客户端防御XSRF等。所以我们的尤大大也是果断放弃了对其官方库vue-resource的维护,直接推荐我们使用axios库。如果还对axios不了解的,可以移步axios文档。

发布于:1月以前  |  158次阅读  |  详细内容 »

iOS 持续集成:更完备的 App Store Connect API

时隔两年 App Store Connect API 有了更新,WWDC 2018 推出了 App Store Connect API ,用于自动化一些 App Store Connect 后台操作。这次更新包含了 app 元数据相关的API,补上了原来缺失的重要一环, 使得几乎可以通过 App Store Connect API 完成 App Store Connect 上的所有操作。今后开发、证书配置、用户管理、测试、发布全流程都可以通过 API 完成。

发布于:1月以前  |  200次阅读  |  详细内容 »

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

苹果是一家特别注重用户体验的公司,过去几年一直在优化 App 的启动时间,特别是去年的 WWDC 2019 keynote[1] 上提到,在过去一年苹果开发团队对启动时间提升了 200%

发布于:1月以前  |  182次阅读  |  详细内容 »

让你的应用远离越狱:iOS 14 App Attest 防护功能

当越狱在 iOS 设备第一次流行起来时,iOS 开发人员会尝试各种方法来保护自己的应用程序,以让应用免受盗版等不确定因素的困扰。有许多方法可以做到这一点,包括检查 Cydia 是否存在、检测应用程序是否可读取自身沙箱之外的文件、在检测到调试器时让应用程序崩溃等等。

发布于:1月以前  |  197次阅读  |  详细内容 »

探秘 iOS 14 的 WidgetKit

Widget Extension 提供了 small, medium, large 三个尺寸,不同尺寸可以展示不同的数据、不同的界面,开发者也可以锁定自己APP的 Widget 只有某类尺寸,相同的widget也能重复添加。作为添加在主屏幕上的控件,苹果用了 “At a glance” 来形容 widget ,所以 widget extension 是无法交互的,它能做的只有展示一些信息与点击两个作用,点击后就会引导至app,同时为了性能与耗电量的考虑,Widget extension 也不能展示视频和动态图像。

发布于:1月以前  |  215次阅读  |  详细内容 »

iOS14 Widget 万字指北,先人一步获得顶级流量

2020 年 6 月 22 日,苹果召开了第一次线上的开发者大会 - WWDC20。这次发布会上宣布了ARM架构Mac芯片(拳打Intel)、iOS 14 ATT(脚踢Facebook),可谓是一次载入史册(我是爸爸)的发布会了,当然还发布了被称为下一个顶级流量入口的Widget。踩着八月的尾巴,本次我们就来探究一下Widget。本文会从Widget初窥和Widget开发两个维度和章节来探究一下Widget, 其中初窥章节会带您简单的了解一下Widget,适合应用决策者阅读; 开发章节会带着您一步一步的完成设计开发Widget,适合程序员阅读。

发布于:1月以前  |  276次阅读  |  详细内容 »

OCRunner:完全体的iOS热修复方案

为了能够实现一篇文章的思路:Objective-C源码 -> 二进制补丁文件 ->热更新(具体是哪篇我忘了)。当时刚好开始了oc2mango翻译器的漫漫长路(顺带为了学习编译原理,嘻嘻),等基本完成以后,就开始肝OCRunner:完全兼容struct,enum,系统C函数调用,魔改libffi,生成补丁文件等,尽可能兼容Objective-C,为了做一个直接运行OC的快乐人。

发布于:1月以前  |  228次阅读  |  详细内容 »

iOS APP图标版本化

在我们的项目开发过程中,需要频繁打包给测试人员去测试,有时候我们都不知道测试机上安装的版本是否是最新的,这样会造成很多不必要的麻烦和成本。因此我们需要将buildNumber以水印的方式打在APPIcon上,可以很直观的知道当前是哪一个版本。

发布于:1月以前  |  212次阅读  |  详细内容 »

百度App iOS工程化实践: EasyBox破冰之旅

百度App从单一的搜索工具发展到今天以搜索和Feed流为双引擎的综合性内容消费服务平台,其复杂程度已然不可同日而语矣。 作为一个日活过亿的超级App,业务规模庞大,相关技术人员超过千人,客户端支持主流的移动技术,涉及近百业务方,技术形态复杂,各种组件近三百个,代码百万量级,由此带来的工程化问题是技术团队的一个极大挑战。

发布于:1月以前  |  232次阅读  |  详细内容 »

最多阅读

快速配置 Sign In with Apple 1年以前  |  3447次阅读
开篇 关于iOS越狱开发 1年以前  |  2458次阅读
给数组NSMutableArray排序 1年以前  |  2405次阅读
APP适配iOS11 1年以前  |  2379次阅读
在越狱的iPhone设置上使用lldb调试 1年以前  |  2329次阅读
UITableViewCell高亮效果实现 1年以前  |  2232次阅读
使用 GPUImage 实现一个简单相机 1年以前  |  2225次阅读
App Store 审核指南[2017年最新版本] 1年以前  |  2203次阅读
所有iPhone设备尺寸汇总 1年以前  |  2126次阅读
使用ssh访问越狱iPhone的两种方式 1年以前  |  2043次阅读
关于Xcode不能打印崩溃日志 1年以前  |  2015次阅读
使用ssh 访问越狱iPhone的两种方式 1年以前  |  1901次阅读
UIDevice的简单使用 1年以前  |  1742次阅读
为对象添加一个释放时触发的block 1年以前  |  1703次阅读
使用最高权限操作iPhone手机 1年以前  |  1668次阅读