QuincyKit/PLCrashReporter:在崩溃之前提供描述 [英] QuincyKit/PLCrashReporter: provide description *before* the crash

查看:31
本文介绍了QuincyKit/PLCrashReporter:在崩溃之前提供描述的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用在 PLCrashReporter 之上运行的 QuincyKit 来发现我的 iOS 应用程序中的生产崩溃并获取日志.有时,如果我在崩溃点以上的几个调用堆栈级别中有一些变量,它将极大地帮助我调试.比如,如果记录处理代码嵌套了很多层,那么它在哪个记录 ID 上崩溃了.

I'm using QuincyKit, which runs on top of PLCrashReporter, to discover production crashes in my iOS app, and to obtain logs. Sometimes, it'd tremendously help me debug if I had some variables from several call stack levels above the crash point. Like, what record ID did it crash on, if the record processing code is many levels of nesting deep.

问题是 - 有没有办法提供某种上下文字符串作为生成时的描述插入到崩溃日志中?我会在进入记录的调用堆栈时设置它,我会在退出时清除它.如果它是非持久性的(即在内存中)会更好——我担心一直写入非易失性存储会对电池造成负担.

The question is - is there a way to provide some kind of context string that gets inserted into a crash log as description at generation time? I'd set it upon entry into a call stack for a record, I'd clear it upon exit. Better if it's non-persistent (i. e. in memory) - writing to the nonvolatile storage all the time would be taxing on the battery, I'm afraid.

推荐答案

找到了有限的解决方法.我使用 共享内存块,其名称源自捆绑包 ID存储上下文字符串.该块在正确关机时被清除.然后我在 Quincy 委托中覆盖 -crashReportDescription 以便它提供共享内存内容(如果有)作为描述.仅当最后一次关闭应用程序崩溃时才为非空.

Found a limited workaround. I use a shared memory block with a name that's derived from bundle ID to store the context string. The block is cleared on proper shutdown. Then I override -crashReportDescription in my Quincy delegate so that it provides the shared memory contents, if any, as description. It is only nonempty if the last app shutdown was a crash.

这种方法显然存在缺陷.例如,如果他们在崩溃和下一次应用启动之间重新启动设备,共享内存信息就会丢失.

There are obviously flaws with this approach. If they, say, restart the device between the crash and the next app startup, the shared memory info is lost.

在设计的第一个版本中,我使用了一个名为 UIPasteboard 的私有内存,而不是共享内存.事实证明,这对性能造成了很大的影响.共享内存的速度要快几个数量级.

in the first version of the design, I used a private, named UIPasteboard instead of shared memory. That turned out to be quite a performance hit. Shared memory is orders of magnitude faster.

但后来他们在 iOS 7 中破坏了共享内存,所以 UIPasteboard 又回来了.无赖.

but then they broke shared memory in iOS 7, so UIPasteboard is back. Bummer.

找到了另一种方法,不太优雅,但它适用于 iOS 7.我将上下文字符串存储在一个普通的静态内存块中.我使用 [[PLCrashReporter sharedReporter] setCrashCallbacks:] 在 PLCrashReporter 中放置了一个自定义崩溃处理程序.在处理程序中,我将所述上下文(如果有)写入文件.在应用启动时,我读取了该文件,并在 -crashReportDescription 中提供了内容(如果有).走开,UIPasteboard.

found another approach, less elegant but it works in iOS 7. I store my context string in a plain static memory block. I place a custom crash handler within PLCrashReporter with [[PLCrashReporter sharedReporter] setCrashCallbacks:]. In the handler, I write out said context (if any) to a file. On app startup, I read said file, and provide the contents (if any) in -crashReportDescription. Go away, UIPasteboard.

这篇关于QuincyKit/PLCrashReporter:在崩溃之前提供描述的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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