序文
この連載のパフォーマンスの最適化：
1は、説明の仕方によって簡単に理解するために、技術の実用的な値説明
2、詳細に記述されたソースの追跡、ソース・キャプチャー、構造描画クラスを、詳細に探査法の原則を説明してみてください
3デモGithubのプロジェクトを実行することができます提供し、私は、コードを提供している、より多くのアイデア、より良いアイデア、くださいCVの適切な提供
4、いくつかのピットを探索するプロセスの動作原理の際の注意事項のセットを終え、またはデモでは
、5図GIFを使用して、最も直感的な業績は、**デモ示しあなたは詳細が薄すぎると思われる場合は、結論を見てスキップすることができます。
限られた容量は、説明が不適切、歓迎メッセージの批判を見つけなければなりません。
記事を接続：速度最適化を開始
ボディ概要
- DDMS
- SYSTRACE
- TraceView
- オーバードローについて
テキスト
DDMS
DDMSは、のDalvikデバッグモニタサービス、Androidの開発環境のDalvik [仮想マシン]デバッグモニタサービスの略です
以前使用eclipse時間は、DDMSを開くには、直接の入り口がありますが、AndroidStudioを使用するので、入り口はしませんでした....が、実際にSDKディレクトリ内にまだそこにあります。
DDMSを開いた後：
具体的に、後に発言を暗く。
SYSTRACE
SYSTRACEは、コマンドのSDKで、それはPythonで書かれ、python2.7を使用していたが、後にGoogleは、このコマンドは更新されていませんのpython 3.0を更新し、唯一のpython 2.7で、使用SYSTRACEコマンドに今私たちをリードライン上の2.7.16、公式サイトのダウンロードの最新バージョン2.7で通常の状況下で、バージョン、。
だからここでSYSTRACEコマンド？
前提
我々は適切にPythonコマンドを使用できるようになるまで、最初に我々は良いpython2.7.16をインストールしたいすべての、それを使用して、環境変数を設定するには（
SYSTRACEは、一定期間のAndroidデバイス上のインデックスデータへのクローラは、私のように理解されている：機器の操作ログが、これはテキストログではなく、htmlファイルは、あなたがGoogleのブラウザを使用する必要がある クロムを： //トレース/プラグインが表示されます。次のように具体的な手順は次のとおりです。
1. CMD、SYSTRACEディレクトリを入力します。
2.入力して python systrace.py -b 32768 -t 5 -o mytrace.html wm gfx input view sched freq入力し、その後、
コマンドの文字列を説明するために本文不做systrace命令的详解，这些东西都是死命令，百度即可）（：
pythonPythonスクリプトを実行しますsystrace.py脚本名称-bバッファサイズを設定します-tクロール5秒ログ-oこの内のファイルへの出力mytrace.htmlwmウィンドウマネージャのログ内の情報ウィンドウマネージャが含まれていますgfxグラフィックス・ログには、レンダリング情報グラフィックスが含まれていますinput入力ログには、情報入力装置が含まれていますviewシステムビューシステムに含まビューログ情報schedCPUのスケジューリング情報をスケジューリングすると、CPUのログを含みfreqCPU周波数のログには情報が含まれています
ここではピットは以下のとおりです。
いくつかの実際のマシンでは、例えば
vivo X7、それが生成されます。html失敗したファイルを、何とか、私はシミュレータ、うまく、まだ他のモデルをテスト実機を変更しました。
網易は、私は、私は次のような結果を得るために実験シミュレータを使用しMUMU：
3.ファイルを取得した後、Googleのブラウザを開く：アドレスバーに chrome://tracing/ して、ちょうどロード）ファイルあなた:(またはHTMLファイルをダブルクリックします
我々はCPU、マルチコアCPUのスケジューリング状況、UIメインスレッド、スレッドのレンダリングなどの赤いマークのフォントの使用上の画像を含むパフォーマンス指標の多くを、取得するが、私たちは主な問題を解決するために、アプリケーション層の開発4は、アプリカトンです一般的にちょうどに焦点を当てる必要があります メインUIスレッド掉帧情况次の図に従うことができます。
これを見て詳細带圈的F：
- 全体座標、横軸は時間であり、時間の経過とともに指標の代わりに、左から右に時間スケールが増加
带圈的F：緑、黄色と赤。緑が通常のドローを示し、我々は気にする必要はありません場合は、懸念は、特に赤、黄、赤です。- 赤F上でマウスをクリックして、キーボードを押す
Gキーを、あるでしょう红色的竖线長い各2（携帯電話の画面のリフレッシュレートを約各図ので、まだ60でのほとんどの間に赤い線の代表16.67MS）、このFこれは、UIがの期間内に完了することができない場合は、長い描かれたUIは、はるかに1よりもフレーム落ちが発生しますので、理由は、赤で、一度ユーザーの認識の下に、フレーム落ちということであるカトン。- ルック：
。
ドラッグ＆ドロップのマウスを使用して、あなたはそれが描画するのに要する時間が長いことをグラフィカルインタフェースを介して見ることができますに116.868ms
- 以下の警告欄には疑いが見つかった
掉帧犯人を
ここでは、私たちの反映bitmapアップロードされたフレームLEDオフの景色を。
私たちは、あなたが見ることができ、次の二つの矢印を拡大し続けます。
ここでは、英語の記述は、私たちに、私はおそらく、この一節を翻訳助言を与えるために、Googleのエンジニアであります：
最初の段落の
description意味：修改/新绘制的位图必须上传到GPU。因为如果上传的总像素量很大，这是很昂贵的，所以每帧减少这个动画/上下文中位图的波动量。
第二段落の
description手段：生成这个帧的工作被重新调度了几毫秒，这是jank的功劳。确保UI线程上的代码不会阻塞其他线程上的工作，并且后台线程(例如网络或位图加载)在android.os上运行。进程#THREAD_PRIORITY_BACKGROUND或更低，因此它们不太可能中断UI线程。这些后台线程应该在内核进程的调度部分以130或更高的优先级出现。
一般的に、あること
Bitmap的使用不当导致掉帧、解決策はおそらくです：あまりにも大きなビットマップは、負荷への適切なサイズまたはバックグラウンドスレッドに切断するために
、より具体的な例は、他のソリューションをフレーム落ちとしては、特定の出会いに応じてケースを調査する必要がありますデータ。
Trace.beginSectionとTrace.endSectionについて
2つのAPIはandroidSdkあると、それは、タグを追加し、役割がSYSTRACEプラスタグにある、来て、それはSYSTRACEグラフィックスでコードの我々の2つのAPIピースの間などが実装に反映されます。
簡単に言えば、あなたは、コードの一部の周りにある、プラスこのようなTrace.beginSectionとTrace.endSection、：
だから、あなたはSYSTRACEグラフィックでこれを見つけます。
目に見えるが、時間のかかるなど我々のコードの実装がに反映させることができるsystrace、それがになり、エリア上の赤いボックスをクリックし、グラフィックsystrace画面の一番下で見つかりました：
あなたがタグコードの実行が長い（16.67MS）以上かかる追加する場合は、そのフレームのうち、メインUIスレッドを引き起こしたコードの一部は、ユーザーがそうカトンを感じることがあります。
ここでピットがあります
あなたはtrace.beginSectionとendSectionの上に追加した場合、あなたはまだ、あなたのSYSTRACEコマンドを確認し、あなた自身の最高のグラフィックタグセットに表示されていない、何の-a [アプリのパッケージ名]を増やしていないされていません
結論う
上記の例では、コールドスタートSYSTRACEをつかまえたとき、私は、アプリを使用するので、ここで質問にコードを書くコールドスタートの反射で、フレーム落ち。SYSTRACE開始後グラブSYSTRACE時間が長すぎるし、アプリを操作しなければならないことに注意してください。
問題を完全に解決していないがドロップされたフレームの発見後、見ているアラートは、Googleが我々のアプリの最適化の提案の方向性を与える見ることができますが、少なくとも、決定の一般的な方向性を、おそらくどのような質問のうち、コードの一部を知っています、。
TraceView
コードは、アプリケーションに加え Debug.startMethodTracing("/sdCard/zhouzhou");て、Debug.stopMethodTracing();上記のコードは、2つのコードが具現ことを確実にするために行うことができ、その後、アプリケーションを実行します。たとえば、次のように：
クレーター
あなたは直接のスロー後に例外を実行を追加する場合、上記のコードは、あなたがこれを追加する権限を持っていないことを確認してください。
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
次に、コンピュータにエクスポートされたファイルを、見つけます：
その後、我々はまず、我々は、DDMSを使用する最初のDDMSを開いて、[ファイル] - のOpenFileだけで、ファイルを開くべきであると述べ.trace
これは、すべてのメソッド呼び出しのコードが含まれています。
表ショー
テーブルトップは、次のように各列の記述があり、そこにあります：
我々は、すべての関係することはできませんので、多くのものが、2つだけに集中する必要があります。
Cpu Time/Callより長い平均時間関数実行機能（長い関数）Call+Recur Calls/Total、非常に多くのコール数の機能。
あなたは、上記の2つの指標臨時は、特にこのような呼び出しの数は、各呼び出しはその後、基本的には、最適なポイントを決定することができ、私たち自身の道を書くことができるようにも特に長い時間がかかり、ことが判明した場合。
オーバードローについて
コンセプト：如果屏幕的一片区域，在渲染的过程中，被绘制了太多次，则称为过度绘制 。
どうかを確認する方法：
図はMUMUエミュレータの設定インターフェースで、我々はクリック显示过度绘制区域インターフェイスを見つけるには、色が変更されています。
浅いから深いの色は、より深い、図面は遷移がより深刻になり表します。一般的には、以下の色を持っています：
- ホワイト：ノーオーバードロー。
- 青：オーバードローは倍増しました。ピクセルは受け入れるように、二回描かれたが、全体のインターフェースが青である場合、そのショーはまだ、あなたは1つの引き分けを保存することができ無駄にそこに描かれています。
- 緑：オーバードロー二回。最適化しようと。
- 光は、赤：オーバードロー3回。
- ダーク：オーバードロー4回。非常に深刻かつ最適化されなければなりません。
描画への移行を最適化するには？
- 過度のドローをチェックして、あなたのコードならば、複雑なレイアウト表示オーバードローの多数を発見し、それが考慮されなければなりません
用自定义View自己去绘制。- あなたのレイアウトXMLの場合は、検討し、ネストがたくさんあります
去掉某些 backgroundバックグラウンドがないため、UIスレッドが描画するために、この時間を行うことはありません、- あなたはレイアウトがある背景を使用する必要がある場合のビジネスニーズを満たしながら、その後、検討します
减少一定的层级。
エピローグ
上記の3つのツールを使用しなければならない我々のアプリのパフォーマンスの最適化を使用します。次のようにおそらくアイデアがあります
1. SYSTRACEフレームのおおよその位置を見つけるために.htmlファイル、グラフィック観察を、把持
2 Trace.beginSectionおよびTrace.endSection正確なコードブロックを決定するために、推定を繰り返し
オープンDDMS 3. traceView把持.traceログドロップされたフレームの正確な原因を判断するために非常に長い時間のかかる関数または周波数の関数を探しています
3つのツールは、間違っていた、特に何の我々のアプリを決定するために組み合わせて使用する必要があります。
トピックを展開
この記事では、唯一の一般的なアイデアを提供し、理由は潜在的なパフォーマンスの最適化をあまりにも頻繁にあるデモを与えていない、我々は結果が自分のツールが検出されて行くの後に唯一の場所を取るために、何が起こったのか、具体的にそれらを一覧表示することができません推論、解決するには、実証します。
パフォーマンスの最適化は常にスペースを最適化する必要があり、無限大です。この記事では、特に最適化し、どの程度まで、唯一の目安方向を与え、それはすべて自己修復のためにあなたに依存します。
パフォーマンスの最適化のために使用することができる3つのツール上で、しかし、彼らの役割は、木材が表示されないだけでなく、最適化性能にあります。たとえば、SYSTRACEについては、この事は、私が唯一のカトンは、フレーム落ち上記の記事の状況を確認するために使用されるが、それは実際には、マルチコア割り当てのCPUとCPUスケジューリングを表示することができ、スレッドは、スイッチなどのメインスレッドの状態を確認することができます。
次へ：内存抖动和泄漏的优化
