序文
記事のこのパフォーマンスの最適化シリーズ：
1、技術の実用的な値説明、説明するためにユーザーフレンドリーな方法で
、2を詳細に記述されたソースの追跡、ソース・キャプチャー、構造描画クラスを、詳細に探査プロセスの原理を説明しようとする
3デモGithubのプロジェクトを実行することができます提供し、私は、コードを提供している、より多くのアイデア、より良いアイデア、くださいCVの適切な提供
4、いくつかのピットを探索するプロセスの動作原理の際の注意事項のセットを終え、またはデモでは
、5図GIFを使用して、最も直感的な業績は、**デモ示し
あなたは詳細が薄すぎると思われる場合は、結論を見てスキップすることができます。
限られた容量は、説明が不適切、歓迎メッセージの批判を見つけなければなりません。
プライマー
アプリのパフォーマンスの最適化は、すべての開発者は、高レベルのスキルを持っている必要がありますが、今書かれていませんほとんどの場合、上のネットワークパフォーマンスの最適化の記事、および無知識の導入は、人々が学習を開始することはできません。この技術を理解する必要がありますので。記事のこのシリーズは、最初のケースを説明し、あなたが効果を見てみましょう、そしてあなたが作品を知っているのでという、詳細を説明します。私が手助けをしたいです。
ケース
アプリのパフォーマンスの最適化は、当然問題は、これらの問題を診断する方法、最適化の前にあるのでしょうか？自然な手段があります。
Q：どのように私たちは私たち自身のアプリは、それがかかった時間始めることを知っていますか？
A：ADBコマンド。次のステップ：
- デバイスがコンピュータに接続されていることを確認します。
- スタートCMDウィンドウ
- 次のように入力します。
adb shell am start -W [app包名]/[launcherActivity的全类名]
android29シミュレータの結果は次のとおりです。
実機VIVO、結果は次のとおりです。
ここでは3つの時間があるでしょう。
thisTime：アムstartコマンドは、複数の活動を開始することがありますが、複数起動した場合、スタートは、1つの、そしてthisTime等しいTOTALTIMEであれば、thisTimeは最後の活動の開始時刻を指します。
TotalTime：新しいアクティビティのアプリケーションの起動時間がかかります。
WaitTime：AMSの現在の活動onResume onPauseからシフトして、TOTALTIMEなどの新しいアプリケーションのアクティビティの合計時間は、含まれ、そのTOTALTIMEよりWAITTIME長く開始。
もちろん、あなたも-R 10 -Sは、行で10回を始め追加し、自分自身の開始の平均時間を計算することができます。
adb shell am start -S -R 10 -W packagename/.MainActivity
ここでは3回、我々はおそらく、彼らはそれがかかった時間、特定のアプリを起動していることがわかります。通常の目視観察によって得られた時間が、正確な数値に特異的、またはコマンドラインを使用する必要があります。あなたはこのような極端な例として、時間がかかるが理想的ではないアプリの起動を、発見した場合の問題は、その後、私たちは、活動のonCreateにいくつかの時間のかかる操作を追加しました
それとも、onResumeに時間のかかる操作に入れ：
その後：
ここでは、開始時刻が全体4000MSが遅くなりますです。
これは私がアナログUIスレッドで時間のかかる操作を実行する極端な場合を上回っています。実際のプロジェクトでは、これらの時間のかかるタスクの活動のいくつかは、開始時間を遅らせることがあり、これはどのように処理すべきか、時間複雑ですか？
4つのカテゴリに2次元のすべての起動タスク：必要：たとえば、私たちのランチャーがWelcomeActivityであることが事前にいくつかのパラメータを取得するために必要なMainActivityの必要性であるならば、それは自動的に終了し、その後、次はMainActivityあり、これらのパラメータの後、取得タスクは必要不可欠なタスクです。耗时：大別を消費する時間の長さのようにしてくださいではなく、時間のかかるが、通常、トレース計算を迅速に行うことができ、メインスレッド上であまりにも多くの時間を無駄にしていません。時間がかかり、通常はサードパーティのSDKの初期化、またはネットワーク要求を行います。
これらの四つの異なる治療法は以下の通りでした。
- 必要に応じて、時間のかかる
この、サードパーティのSDKの初期化は、例えばTinker、ウェルカムページが合併パッチかどうかを知っておく必要がありますが、これは必須であり、それは時間のかかる、またはオーロラプッシュSDKの初期化です。これは、使用するのと同様である异步线程初期スレッドプールは、新しいスレッドのRunnableとして実行しないように、時間のかかることであるため、ここでは、スレッドプールで内側にはなく、スタートの活動よりも、直接新しいスレッドを実行することを推奨し、対処する。
非同期実行利点は、ユーザーがより良い経験のウェルカムページを与え、UIスレッド上の遅延をもたらすまでの時間ではありません。 - 時間のかかる必要はありませんんが
、この、またはのonCreate onResumeでとにかく内部。 - 不要な消費することなく
、この不必要ではなく、時間がかかるため、我々は耐えることができ、それが活動を開始し、まだ新しいスレッドに入る節約節約、開始時刻、パフォーマンスが向上。 - 不要と時間がかかり
、たとえば、データはSDKの初期化を報告し、あなたは初期化に持っている必要はありません。次の活動は完了です。スタート活動でこれを入れないでください。直接移動する第1の初期化コードによって報告されたデータに。
また、親指のルールは：数は、実行が、ページの活動にも長い時間滞在する開始するには、直接のスレッドで、非常に大きい場合、必要かつ時間のかかる作業のために、この時間は、すべてのタスクの1を区別することができる轻重缓急重要な使命を完成し、その後、我々は、非クリティカルなタスクの結果を待たずに、次のアクティビティに進みます。（この考え方によると、私はターンのうち話すことはありません、あなたがあなた自身のギャングの実装コードを書くことができると考えています）。
最後にアプリを起動し、いくつかの例では、重要があるだろう、言及し白屏、その後、再び私たちは、UIのレイアウトを記述します。私たちの活動の開始時刻でAMSは、最初にデフォルトの白いウィンドウが表示され、その後、再び我々が開始した場合、アプリ自体が長すぎる黒と白で、その結果、時間がかかりすぎるので、我々は、UIのレイアウトを記述し、経験からですそれは非常に悪いです。これは、二つの解決策があります。
1、テーマ活動セット、透明の背景色。
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowNoTitle">true</item>
</style>
2は、テーマの活動を画像に設定されますが、最高のは、バックグラウンドスタートページと一致しており、ページを起動したり、実際のUIが発生した場合に、より急になります。
<style name="splash" parent="AppTheme.NoActionBar"> <item name="android:windowBackground">@drawable/bg_splash</item> <item name="android:windowFullscreen">true</item> </style>
エピローグ
開始速度の最適化は、最初のドアに最適化されたアプリの経験で、それは我々のアプリのユーザーエクスペリエンスに直接アップグレードを行います。しかし、実際に私たちは、そのシンプルよりもはるかに多くを行うことができます。たとえば：スタートアップページUIが複雑であれば、また悪い経験もカトンにいくつかの時間の鉛を取るが、これはUIのクラッシュの要件であるUIに描画、私たちは国を変更することはできませんか？引き分けに自分自身のためにかわすためにいくつかの最適化を行います。詳細な記事次のセット。
