ios - 在 iOS 上拦截崩溃

Question

描述

我想捕获 iOS 应用程序中发生的所有异常并将它们记录到文件中，并最终将它们发送到应用程序使用的后端服务器。

我一直在阅读有关此主题的内容，并发现了设备发送信号的用法并对其进行了处理，但我不确定它是否会违反 App Store 审核指南或是否会引入其他问题。

我已将以下内容添加到 AppDelegate:

NSSetUncaughtExceptionHandler { (exception) in  
    log.error(exception)  
}  

signal(SIGABRT) { s in  
    log.error(Thread.callStackSymbols.prettified())  
    exit(s)  
}  

signal(SIGILL) { s in  
    log.error(Thread.callStackSymbols.prettified())  
    exit(s)  
}  

signal(SIGSEGV) { s in  
    log.error(Thread.callStackSymbols.prettified())  
    exit(s)  
}

---

问题

• 这种方法好吗？还有其他方法吗？
• 是否会因为使用 exit() 而违反 App Store Review 指南
• 使用 kill(getpid(), SIGKILL) 代替 exit() 更好吗？

---

资源

• https://github.com/zixun/CrashEye/blob/master/CrashEye/Classes/CrashEye.swift
• https://www.plcrashreporter.org/
• https://chaosinmotion.blog/2009/12/02/a-useful-little-chunk-of-iphone-code/

Answer 1

这里是前 Crashlytics iOS SDK 维护者。

您上面编写的代码确实存在一些技术问题。

首先，实际上很少有函数被定义为可以在信号处理程序中安全调用。 man sigaction 列出了它们。您编写的代码不是信号安全的，并且会不时发生死锁。这一切都将取决于崩溃的线程当时正在做什么。

第二个是您试图在您的处理程序之后退出程序。您必须牢记，信号/异常处理程序是进程范围的资源，您可能不是唯一使用它们的人。您必须保存预先存在的处理程序，然后在处理后恢复它们。否则，您可能会对应用程序可能使用的其他系统产生负面影响。正如您目前所写的那样，即使是 Apple 自己的崩溃报告器也不会被调用。但是，也许您想要这种行为。

第三，您没有捕获所有线程堆栈。这是崩溃报告的关键信息，但增加了很多复杂性。

第四，信号实际上不是最低级别的错误系统。不要与运行时异常(即 NSException)混淆，ma​​ch 异常 是用于在 iOS 上实现信号的底层机制。它们是一个更强大的系统，但也更复杂。信号有许多陷阱和限制，而 mach 异常可以绕过。

这些只是我突然想到的问题。崩溃报告是一项棘手的工作。但是，我不想让你认为这是魔法，当然不是。您可以构建一个有效的系统。

我确实想指出的一件事是，崩溃报告器不会向您提供有关失败的反馈。因此，您可能构建了一些在 25% 的时间都有效的东西，并且因为您只看到有效的报告，所以您认为“嘿，这很好用!”。 Crashlytics 必须付出多年的努力来确定失败的原因并尝试减轻它们。如果您对这些感兴趣，可以查看 talk我做了 Crashlytics 系统。

更新:

那么，如果您发送此代码会发生什么情况？好吧，有时您会得到有用的报告。有时，您的崩溃处理代码本身会崩溃，这将导致无限循环。有时您的代码会死锁，并有效挂起您的应用。

Apple 已将 exit 设为公共(public) API(无论好坏)，因此您绝对可以在规则范围内使用它。

我建议仅出于学习目的继续沿着这条路走下去。如果你有一个真正关心的应用程序，我认为集成现有的开源报告系统并将其指向你控制的后端服务器会更负责任。没有第 3 方，也无需担心弊大于利。