Android Vitals を使用してアプリのパフォーマンス、安定性、サイズを改善する

  • テスト
  • 開発
  • 分析

パフォーマンスと安定性は、Google Play での良好な評価に直結します。問題を修正し、動作不良を防止すると、ユーザー エクスペリエンスの向上や評価のアップ、アプリをインストールしたユーザーの定着率の増加につながります。さらに、アプリのサイズを削減することにより、インストール率が向上し、アンインストール数を減らすことができます。

解説

Android Vitals には、安定性、電池、ジャンク、スタートアップ時間、権限の拒否に関するアプリ パフォーマンス指標が表示されます。このような指標を追跡することで、ユーザー エクスペリエンスに直接影響するアプリの動作不良を特定し、修正できるようになります。また、調査が必要な異常を示す主な指標の急激な変化に気付くことができるほか、類似のアプリや選択したアプリのパフォーマンスと比較できるベンチマークも提供されます。アプリの指標が上昇すると宣伝材料となる価値が高まり、Google Play ストアの検索ランキングも向上します。また、Google Play の「新着&更新済み」や「エディターのおすすめ」のコレクション、Google Play アワードのノミネート作品に選ばれる可能性も高まります。

主な指標

  • 安定性 | ANR 発生率: 1 日のセッションで少なくとも 1 回の ANR(アプリケーション応答なし)イベントを経験したユーザーの割合(%)。ANR は通常、UI スレッドやバックグラウンド プロセス(ブロードキャスト レシーバ)のデッドロックや遅延によって発生します。
  • 安定性 | クラッシュ発生率: 1 日のセッションで少なくとも 1 回のクラッシュ イベントを経験したユーザーの割合(%)。クラッシュは通常、未処理の例外、リソースの枯渇、アサーションの失敗などの予期しない状態によって発生します。
  • レンダリング時間 | 16 ms(60 FPS): 50% を超えるフレームでレンダリングに要する時間が 16 ms を上回った 1 日のセッション数の割合(%)。ユーザーによるアプリの操作は、フレームの欠落や遅延なしに、毎秒 60 フレームの速度で実行される必要があります。
  • レンダリング時間 | 700 ms: 1 日にレンダリング時間が 700 ms を超えるフレーム数が 0.1% 以上に達したユーザーの割合(%)。上記のとおり、レンダリング時間が増加するとスムーズな表示ができず、ユーザー エクスペリエンスが劣化します。 レンダリング時間が 700 ms を超えると、ユーザーにはアプリがフリーズしているように見えるおそれがあります。
  • バッテリー | 部分的 wake lock: 1 日に 1 時間以上の wake lock を少なくとも 1 回経験したユーザーの割合(%)。部分的に wake lock のままの状態が発生すると、アイドル状態のデバイスがスリープ状態にならず、電池を節約できなくなります。
  • バッテリー | wakeup: デバイスをフル充電してから 1 時間あたり 60 回以上の wakeup を経験したユーザーの割合(%)。アプリの存続期間外に時間ベースのアラームが実行されたために wakeup が頻繁に発生すると、アイドル状態のデバイスがスリープ状態にならなくなります。
  • スタートアップ時間: コールド、ウォーム、またはホットのスタートアップ時間が長くなったセッションの割合。さまざまな問題が原因でスタートアップ時間が長くなることがありますが、通常は、アプリの初期化時に大量のワークロードや複雑なロジックを実行することが原因です。
  • 権限の拒否: 1 日の権限セッション数のうち、ユーザーが権限リクエストを拒否した、または [次回から表示しない] を選択した割合。権限の拒否には、権限リクエストの理由が不明瞭である、不要または不当なリクエストであると見なされたなどの理由が考えられます。
  • アプリのサイズ: アプリのダウンロードとデバイス上でのサイズを追跡し、これらの指標を類似アプリと比較できます。また、空き容量が少ないデバイスでのアクティブ ユーザー数とアンインストール数の指標も確認できます。リリースの分析に基づいて、アプリのサイズを削減する最適な方法も提示されます。

おすすめの方法

  • 動作不良について考察し、排除する: アプリの開発中に、さまざまな環境でのアプリの動作について考えてみます。たとえば、ハイエンドのフル機能デバイスがアプリのテスト環境の場合、電池やメモリ、帯域幅、CPU / GPU の機能が制限されたローエンド デバイスではどのように動作するかについても忘れずに考慮する必要があります。リリース前レポートを使用すれば、各リリースの前に広範なデバイスでアプリのテストを行えます。
  • アプリの新しいバージョンをリリースした後に Android Vitals を確認する: アプリを公開した後は、Android Vitals を利用することで、実際の本番環境デバイス上のパフォーマンスに関する指標をチェックできます。これにより、特定のデバイスや Android バージョンでユーザーに影響を与える問題や動作不良を特定できます。
  • 問題のあるデバイスを特定する: 特定のデバイスやデバイスセット上でのみ、アプリが動作不良を起こすことがあります。ユーザー エクスペリエンスへの影響の深刻度や、影響を受けるデバイスとユーザーの数に応じて、修正プログラムが利用できるようになるまで、アプリのデバイス ターゲティングを更新して該当するデバイスを除外できます。
  • 問題のある Android バージョンを特定する: 特定の Android バージョン上でのみ、アプリが動作不良を起こすことがあります。ユーザー数の少ない古い Android バージョンの場合は、アプリを更新して動作不良を排除するか、アプリのマニフェストで <uses-sdk> 要素の android:minSdkVersion 属性を、アプリが動作不良を起こさない API レベルに更新します。新しい Android バージョンの場合は、<uses-sdk> 要素の android:maxSdkVersion 属性を更新して新しい Android バージョンを除外するのではなく、必ずアプリを更新して、動作不良を修正するようにしてください。
  • クラッシュ レポート ツールを使用して、クラッシュや ANR を特定し、トレースする: Firebase Crash ReportingCrashlytics などのクラッシュ レポート ツールと、Android Studio デバッグツールを使用して、クラッシュや ANR につながるシナリオを可能な限り多く特定し、トレースします。
  • JobScheduling API を使用して、wake lock と wakeup を回避する: JobScheduler などの JobScheduling API を使用することで、バックグラウンドのプロセスやタスクについて高度なスケジュール設定ができます。これにより、プラットフォームがアイドル状態を適切に管理し、電池を節約できるようになります。
  • FrameMetrics API を使用して、レンダリング時間の遅延を特定する: FrameMetrics を使用して、本番環境デバイスのインタラクションごとのフレーム レンダリング時間を詳細に測定します。これにより、USB 経由で接続されたテストデバイスに依存することなく、本番環境デバイスに対してジャンクを引き起こしている特定のインタラクションやイベントを特定できます。
  • 権限リクエストに関するおすすめの方法を採用する: 権限をリクエストする前にユーザーにその理由を説明し、権限によってユーザーが直ちにメリットを得られるようにします。また、ユーザーが権限の拒否を元に戻せるようにするほか、アプリが正しく機能するための設定も適切に行えるようにします。
  • リリース前レポートを利用する: 実際のデバイスでアプリをテストすることで、アップデートを公開する前に問題を特定し、修正できます。
  • Android App Bundle に切り替える: 切り替えることで、より効率的にアプリをビルドしてリリースできます。コードをリファクタリングせずにアプリのサイズを削減することもできます。