Androidパフォーマンスの最適化-最適化の開始

一、前言
APPの最適化は私たちが上級開発エンジニアに進級するために必ず通らなければならない道であり、APPの起動速度の最適化は、私たちがAPPの最適化を開く第一歩でもあります.ユーザーが私たちのソフトウェアを使用する時、最も頻繁にやり取りするのはアプリの起動ページであり、起動ページのロードが遅すぎると、ユーザーの私たちのアプリに対する印象が悪すぎる可能性があり、さらにユーザーの忍耐力を消耗し、ユーザーのアンインストール行為をさらに深刻にする可能性がある.これも、微信が“ ”を起動ページの背景として使用し続け、起動広告を追加しない理由である.
二、APPの三種類の起動方式
Googleの公式ドキュメント「Launch-time Performance」のアプリケーション起動最適化の概要を見てみましょう.
アプリケーションの起動は、冷却起動、熱起動、温起動に分けることができますが、起動が最も遅く、最も時間がかかるのは冷却起動です.
コールドスタート
アプリケーションが起動すると、バックグラウンドにアプリケーションのプロセス(一般的には、プロセスが殺されたり、最初に起動されたりするなど)がありません.この場合、システムは新しいプロセスを再作成してアプリケーションに割り当てます.
ホットスタート
この起動は、既存のプロセスからアプリケーションを起動します.一般的には有効になっているアプリケーションで、backキーまたはhomeキーでシステムのメインインタフェースに戻り、最近のタスクでActivityを再開するプロセスです.オーバーヘッドはコールドスタートよりも小さい.
ウォームスタート
ウォームアップで発生するシーンが多いです.一般的な例:1.ユーザーは、戻りキーを使用してアプリケーションを終了し、すぐにアプリケーションを再起動します.2.アプリケーションはメモリによって消去され、再度アプリケーションを開くと、OnCreate()に保存されているインスタンスの状態で復元されます.
コールドスタートは最初からアプリを起動し、他の2つのスタートはバックグラウンドアクティビティからフロントに戻るプロセスです.熱起動と暖房起動には明らかな区別はなく,一応熱起動と暖房起動を総称して熱起動と呼ぶ.開発では冷却起動の最適化に注目し,Androidの例から冷却起動の起動過程を分析し,冷却起動の最適化案を与えた.
三、APPのコールドスタートプロセス
コールドスタートが開始されると、システムは3つのタスクを順次実行してAPPを起動します.

アプリケーションのロードおよび起動

APPが起動すると、すぐに空白の起動Window

を作成します.

APP作成プロセス

この3つのタスクが実行されると、アプリケーション・プロセスが作成され、アプリケーション・プロセスは次のステップを実行します.

APPオブジェクト

を作成する

メインスレッド

を開く

起動ページ作成Activity

View

をロード

レイアウトviewからスクリーン

へ

初期描画表示ビュー

を行う.
アプリケーションプロセスが初期ペイントを完了すると、システムプロセスは、現在表示されている空白Windowを起動ページのActivityで置き換え、この時点でユーザーはAppを使用することができます.
四、APP起動時間
アプリの起動時間は最適化効果を検証できる根拠であり、起動時間とはアプリケーションを初期化してから起動ページActivityを表示するまでの時間を指す.Google公式解釈:アプリstartup time
logcatを使用して起動時間を表示
Android 4.4(API level 19)以上のAndroidバージョンでは、アプリケーションの起動時にAndroid Studioが自動的にlogcatに起動時間を出力します.この時間は、アプリケーションの開始(作成プロセス)から計算を開始し、ビューの最初の描画(つまりActivityコンテンツがユーザーに表示される)が完了するまでです.
Display表示の場合:

I/ActivityManager: Displayed com.example.app/com.example.app.SplashActivity: +1s742ms (total +49s450ms)

ReportFullyDrawn()メソッド
ActivityのreportFullyDrawn()メソッドは、apkからLogcatメソッドが呼び出されるまでにどれくらいの時間がかかったかをreportFullyDrawn()に印刷します(記事のreportFullyDrawn()はSplashActivityのonCreate()で実行され、表示された時間がDisplayedとそっくりであることがわかります).

I/ActivityManager: Fully drawn com.example.app/com.example.app.SplashActivity: +1s742ms (total +49s450ms)

adbコマンドを実行して起動時間を手動で表示

adb shell am start -W [packagename]/[packagename.SplashActivity]

出力:

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.app/.SplashActivity }
Status: ok
Activity: com.example.app/.SplashActivity
ThisTime: 1368
TotalTime: 1368
WaitTime: 1432
Complete

ThisTime:最後に起動したActivityの起動に時間がかかる.
TotalTime:自分のすべてのActivityの起動に時間がかかります.
TotalTimeだけに注目すればいい
起動時間基準
公式には、起動時間が以下の指標を超えた場合、起動時間が長すぎると考えられ、起動時間の最適化を考慮する必要がある.

冷始動時間が5 s

を超える

熱起動時間が1.5 sを超える

暖房起動時間が2 s

を超える
起動の基礎知識をたくさん話して、下から本当の最適化実戦を説明し始めました.
五、実戦の最適化を開始する
アプリケーションが起動したときのホワイトスクリーンの問題を解決
前述したように、アプリケーションの初期化は一連のプロセスの作成を行い、リソースの初期化作業を行い、この時間にシステムはまず空白のWindowを割り当て、これによりユーザーが最初のインタラクティブなActivityを表示するためにアプリケーションを開き、白い画面の時間を経験することになる.
このとき,appにトピックを定義して解決し,Activityが表示される前にトピックの背景を表示し,空白のWindow段階を埋めることができる.Splash を定義

manifestでこのトピックを参照

最後に、起動ページの表示後にデフォルトのAPPトピックを復元することを覚えておいてください.

  override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setTheme(R.style.AppTheme)
        setContentView(R.layout.activity_splash)
      
  }

この方法は視覚的にユーザに高速起動の感覚を与えるだけで,実際の起動時間を減らすことはできない.
アプリケーション初期化の過負荷を回避
私たちのプロジェクトが大きくなるにつれて、サードパーティ製ライブラリとコンポーネントも徐々に私たちのプロジェクトに依存し、ApplicationのonCreate()で多くのサードパーティ製ライブラリの初期化作業を実行することは避けられません.大量の初期化作業により、このライフサイクルが重すぎて、アプリケーションの起動時間が長くなる可能性があります.そのため、これらのサードパーティ製ライブラリを分類し、最適化する必要があります.

は、onCreate()であり、メインプロセスである

を初期化する必要があります.

は遅延可能であるが、

をApplicationで初期化する必要がある.

は、起動ページのライフサイクルコールバックの初期化

に遅延することができる.

は、使用時まで遅延して

を再初期化する.
皆さんは自分のプロジェクトに基づいてコードを整理することができて、実行を遅らせることができるのはIntentServiceあるいはWork Threadの中で初期化を行うべきです.

例えばEventBusはActivityで使用する必要があり、Applicationで

を初期化する必要がある.

、例えばBugly、GrowingIOなどの類似ライブラリは、Work Threadにおいて

を初期化することができる.

、例えば地図測位、ImageLoadは、使用前の初期化

に遅延することができる.

SplashActivityでネットワークにロードするリソースは、初めてロードしてキャッシュに保存することができ、次回起動時に

が表示されます.

サードパーティ製ライブラリの中には、プライマリスレッドで

を初期化する必要があることに注意してください.

データベースI/O操作をメインスレッドに置かないで

を実行するなど、時間のかかる操作を避ける.

不要または重複するコードを削除する

トップスクリーンActivityにおけるネットワーク要求密度

を低減する.