在iOS上侦听崩溃 [英] Intercepting crashes on iOS

问题描述

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

I would like to catch all exceptions that are occurring in iOS app and log them to file and eventually send them to back-end server used by the app.

我一直在阅读有关此主题的内容，并发现了设备发送和处理的信号的用法，但是我不确定它是否会违反App Store审查指南，否则可能会带来其他问题.

I've been reading about this topic and found usage of signals sent by device and handling them, but I'm not sure if it's gonna break App Store Review guidelines or it may introduce additional issues.

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

I've added following to 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审查指南
• 使用kill(getpid(), SIGKILL)代替exit()更好吗?

---

Questions

• Is this good approach, any other way?
• Will it break App Store Review guidelines because of usage of exit()
• Is it better to use kill(getpid(), SIGKILL) instead of exit()?

资源

• https://github.com/zixun/CrashEye /blob/master/CrashEye/Classes/CrashEye.swift
• https://www.plcrashreporter.org/
• https://chaosinmotion. blog/2009/12/02/a-use-little-chunk-of-iphone-code/
• 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/

推荐答案

以前的Crashlytics iOS SDK维护者.

former Crashlytics iOS SDK maintainer here.

您上面编写的代码确实存在许多技术问题.

The code you've written above does have a number of technical issues.

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

The first is there are actually very few functions that are defined as safe to invoke inside a signal handler. man sigaction lists them. The code you've written is not signal-safe and will deadlock from time to time. It all will depend on what the crashed thread is doing at the time.

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

The second is you are attempting to just exit the program after your handler. You have to keep in mind that signals/exception handlers are process-wide resources, and you might not be the only one using them. You have to save pre-existing handlers and then restore them after handling. Otherwise, you can negatively affect other systems the app might be using. As you've currently written this, even Apple's own crash reporter will not be invoked. But, perhaps you want this behavior.

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

Third, you aren't capturing all threads stacks. This is critical information for a crash report, but adds a lot of complexity.

第四，信号实际上不是最低级别的错误系统.不要与运行时异常(即NSException)相混淆.马赫异常是用于在iOS上实现信号的基本机制.它们是一个更强大的系统，但也要复杂得多.信号具有很多陷阱和局限性，可以避免许多异常.

Fourth, signals actually aren't the lowest level error system. Not to be confused with run time exceptions (ie NSException) mach exceptions are the underlying mechanism used to implement signals on iOS. They are a much more robust system, but are also far more complex. Signals have a bunch of pitfalls and limitations that mach exceptions get around.

这些只是我想到的问题.崩溃报告是一项棘手的事情.但是，我不希望您认为这是魔术，当然不是.您可以构建一个有效的系统.

These are just the issues that come to me off the top of my head. Crash reporting is tricky business. But, I don't want you to think it's magic, of course it's not. You can build a system that works.

我想指出的一件事是，崩溃报告程序没有提供关于失败的反馈.因此，您可能会构建出25％的时间都可以工作的东西，并且由于您只看到有效的报告，因此您认为嘿，这很好！". Crashlytics必须付出多年的努力才能找出失败的原因并设法减轻它们.如果您对这一切都感兴趣，则可以查看我对Crashlytics所做的对话系统.

One thing I do want to point out, is that crash reporters give you no feedback on failure. So, you might build something that works 25% of the time, and because you are only seeing valid reports, you think "hey, this works great!". Crashlytics had to put in effort over many years to identify the causes of failure and try to mitigate them. If this is all interesting to you, you can check out a talk I did about the Crashlytics system.

更新:

那么，如果发布此代码会发生什么?好吧，有时候您会得到有用的报告.有时，您的崩溃处理代码本身也会崩溃，这将导致无限循环.有时，您的代码将陷入僵局，并有效地挂起您的应用程序.

So, what would happen if you ship this code? Well, sometimes you'll get useful reports. Sometimes, your crash handling code will itself crash, which will cause an infinite loop. Sometimes your code will deadlock, and effectively hang your app.

Apple公开了exit公共API(无论好坏)，因此您绝对可以使用它.

Apple has made exit public API (for better or worse), so you are absolutely within the rules to use it.

我建议您仅出于学习目的而继续这条路.如果您有一个真正的应用程序在乎，那么我认为集成一个现有的开源报告系统并将其指向您控制的后端服务器将更具责任感.没有第三方，也没有必要担心弊大于利.

I would recommend continuing down this road for learning purposes only. If you have a real app that you care about, I think it would be more responsible to integrate an existing open-source reporting system and point it to a backend server that you control. No 3rd parties, but also no need to worry about doing more harm than good.

这篇关于在iOS上侦听崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！