以实战 iOS 连续崩溃检测与自修复
实战 iOS 连续崩溃检测与自修复
背景
在近期 iOS 上线的版本，友盟在它的升级版本中默认就自动进行用户的崩溃收集上报。
如果只是恶心一下开发也就算了，然而在发版本时，却发现友盟的代码没有对上报的数据，做类型的
安全判断
，导致读取数据
每次都会crash
.
搞崩溃检测的，自己却导致 App 不断崩溃 ： ）
堆栈如下：
从方法名称
[UMCrash initUMCrash:channel:]
和
[WPKSetup sendAllReports]
可以很容易看出来, 这是友盟在做初始化的时候，对崩溃信息进行了一次检测，然后做上报，在处理数据的时候挂掉了。
看不到具体代码，控制台看到直接原因是:
[NSTaggedPointerString objectForKey:]: unrecognized selector sent to instance
由于友盟的初始化发生在很早的时候(我们一般都放在启动阶段)。这就导致大多服务还没起来，应用就已经崩溃了。只要出现了这种情况，每次打开App, 都会因为一样的问题，而连续闪退。
连续崩溃的后果
那么像这样的连续崩溃，会造成什么后果呢？
可以总结为以下的 3 点：
- 开发无感知 .由于在启动阶段就直接崩溃掉，崩溃收集平台 bugly / 友盟 都没有相关信息。更无从谈修复。
- 用户无法反馈 .因为每次进来都崩溃，也无法反馈相关信息给到客服。
- 新用户 0 体验 .当 App 连续 3 次都进入就闪退，我自己来说，是肯定不再使用这一款无法体验的 App。
解决方案
面对上述的情况，因为掌握可复现的场景，通过技术手段，我们的确可以 hook 掉它的上传方法，从而解决崩溃问题。
例如这次,对我们发生的路径中的
[WPKSetup sendAllReports]
进行截获，不再执行。那么它当然不再崩溃。
但是上面解决方法有 3 点问题：
- 成本取舍问题，原有的功能因为一次偶现崩溃场景而直接禁用。
- SDK 功能缺失，甚至也可能引入新的问题。
- 只解决了当下的场景，缺乏必要手段解决其它的连续崩溃问题。也就是说，保得了一时，保不了一世。
进行连续崩溃检测
在前面有提到过，连续崩溃的一大问题是--开发无感知。
也就是说，我们连问题发生了都不知道，所以首要做到的是
发现问题
。
通常最先想到的思路，就是和崩溃上报框架一样，通过捕获异常，来观察它的每次崩溃。
捕获异常的操作，也存在两个缺点：
- 会与已有处理异常的代码重复，耦合
- 与第三方 crash 收集框架的冲突，导致漏检测
对于第二点与第三方崩溃收集框架的冲突，是影响最大的地方，因为他们的代码通常对我们来说都是看不到的。
- 持久化一个 crashCount 变量
- 每次启动 crashCount = crashCount +1
- 在 x 秒后，crashCount = 0
通过
crashCount
来代表崩溃次数，每次启动的时候让它加 1,如果 App 存活过一段时间，那么证明没有发生连续崩溃，将它置空复位。一旦超过我们设定的次数阈值，证明连续这几次时间阈值内，都没存活过去，发生了异常崩溃。
当然也存在
误报
的情况，比如用户在这段时间阈值内，主动杀掉 App。这一点通过调整次数和时间两方面的阈值，可以控制。
控制误报
我们可以在原来的方案中，更进一步控制误报，想办法监听用户主动杀App的场景：
- 用户在前台杀APP
- 用户在后台杀APP
对于误报的情况，大多数都是第一种，在几秒之内，启动时前台杀APP，iOS 中通过
UIApplicationWillTerminateNotification
来监听，收到通知后，将次数置空清零。
自动修复连续崩溃
要对于崩溃进行修复，首先需要知道这类问题的常见原因。
对于代码 bug 的问题，如果固定进入就必现崩溃的话，在测试流程就一般还是会暴露出来。当然并不完全排除代码崩溃的情况。
清除数据
造成线上问题连续崩溃的，肯定是一个“变量”，那么应该是：
- 数据库
- 存储文件
- 服务端数据
对于
数据库
和
存储文件
的修复，我们都做一个清理操作，以本地数据的清理，来保证 App 的正常流程。
对于重要的数据定义，可以先传入云端存起来。
这次我们出现的友盟崩溃，也正是因为读取了存在本地的
问题数据
而导致连续闪退的。
重新请求/运行热修复包
而对于服务端数据处理的失败，通过与服务端排查，返回正常的数据进行解决。也可以提供入口让用户上报或者直接与我们联系。
甚至考虑引入动态修复手段，解决代码 bug ，请求以及运行热修复包。
具体处理
按照
微信读书团队
的处理，是在
didFinishLaunching
的阶段做 hook。当触发崩溃限制数量后，进入修复，修复完成后再调用原方法
didFinishLaunching
，来按照原来的流程进入到 App.
结合我们的工程实际情况，自动修复流程与有细节
差异
:
-
Appdelegate 的
initialize就开始有日志初始化。 -
在
willFinishLaunching的阶段，有一些数据和服务的初始化。 -
applicationDidBecomeActive也有逻辑。 -
进入首页需要拉取的请求和模块逻辑复杂。
需要解决这些问题，不止是对 didFinishLaunching 的阶段做 hook，还要分别对上述的情况进行处理，在崩溃数超过限制后进行拦截。 而中间整合，也发生了如服务找不到崩溃的问题等，需要一点点解决和整合。 目前临时增加一个方法：
+ (BOOL)needFixCrashes{ NSInteger launchCrashes = [self crashCount]; if (launchCrashes >= kContinuousCrashOnLaunchNeedToReport) { return YES; } return NO;}
通过 needFixCrashes 来在各处做控制:
if(needFixCrashes){ return;}//原有正常逻辑处理
在修复后，我们再分别调用对应流程。相当于
[A do],[B do]
..一个个去调用。
更好的思路
ps;作为iOS开发人员必看[ios资料大全]( iOS熊/iOS面试专题.dm )，其中你有想象不到的面试题和学习资料等等
其实对于上述流程，还有一个更好的做法，限于业务时间没做。
我们可以将流程中要 hook 的对象和方法，都想办法存储起来，如使用 NSMapTable 等。
在结束修复后，再按顺序遍历出来对象和方法一个个调用，走完一套启动的流程。
这里的好处在于复用，可以直接
addObject:Selector:
的方式就增加进去，之后修复完成，不需要再写
hard code
一个个调用。
3.3 最终流程
最终检测流程为：
- 启动App, crash=crash+1
- 检查 crash<maxCrash
- crash < maxCrash,则进入正常启动流程, 一段时间后就置空
- crash >= maxCrash, 进入修复引导
修复的流程设计为：
- 设置根控制器为新的控制器，并弹出修复框，提示“检测到应用可能已损坏，是否尝试修复？”
- 用户选择"取消",则 上报信息 到平台，然后 App 退出到后台
- 用户选择"修复",则进行我们的数据清理操作（重要数据考虑先云备份），然后 上报信息 。
- 修复完成后，直接重新初始化全部服务，进入首页。
- 最坏的情况，数据清理也仍然无济于事，记录下一段时间内的“修复”次数。提供方式直接联系到平台，在条件的情况下解决闪退。
实际操作当中，有不少业务待我们梳理，光做到在 所有服务之前检测 ，如果之前没有专门的类收拢处理，就要花时间来做，或者在各处进行判断。总的来说，最主要的思路是：
- 崩溃检测 要在整个 App 里，做到最先启动。代码足够干净和简单。
- 修复时 的数据要分类，哪些重要的要备份，哪些直接删除。
- 修复后 进入 App,路径要足够完整，做到顺畅进入。
4. 总结
连续崩溃问题的发生，可以说是一个 App 最严重的问题，一般来说并不会出现。
而随着用户的增多，任何问题也有可能被无限放大。
所以作为技术人员，需要做好兜底的策略，尽量来消除此类问题，保证好用户体验，通过技术保护手段多留住一个用户就是一个用户。
何况事实证明，未雨绸缪是应该的，这次连续崩溃问题不就发生在了自己身上了吗？
