iOS 启动连续闪退保护方案

一.引言

“如果某个实体表现出以下任何一种特性,它就具备自主性:自我修复、自我保护、自我维护、对目标的自我控制、自我改进。” —— 凯文·凯利

为了尝试解决这个问题,微信读书开发了 iOS 连续闪退保护工具:GYBootingProtection,检测连续闪退,在连续闪退出现时,尝试自修复 App:

本文探讨了连续闪退问题的产生原因、检测、修复机制,以及如何在你的项目中引入、测试和使用 GYBootingProtection

二.连续闪退检测

首先要检测用户 App 出现了连续闪退的情况,有两种检测方法,捕获异常和计时器。

1.捕获异常

检测连续闪退,可以通过捕获异常来实现,异常有以下种类:

  • Mach 异常:EXC_CRASH
  • UNIX 信号:SIGABRT
  • NSException 异常:应用层,通过 NSUncaughtExceptionHandler 捕获

在念茜的漫谈 iOS Crash 收集框架一文中详细介绍了 Mach 异常和 Unix 信号捕获 crash 的机制。简单来说,异常一般产生自 iOS 的微内核 Mach,然后在 BSD 层转换成 UNIX SIGABRT 信号,以标准 POSIX 信号的形式提供给用户。NSException 是使用者在处理 App 逻辑时,用编程的方法抛出。

如何捕获异常

通过以下方法捕获异常:

  • 利用 Mach API 捕获 Mach 异常
  • 通过 POSIX API 注册 signal(SIGSEGV,signalHandler) 来捕获 UNIX 异常信号
  • 注册 NSUncaughtExceptionHandler 来捕获应用级异常

Crash 上报工具如 PLCrashReporter 通过注册 Mach 异常 + UNIX信号 的 handler 达到检测的目的,对用户提供了处理异常的接口。

如何检测

可以利用 PLCrashReporter 这类工具来检测连续闪退:

  1. 首先维护一个计数变量,表示连续闪退次数
  2. 在 PLCrashReporter 的 crash handler 中加入逻辑:如果启动 5s 内 crash 使计数器加一
  3. 每次启动时,如果连续闪退计数 > n,则检测到了连续闪退
  4. 启动后,执行一个定时任务,在 5s 后重置计数(如果 App 连续闪退则不会重置)

流程图

优缺点

通过 Mach 异常、Unix 信号、NSException 异常来检测闪退,能获得更多的 crash 上下文,但由于 crash 收集框架多使用这些方法,可能会有这样的风险:与第三方 crash 收集框架冲突导致漏检测。另外,可能会与 App 已有的异常处理代码产生耦合。

2.计时器方法

除了通过捕获异常的方式检测连续闪退,还可以通过计数器方法来检测:

  1. 维护一个计数变量,用于表示连续闪退的次数
  2. 在启动 application:didFinishLaunchingWithOptions: 后使计数加一
  3. 接着使用 dispatch_after 方法在 5s 后清零计数,如果 App 活不过 5 秒计数就不会被清零
  4. 如果发现计数变量 > n,表明 App 连续 n 次连续闪退,启动保护流程,重置计数。
  5. 当保护流程完成后,进入 App 正常启动流程

流程图

优缺点

而计数器方法逻辑简单,与原有的代码耦合小。虽然有误报可能(在启动后立即被 kill 掉,误认为 crash),但是可以通过设置阈值来减小误报的误报率。

综上权衡,我们使用计时器方法检测连续闪退。

三.连续闪退修复

检测到连续闪退后,接下来要尝试对闪退进行修复,这里先分析可能的闪退原因,再结合微信读书的例子说明修复流程。

1.闪退原因

连续闪退,可能是 App 启动关键路径中执行了必 crash 的代码,原因可能有:

  1. 数据库损坏:在日常使用如异常退出、断电,或者错误的操作(参考:sqlite corruption causes)。
  2. 文件损坏:处理文件时如果没有 @try...catch,损坏文件会抛出 NSException 导致 crash
  3. 网络返回数据处理异常:比如预期返回数组,但实际返回了字典,对字典对象执行 -objectAtIndex 方法会产生 crash: unknow selector send to object;,或返回破损的 Tar 包,在解压失败导致 crash。
  4. 代码 bug:当必 crash 的代码出现在启动关键路径中,就会导致连续闪退。
  5. 针对 1,可以通过工具修复数据库,或者删除 DB。针对2,可以删除文件来进行修复。对于 3 和 4,我们需要具体地分析 crash 案例,通过 JSPatch 来进行修复。

2.微信读书的修复流程

为了应对上述导致连续闪退的原因,微信读书的修复流程为:

  1. 进入 didFinishLaunch 时检查是否有连续闪退,无则执行 5
  2. 弹 Toast 提示用户是否修复,轻触『修复』执行2,否则执行 5
  3. 尝试下载并执行 JSPatch 补丁 这里是为了解决上述第4点 - 代码 bug 导致的闪退,使用 JSPatch [github]可以进行热修复。在 didFinishLaunching 时,会卡住界面发请求检查是否有可用的 JSPatch 脚本,如果有则加载执行,解决代码 bug 导致的闪退。
  4. 尝试删除Documents /Library / Caches 目录下的所有文件
  5. 这里直接删除了所有用户数据,适用于微信读书这种所有数据都在云端,删除后可以完全从云端恢复。如果你的 App 不属于这种场景,那么应该在 repairBlock 中自定义修复逻辑,比如: a. 不删除文件,只修复数据库 b. 修复前把用户数据备份到云端 c. 收集 crash 样本,查明原因,定制 JSPatch 修复补丁并下发
  6. 退出微信读书登录状态
  7. 进入原 didFinishLaunch 连续闪退检测 + 保护流程如图所示:

3.实现

检测和连续 crash 并修复需要修改原-application:didFinishLaunchingWithOptions: 逻辑,有几种方法:

直接修改 -application:didFinishLaunchingWithOptions: 方法。 新建一个 SubAppDelegate 类来继承 AppDelegate,覆盖 -application:didFinishLaunchingWithOptions: 方法,然后把 main() 函数中的 AppDelegate 替换为 SubAppDelegate 新建一个 AppDelegate 扩展,然后用 method swizzle 的方法替换 -application:didFinishLaunchingWithOptions: 方法。 上述三种方案,对现有项目改动代价是 1 > 2 > 3。因此,我们使用对源码修改代价最小的方案 3 来替换-application:didFinishLaunchingWithOptions:

检测的逻辑 GYBootingProtection 已经处理好,修复的处理预留了接口,可以由用户自定义,把自定义的修复流程传入 repairBlock 即可。

4.使用

引入项目

  1. 下载 (github) 源码 ,将 src 目录下所有文件拖拽到你的 Xcode 项目
  2. AppDelegate+GYBootingProtection.monBeforeBootingProtection方法中添加检测前需要执行的代码,比如设置crash上报: (void)onBeforeBootingProtection { [GYBootingProtection setLogger:^(NSString *msg) { // setup logger NSLog(@"%@", msg); }]; [GYBootingProtection setReportBlock:^(NSInteger crashCounts) { // setup crash report }]; }
  3. 在 onBootingProtection 方法中添加修复逻辑,比如删除文件: (void)onBootingProtection { // 检查 JSPatch 更新 ... // 删除 Documents Library Caches 目录下所有文件 [GYBootingProtection deleteAllFilesUnderDocumentsLibraryCaches]; ... } 如需执行异步的修复逻辑,在 onBootingProtectionWithCompletion: 方法添加修复逻辑,并在完成修复后调用 completion : (void)onBootingProtectionWithCompletion:(BoolCompletionBlock)completion { [self onBootingProtection]; // 异步修复 [self asyncRepairWithCompletion:^(void) { // 正常启动流程 if (completion) completion(); }]; }

5.测试

  1. 首先制造连续闪退场景: 启动后 5 秒内,双击 Home 通过上划手势 kill 掉 App,重复多次。(也可以在代码里人为制造crash)
  2. 当连续闪退超过 5 次时,会提示用户修复:
  1. 用户轻触修复,App 重置初始状态,连续闪退问题解决:

源码 https://github.com/liuslevis/GYBootingProtection

相关推荐

微信读书排版引擎自动化测试方案

手游兼容性测试 产品简介

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏青枫的专栏

day70_淘淘商城项目_03_作业

请求URL: /item/update 参数: 表单数据(TbItem) 返回值:Taotaoresult

752
来自专栏源哥的专栏

基于linux的嵌入IPv4协议栈的内容过滤防火墙系统(5)-包过滤模块和内容过滤模块所采用的各种技术详述

3。1 module编程 module可以说是 Linux 的一大革新。有了 module 之后,写 device driver 不再是一项恶梦,修改 ker...

873
来自专栏逸鹏说道

2.并发编程~先导篇(下)

代码实例:https://github.com/lotapp/BaseCode/tree/master/python/5.concurrent/Linux/进程...

803
来自专栏风火数据

hadoop大数据面试题

以下资料来源于互联网,很多都是面试者们去面试的时候遇到的问题,我对其中有的问题做了稍许的修改了回答了部分空白的问题,其中里面有些考题出的的确不是很好,但是也不乏...

1402
来自专栏JackieZheng

照虎画猫写自己的Spring

从细节跳出来 看了部分Spring的代码,前面用了四篇内容写了一些读书笔记。 回想起来,论复杂度,Spring够喝上好几壶的。他就像一颗枝繁叶茂的大树,远处看...

1876
来自专栏向治洪

android守护进程

Service组件在android开发中经常遇到,其经常作为后台服务,需要始终保持运行,负责处理一些必要(见不得人)的任务。而一些安全软件,如360等,会有结束...

2678
来自专栏JadePeng的技术博客

XNginx - nginx 集群可视化管理工具

之前团队的nginx管理,都是运维同学每次去修改配置文件,然后重启,非常不方便,一直想找一个可以方便管理nginx集群的工具,翻遍web,未寻到可用之物,于是自...

2013
来自专栏iOS技术

YYWebImage 源码剖析:线程调度与缓存策略

在 iOS 开发中,异步网络图片下载框架可以说是很大的解放了生产力,通常情况下开发者只需要简单的代码就能将网络图片异步下载并显示到手机屏幕上,并且还带有缓存优化...

1124
来自专栏熊二哥

JavaWeb快速入门

孙卫琴老师的javaweb一书已经买了很多年,由于很厚一直也没有去好好阅读下, 项目发布后有闲暇时间,决定快速学习了,毕竟很多概念和知识主要还是复习。 ? 对...

2645
来自专栏wOw的Android小站

[Objective-C]深入理解GCD

GCD(Grand Central Dispatch)是libdispatch的市场名称,而libdispatch作为Apple的一个库,为并发代码在多核硬件(...

471

扫码关注云+社区