PLCrashReporter の上で動作する QuincyKit を使用して、iOS アプリでの製品のクラッシュを検出し、ログを取得しています。場合によっては、クラッシュ ポイントより上の複数のコール スタック レベルからいくつかの変数があれば、デバッグに非常に役立つことがあります。同様に、レコード処理コードが多くのレベルのネストの深さである場合、どのレコード ID でクラッシュしたか。
問題は、生成時に説明としてクラッシュ ログに挿入されるある種のコンテキスト文字列を提供する方法があるかどうかです。レコードのコール スタックに入るときに設定し、終了するときにクリアします。非永続的 (つまり、メモリ内) の方が良いです。不揮発性ストレージに常に書き込みを行うと、バッテリーに負担がかかるのではないかと思います。
いいえ。ただし、この機能は 2 年以上前に提案されており、パッチがあります。
私は実際には、リング バッファの内容をログに記録できるバージョン (メッセージを効率的にログに記録できる!) を使用したいと考えています。
限定的な回避策を見つけました。バンドル ID から派生した名前を持つ共有メモリ ブロックを使用して、コンテキスト文字列を格納します。ブロックは適切なシャットダウンでクリアされます。次に、Quincy デリゲートをオーバーライド-crashReportDescriptionして、共有メモリの内容があれば説明として提供するようにします。最後のアプリのシャットダウンがクラッシュした場合にのみ空ではありません。
このアプローチには明らかに欠陥があります。たとえば、クラッシュから次のアプリの起動までの間にデバイスを再起動すると、共有メモリ情報が失われます。
編集: デザインの最初のバージョンでは、共有メモリの代わりに UIPasteboard という名前のプライベートを使用しました。それはかなりのパフォーマンスヒットであることが判明しました。共有メモリは桁違いに高速です。
EDIT2:しかし、iOS 7 で共有メモリが壊れたため、UIPasteboard が復活しました。残念。
EDIT3: 別のアプローチを見つけましたが、エレガントではありませんが、iOS 7 で動作します。コンテキスト文字列をプレーンな静的メモリ ブロックに保存します。PLCrashReporter 内にカスタム クラッシュ ハンドラを配置し[[PLCrashReporter sharedReporter] setCrashCallbacks:]ます。ハンドラーで、上記のコンテキスト (存在する場合) をファイルに書き出します。アプリの起動時に、上記のファイルを読み取り、コンテンツ (ある場合) を に提供します-crashReportDescription。消えろ、UIPasteboard。