Debug.startMethodTracing()コードから直接使用して作成した保存済みの .trace ファイルを開きたいです。ただし、それを PC にコピーして DDMS で開こうとすると、「ファイル [myfile].trace が見つかりませんでした」というエラーが表示されます。これは、メモ帳で問題なくファイルを開いて読み取ることができるためです。 .

ADT、ビルド: v22.0.0-675183 があります。TraceView を使用しようとすると、トレースを停止した後にエラーが発生します。

何が間違っている可能性がありますか？

編集：

コマンドラインで実行しようとしたとき

EDIT 2 空のプロジェクト（Hello worldでのアクティビティのみ）でも問題が発生しました。

AsyncTask を使用して、ListView の各行に対してバックグラウンドでタスク (ディスクからデータをロードする) を実行しています。ただし、TraceView を使用して異なるアプリ スレッド間で CPU がどのように共有されているかを確認すると、メイン スレッドがほぼすべてを消費し、それぞれ約 70 のスレッドがほとんど CPU 時間を消費しないという状況に陥ります。さらに、行が正しく再描画されない (データがロードされない) ため、これらのスレッドはどれも完了していないように見えます。

非表示の行に対応するタスクを実行する前 (または停止した後) に、視覚化する行のタスクを完了します。

単一のスレッドを使用して、対応する Runnable インスタンスを優先する方法はありますか?

この質問は、traceview によって表示されるデータ列の意味に関するものではありません - 私はそれを理解していると思います。

Android 3.2 デバイスと Android 4.1 デバイスでキャプチャされた traceview のトレースを見て、いくつかのことに気付きました。私の質問は、これらが新しい Android リリースで行われた既知の改善なのか、それともデバイスの制限なのか、それともアーティファクトではなく実際に意味があるのか​​ということです。

私が比較している2つのデバイス/OS

• Android 3.2 を実行する 2 コアの Samsung Galaxy Tab 10.1
• Android 4.1 を実行する 4 コアの Google Nexus 7 タブレット

最初に気付いたのは、Android 3.2 を搭載した Samsung Galaxy Tab でキャプチャされたトレースには、「リアルタイム」列がなく、「CPU 時間」列だけがあることです。誰かが理由を知っていますか？

次に気付いたのは、Android 3.2 を搭載した Samsung Galaxy Tab には 2 つのコアがありますが、Samsung Galaxy Tab から取得したキャプチャの traceview スレッド アクティビティ ラインには、特定の時点で実行されているスレッドが常に 1 つしか表示されないことです。一方、Google Nexus 7 では、複数のスレッドが同時に実行されていることが示されています。

両方のデバイスで実行されているアプリは、いくつかのスレッドを起動するテスト アプリであり、メインの UI スレッドを含む各スレッドがしばらくループして、フィボナッチ数列を計算します。これらのスレッドのうち 2 つが、Samsung Galaxy Tab やその他の 2 コアのデバイスで同時に実行できない理由はありません。さらに、一定量の計算を実行するのにかかる時間は、スレッドが 2 つある場合とスレッドが 1 つしかない場合の各スレッドでほぼ同じです。したがって、2 つのスレッドは実際には期待どおりに同時に実行されている必要があります。次に、2 コア デバイスに 3 つのスレッドがある場合、各スレッドが計算を行うのにかかる時間が 50% 増加します。

したがって、これは Android 3.2 を実行している Samsung Galaxy Tab 10.1 でのトレース キャプチャの制限に過ぎないと思います。呼び出しが多い「実際の」アプリのこのデバイスでは、traceview は 2 つのスレッドが同時に実行されているように見えますが、ズームインすると、実際にはアクティビティがインターリーブされ、2 つのスレッドが同時にアクティブとして表示されることはありません。

トレース ファイルのリストがあり、それらを分析する必要があります。ツールを使用せずにプログラムで分析する方法はありますtraceviewか?

とを追加Debug.startMethodTracing("can_act");しました。トレース ファイルのサイズは 0KB です。onCreate Debug.stopMethodTracing();onDestroy

何が悪かったのか？

編集：

トレース ファイルを書き出しますが、サイズは 0 KB です。デバイスのカスタム カメラ アクティビティでメソッドを使用します。後で呼び出しています。super.onDestroy();

そのため、ListView が携帯電話で途切れていたので、TraceView を使用して原因を特定しました。

予想通り、すべてのメソッド呼び出しで newView と bindView に最も時間がかかっていました。

• newView() はすべての時間を inflater.inflate(R.layout.menu_row, parent, false); で費やしています。電話
• bindView() は、すべての時間を holder.icon.setImageResource(resource); で費やしています。

setImageResource をさらに掘り下げたところ、呼び出し階層は次のようになりました: (これらのメソッドはすべて CPU 時間の 99% でした):

1. ImageView.setImageResource
2. ImageView.resolveUri
3. Resources.getDrawable
4. Resources.loadDrawable
5. Drawable.createFromResourceStream
6. BitmapFactory.decodeResourceStream
7. BitmapFactory.decodeStream
8. BitmapFactory.nativeDecodeAsset (これは、自身が最も多くの CPU 時間を引き起こしているメソッドです)。

ListView を最適化するにはどうすればよいですか? (すべての画像のディスク サイズは 15 KB 以下です)。

これは私がxmlを設定しているImageViewです:

編集: ImageView xml を次のように変更しました。

パフォーマンスの向上はありませんでした。

Android アプリのパフォーマンスを向上させるために Android Traceview を学習し始めているのですが、私を混乱させる概念があります。最も深いレベルまでメソッドをトレースした後、子メソッドのリストで、(コンテキスト スイッチ) がほとんどの CPU 時間を消費していることがわかります。

私の質問は次のとおりです。それはどういう意味ですか? それをさらに詳しく追跡できないのはなぜですか？

この例を見てみましょう