3

現在、クラッシュレポート用のiOSアプリのサードパーティソリューションまたはカスタムソリューションを評価中です。Crashlytics、BugSense、Testflightを検討しています。それらはすべて、ライブクラッシュレポートという目的を果たしているようです。また、 Xcode4.2のデバッグに沿ったカスタムソリューションの実装を検討してきましたが、スタック呼び出しを象徴していません

2つの質問：

  1. サードパーティのソリューション（Crashlytics、BugSenseなど）は、それを使用したい唯一の目的がクラッシュレポートである場合、カスタムソリューションよりも優れていますか？
  2. カスタム例外ハンドラーに追加できる機能の量。たとえば、HTTP POSTを使用してサーバーにスタックトレースを送信する場合、例外ハンドラーで実行できますか、またはアプリケーションが次に起動するまで待つ必要があります。ログを送信しますか？例外ハンドラはどれくらい早く終了する必要がありますか？

ありがとう、Hetal

4

1 に答える 1

3

独自のクラッシュレポートソリューションを実行するべきではありませんが、信頼性が高く安全なクラッシュレポーターを作成するのは難しいため、既存のソリューションを使用してください。PLCrashReporterの開発者であるLandonFullerが、この記事でその理由を説明しています：Reliable Crash Reporting

一般に、クラッシュが発生した後に非同期セーフでないコードを実行することは、絶対に避けてください。これは、Objective-Cコードをまったく避ける必要があることを意味します。これは、クラッシュレポートは、次回の起動時にのみサーバーに送信する必要があることも意味します。また、デフォルトでPLCrashReporterを使用するサードパーティのフレームワークに依存しないでください。フレームワークが追加で実行するものはすべて非同期セーフで実装する必要があるためです。

独自の例外ハンドラーを作成することは、PLCrashReporterに基づくものほど詳細で、優れた、信頼できるものになることはほとんどありません。

前述のサードパーティソリューションに加えて、オープンソースソリューションQuincyKit（PLCrashReporterとコンパニオンPHPベースの基本サーバーソリューションに基づく）およびHockeyAppもあり、QuincyKitクライアントでも使用できます。（注：私はこれら2つのソリューションの開発者の1人です）

于 2012-08-07T00:43:35.513 に答える