2

アプリで、ANR イベントを再現するのが非常に難しい場合があります。今日それが起こり、/data/anr にあるファイル trace.txt をデバイスから取り出しました。残念ながら、このファイルのデータを理解できません。完全なファイル コンテンツは次のとおりです。アプリの UI が応答しない原因を誰か理解できますか? 私はすでに同様の質問を読みましたが、まだファイルを読むことができません..

完全な trace.txt ファイルの内容をペーストビンに貼り付けました

編集

ペーストビンのファイルはもう利用できず、trace.txt ファイルにアクセスできないため、回答を閉じることができます。

ありがとうございました

4

4 に答える 4

4

Strictmodeを使用して、どの呼び出しが特定のスレッドを遅延させているかを調べることができます。それを使用する最良の方法は、次の形式です。アプリケーション onCreate() で StrictMode を有効にします。その後、そのスレッドでの (ほぼ) すべてのスロー コールがログに報告され、それが発生した場所の完全なスタック トレースが記録されます。

カスタム Application クラスで:

 public void onCreate() {
     if (DEVELOPER_MODE) {
         StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectAll()    // detect everything potentially suspect
                 .penaltyLog()   // penalty is to write to log
                 .build());
         StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                 .detectAll()
                 .penaltyLog()
                 .build());
     }
     super.onCreate();
 }
于 2013-10-25T08:19:04.710 に答える
3

@Mohamed_AbdAllah がコメントに書いているように、「trace.txt は、ANR が発生したときに実行中のすべてのスレッドの状況です。」ANR が発生している間にスレッドから ANR の理由を見つけることは、あなたが投稿したようなトレースでは不可能に思えます。トレース内のこれらのテキストの意味を理解したい場合は、これに興味があるかもしれません。(トレースから ANR が発生したときにどのスレッドが長時間実行されているかを取得できますが、これはおそらく役に立ちません)

または、Android アプリケーションで発生しているクラッシュ/ANR のタイプを確認したい場合 (Google Play で開発および公開したアプリケーションに関心があると仮定します)、クラッシュ レポート API を使用できます。この目的でcrashlyticsを使用していますが、これはアプリケーションのクラッシュを修正するのに非常に役立ちます。この API をアプリケーションに追加すると、Web ページ上のすべてのクラッシュ/ANR を追跡できます。

あなたの目的が trace.txt から ANR の理由を見つける方法を理解することである場合、私にはわかりません。ただし、クラッシュや ANR を見つけて修正する必要がある場合は、クラッシュ レポート API を使用してください。

編集：Google Playで開発および公開したアプリケーションについて話していると思います。まだ Google Play に公開されていないアプリケーションについて話している場合は、@Jeffrey Klardie の提案が必要です。ただし、Google Play のアプリケーションでStrictmodeを有効にすることはお勧めしません。

于 2013-10-24T21:04:02.040 に答える
0

最も可能性の高い原因は、コンパイラが UI スレッドでの web 間操作を待機していることです。

于 2013-10-21T13:34:11.457 に答える
0

コードなしで何が起こっているかを確認するのは本当に難しいので、代わりに、この状況になった場合に自分のコードに何をするかをリストします.

  1. コードで静的分析ツールを実行して、奇妙な動作 (無限ループ、ケースの欠落など) を特定します。個人的にはFindBugsを使用しています。
    1. 静的分析ツールからポップアップするエラーを確認し、実行していることに意味のあるエラーを修正します。
  2. sleep()非常に長いループ、非同期になる可能性のある同期アクティビティ、関数の使用、同期的に処理される非同期アクティビティなど、「悪質な」コードが発生していないかコードを調べます。
  3. 上記のいずれも影響を及ぼさなかった場合は、Logあらゆる場所にステートメントを投入してください。実行からの出力を見て、どこに到達したか、何が繰り返されているかを確認します。
  4. 上記のいずれもうまくいかない場合は、ビールを開けて少しヨガをしてから、うろつきに戻ってさらに掘ってください!
于 2013-10-23T18:31:48.790 に答える