アプリのクラッシュの追跡

この情報は、クラッシュの追跡方法と、誤ったクラッシュを処理するためのベストプラクティスを理解する場合に役立ちます。

クラッシュがレポートされるタイミング

アプリケーションがバックグラウンドになることなく終了した場合、そのアプリの次回起動時にクラッシュがレポートされます。

クラッシュをレポートする仕組み

iOS では、システム通知を使用して、開発者がアプリケーションのライフサイクルにおける様々な状態やイベントを追跡し、対応できるようにします。

Adobe Mobile iOS SDK には、UIApplicationDidEnterBackgroundNotification 通知に対応する通知ハンドラーがあります。このコードでは、ユーザーがアプリをバックグラウンドにしたことを示す値が設定されます。その後の起動時にその値が見つからない場合は、クラッシュが報告されます。

この方法でクラッシュを測定する理由

このクラッシュ測定手法からは、「ユーザーはアプリを意図的に終了したか」という問いに精度の高い答えが得られます。

Apteligent（旧 Crittercism）などの企業が提供するクラッシュレポートライブラリでは、グローバルな NSException ハンドラーを使用して、より詳細にクラッシュを報告します。アプリが使用できるこの種のハンドラーは 1 つだけです。アドビは、顧客が他のクラッシュレポートプロバイダーを利用する可能性があることを考慮し、ビルドエラー防止のために、グローバルな NSException ハンドラーを実装しないことに決定しました。

誤ったクラッシュが報告される原因

以下のシナリオは、SDK が誤ってクラッシュを報告する原因として知られています。

• Xcode を使用してデバッグを実行する場合は、アプリがフォアグラウンドになっている間にアプリをもう一度起動すると、クラッシュが発生します。

  ヒント

  Xcode から再度起動する前にアプリをバックグラウンドにすることによって、このシナリオでのクラッシュを回避できます。

• アプリがバックグラウンドになっていて、trackActionFromBackground、trackLocation または trackBeacon 以外の呼び出しによって Analytics ヒットを送信し、バックグラウンドになっているときに（手動または OS によって）アプリを終了した場合、次回の起動はクラッシュになります。

  ヒント

  lifecycleTimeout しきい値を超えて発生するバックグラウンドアクティビティによって、さらに偽起動が発生することもあります。

• アプリがバックグラウンドでの取得、ロケーションの更新などの結果としてバックグラウンドで起動され、フォアグラウンドになることなく OS によって終了された場合、（バックグラウンドまたはフォアグラウンドでの）次回の起動はクラッシュになります。

• アプリがバックグラウンドになっているときに、プログラムによってアドビの一時停止フラグを NSUserDefaults から削除した場合、次回起動または再開によってクラッシュが発生します。

偽クラッシュがレポートされないようにする方法

以下のプラクティスを利用して、偽クラッシュがレポートされないようにすることができます。

• iOS SDK 4.8.6 では、新しいライフサイクルセッションが実際に必要かどうかを判断するためのコードが追加されました。

  このコードは、前の節の誤ったクラッシュ 2 と 3 を修正しました。

• 実稼動以外のレポートスイートに対して開発を実施し、誤ったクラッシュ 1 の発生を防ぐ必要があります。

• Adobe Mobile SDK が NSUserDefaults に設定する値を削除または変更しないでください。

  これらの値を SDK 外で変更した場合、レポートされるデータは無効になります。