针对iOS崩溃分析和报告 [英] Crash analytics and reporting for iOS

查看:147
本文介绍了针对iOS崩溃分析和报告的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在为我们的iOS应用程序评估第三方解决方案或自定义解决方案以进行崩溃报告。我们正在看Crashlytics,BugSense,Testflight。他们似乎都服务于目的,即实时崩溃报告。
此外,我们一直在寻找自定义解决方案实现沿着 Xcode 4.2调试不象征栈调用



2个问题:


  1. 第三方解决方案(Crashlytics,BugSense等)提供了优于自定义解决方案的优势,当我们想使用它的唯一目的是崩溃报告?

  2. 我们可以在自定义异常处理程序中添加大量的功能如果我想发布stacktrace到一个服务器与HTTP post,我可以在异常处理程序,或者我需要等待,直到我的应用程序启动下一次发送日志?


  3. 感谢,
    Hetal

    解决方案

    您不应该使用自己的崩溃报告解决方案,但使用现有的解决方案,因为编写可靠和安全的崩溃记录器是很困难的。 PLCrashReporter 的开发人员Landon Fuller解释了本文中为什么:可靠的崩溃报告



    一般来说,非异步安全代码一旦崩溃发生,应该避免任何代价!这意味着任何Objective-C代码都必须被避免。这也意味着您崩溃的报告应该只在下次启动时发送到您的服务器。你也不应该依赖默认情况下使用PLCrashReporter的第三方框架,因为任何框架都应该实现异步安全。



    编写自己的异常



    除了你提到的第三方解决方案,还有一个开源解决方案 QuincyKit (基于具有基于PHP的基本服务器解决方案的PLCrashReporter)和 HockeyApp ,它也可以与QuincyKit客户端一起使用。 (注意:我是这两个解决方案的开发者之一)


    We are in the process of evaluating a 3rd party solution or custom solution for our iOS app for crash reporting. We are looking at Crashlytics, BugSense, Testflight. They all seem to serve the purpose i.e. live crash reporting. Also, we have been looking at custom solution implementation along the lines of Xcode 4.2 debug doesn't symbolicate stack call

    2 questions:

    1. Does a 3rd party solution (Crashlytics, BugSense etc) provide an advantage over a custom solution when the only purpose that we want to use it for is crash reporting?
    2. How much of a functionality can we add to the custom exception handler e.g. if I want to post the stacktrace to a server with HTTP post, can I do it in the exception handler or do I need to wait until my application launches the next time to send the logs? How soon should an exception handler exit?

    Thanks, Hetal

    解决方案

    You shouldn't do your own crash reporting solution, but use an existing solution because writing a reliable and safe crash reporter is hard. Landon Fuller, developer of PLCrashReporter, explains why in this article: Reliable Crash Reporting

    In general running any non async-safe code once the crash occurred, should be avoided at any cost! This means that any Objective-C code has to be avoided at all. This also means that you crash reports should only send to your server at the next launch. You should also not rely on a 3rd party framework using PLCrashReporter per default, as whatever the framework does in addition should be implemented done async-safe too.

    Writing your own exception handler will hardly ever be as detailed, good and reliable as anything based on PLCrashReporter.

    In addition to your mentioned 3rd party solutions, there is also the open source solution QuincyKit (based on PLCrashReporter with a companion PHP based basic server solution) and HockeyApp, which can also be used with the QuincyKit client. (Note: I am one of the developers of these two solutions)

    这篇关于针对iOS崩溃分析和报告的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆