1

変数の状態などに関する情報を取得するのに役立つアプリケーションをテストしているときに、大量のログを記録しています。

ただし、本番コードではロギングをまばらに使用する必要があることを読みました（アプリケーションの速度が低下する可能性があるため）。しかし、私の質問は今です：私のアプリが本番環境にあり、人々がそれを使用している場合、クラッシュ（神は禁じられています）が発生するたびに、ログステートメントを削除した場合、クラッシュ情報をどのように解釈できますか？次に、解釈するためのスタックトレースしかないと思いますか？

これは、何が起こったのかを解釈することが本当に不可欠な場合にのみ、本番コードにログインしたままにする必要があることを意味しますか？

また、ロギングステートメントはクラッシュレポートとどのように関連しますか？それらは組み合わされますか？分析とクラッシュレポートとしてFlurryを使用することを考えています...

4

2 に答える 2

2

リリースされたアプリには、間違いなく多くのログを含める必要があります。ご想像のとおり、デバッグ時に非常に役立ちます。また、ログメッセージが適切に記述され、合理的に自明であり、関連するすべての詳細が含まれていることを確認すると、パワーユーザーの自己デバッグにも役立ちます。

優れたロギングシステムには多くの側面があります。従うのが良いことが多い一般的なパターンがいくつかあります（ただし、iOSでは特にいくつかが適用されます-他のものよりもそうです）：

  1. ログを重大度で区別します。エラー、警告、情報提供、デバッグなど。別の例として、Syslogはこれを行います。最初に、より深刻な問題に焦点を当てるのに役立つだけでなく、「有益な」リリースビルドの最小レベルを設定して、より冗長なデバッグの問題を除外し、必要なもののほとんどすべてを維持することができます。うまくいかない。このようにして、非常に冗長または頻繁な（したがって、アプリの速度が低下するリスクがある）ログメッセージを削除しますが、重要なメッセージは残しておきます。
  2. 実行時にログレベルの構成を許可します（iOSでは明らかにありませんが、通常はコマンドラインフラグを介して行われます）。たとえば、デフォルトでは警告とエラーのみを表示できますが、オプションでフラグを使用してそれを展開できます。
  3. 少なくともデバッグビルドでは、すべてのログメッセージにファイル名と行番号を含めます。リリースビルドにファイル名を含めることについては予約があるかもしれませんが、少なくとも行番号を含めると、デバッグ時に適切なコードを確認するのに役立ちます。（偶然または故意に）同じファイル内の複数の場所からの類似したログステートメントがある場合があります。
  4. ログメッセージは、適切な文法と最小限の略語を使用して平易な英語で記述し、関連するすべての変数の値を含めます。エラーまたは警告の場合は、状態の結果についてのステートメントも含めてください。例：「someserver：1234-エラー-18（ETIMEOUT）に接続できません。利用可能なアプリのアップデートがあるかどうかを判断できません。」
  5. ログ内のユーザーの機密データを最小限に抑え、それを含むログの処理には十分注意してください。パスワードやその性質のものをログに記録しないでください。パスワードの長さやハッシュなどの補助的なものもログに記録しないでください。彼らが提供するウェブサイトのアドレスのように一見良性に見えるものでさえ、機密性が高いと見なされる可能性があることに注意してください（彼らはwww.lumberjacksandpressedwildflowers.comに頻繁にアクセスすることを知られたくない場合があります）。これらのログを何らかの方法で送信する場合、これは特に重要です。SSLなどを採用する必要があります。

これらの機能の多くは、 CocoaLumberjackやNSLogger（またはその両方）などの構築済みのロギングシステムから取得できます。他にも間違いありません。

于 2012-11-30T15:32:41.553 に答える
1

私の知る限り、あなたの問題に対処するための最良の選択の1つはCrashaliticsです。これは、完全に統合された、無料で使いやすいクラッシュレポートシステムです。幸運を！

于 2012-11-30T13:28:34.970 に答える