技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

パフォーマンスの収集と分析に関連するツールの概要

モバイル アプリケーションのパフォーマンス データを収集、分析、表示するためのツールは多数あり、大まかに次のカテゴリに分類できます。たとえば、複数のパフォーマンス指標を収集できるモバイル パフォーマンス ツール、perfdog、および Solopi ですが、Solopi はオープンソースであり、pefdog は商用ツールです。商用の Firebase Crashlytics やオープンソースの Sentry ツールなど、クラッシュ分析を実行できるツール。ネットワーク関連のデータを分析する必要がある場合は、Charles または Wireshark を使用できます。さらに、Dynatrace などの包括的なパフォーマンス管理ツールもあります。一般的に、商用ツールの機能、精度、ユーザー エクスペリエンスは、オープン ソース ツールよりも明らかに優れています。個人的な研究と研究としては、オープン ソース ツールから始めるしかありません。したがって、このブログを書くときも、オープンソース ツールを例として使用します。

モバイルパフォーマンステストツール：
PerfDog: アプリケーションのパフォーマンス、CPU、メモリ、消費電力、その他のデータを監視するツールで、モバイル アプリケーションのパフォーマンス テストとリアルタイム監視をサポートします。
Solopi: フレーム レート、CPU、メモリ、その他の指標のリアルタイム監視を含む、モバイル アプリケーションのパフォーマンスのテストと監視に重点を置いています。

クラッシュ解析ツール：
Firebase Crashlytics: Google が提供する強力なクラッシュ レポートおよび分析ツールで、アプリケーションのクラッシュをリアルタイムで監視できます。
Sentry: モバイル アプリケーションのエラー レポートやパフォーマンス監視など、複数のプラットフォームをサポートするオープン ソースのエラー追跡ツール。

ネットワークパフォーマンステストツール：
Charles Proxy: モバイル アプリケーションのネットワーク要求と応答データをキャプチャして分析するネットワーク デバッグ プロキシ ツール。
Wireshark: モバイル アプリケーションのネットワーク パケットのキャプチャと分析をサポートするオープン ソースのネットワーク分析ツール。

APMツール(アプリケーションパフォーマンス管理):
Dynatrace: モバイル アプリケーションのパフォーマンス監視とユーザー エクスペリエンス分析をサポートする、クラウドネイティブのフルスタック パフォーマンス監視ソリューション。

どのようなパフォーマンス指標がどのように収集されるか

  パフォーマンス分析を実行する前に、まず各パフォーマンス指標の意味を理解する必要があります。Solopi によって収集されるパフォーマンス指標を例として、モバイル アプリケーションのパフォーマンスの一般的な指標と、これらの指標がどのように収集されるかを見てみましょう。

フレームレート

フレーム レートの計算式は次のとおりです。フレームレート = 描画されたフレーム数/期間、ほとんどのアプリケーションおよびゲーム開発者にとっての目標フレーム レートは次のとおりです。60FPS(フレーム/秒)、ターゲット フレーム レートが 60FPS なのはなぜですか?最新のスマートフォンやタブレットの画面リフレッシュ レートは 60 Hz であるため、フレーム レートが 60FPS、つまり 1 秒あたりに描画されるフレーム数が 60 に達する限り、ユーザーの視覚効果はよりスムーズになり、遅延は発生しません。最小値を 30FPS より低くすることはできません。これは、モニターが新しいフレームを待機している間、前のフレームの画像を繰り返し表示するため、画像が滑らかでなくなります。高いものでは 90FPS に達することがあります (たとえば、リフレッシュ レートが高いデバイスの場合)。

フレームレート情報の収集方法

  フレーム レートを収集するには 2 つの方法があります。1 つは Choreographer クラスを使用してフレーム レート統計を収集する方法です。これにはアプリケーション内でコードを記述する必要があり、アプリケーションのフレーム レート情報のみを収集できます。別の方法は使用することです gfxinfo ツール。 Solopi を例にとると、1 秒以内のタイムアウト フレーム時間も gfxinfo ツールの情報を通じて計算され、実際のフレーム レートが推定されるため、静止に近い場合、フレーム レートの一部が正しく表示されない場合があります。スライドやページ切り替えなどの動的なシナリオでフレーム レート テストを実施することをお勧めします。 gfxinfo メソッドはすべてのアプリケーションのフレーム レート情報を収集でき、パフォーマンス データ収集ツールとして非常に適しています。そのため、ここでは gfxinfo を使用してフレーム レート情報を収集する方法にも焦点を当てます。

フレーム レート情報を収集するには、主に 2 つの手順があります。第一歩: adb コマンドを通じて gfxinfo 情報を取得します。ステップ2 : 情報を解析し、フレームレート情報を計算します。 gfxinfo 情報の内容は大まかに以下のとおりです。

以降の統計: 統計の開始時刻、単位はナノ秒です。
レンダリングされた合計フレーム数: レンダリングされたフレームの合計数。
ジャンキー フレーム: ジャンキー フレームの数、つまり 16 ミリ秒 (1 秒あたり 60 フレームの更新間隔) を超えるフレームの数。
ジャンキー フレームの割合: 総フレーム数に対するジャンキー フレームの比率。
90 パーセンタイル: 90 パーセンタイル。90% のフレームのレンダリング時間がこの値 (ミリ秒単位) 未満であることを示します。
95 パーセンタイル: 95 パーセンタイル。95% のフレームのレンダリング時間がこの値 (ミリ秒単位) 未満であることを示します。
99 パーセンタイル: 99 パーセンタイル。99% のフレームのレンダリング時間がこの値 (ミリ秒単位) 未満であることを示します。
Number Missed Vsync: 同期されていない垂直同期の数、つまり、時間内にレンダリングできなかったことによるフレームドロップの数です。
数値 高入力遅延: 高入力遅延の数は、長すぎる入力イベント処理時間によって引き起こされる遅延の数を示します。
遅い UI スレッドの数: UI スレッドの応答が遅かった回数、つまり、UI スレッドの処理に時間がかかりすぎた回数。

Solopi を例に挙げると、フレーム レートは gfxinfo 情報のタイムアウト フレーム時間から推定されます。特定のプロジェクトのコードについては、solopi のソース コードを表示できます。

ラグ率/ラグ数

フリーズの回数 : テスト期間中、フレーム レートがしきい値より低いことが検出された期間の数。フレーム レートが一定期間にわたってしきい値を下回ると、それはスタッターとしてカウントされます。ここでの閾値はカスタマイズ可能で、例えば目標フレームレートより60FPS低い場合はフリーズとして記録することができます。つまり、フレームのレンダリング時間が 16 ミリ秒を超える場合、スタックしていると計算されます。

ラグ率 : 合計テスト時間に対する凍結時間の割合。テストでアプリケーションが 120 秒間実行され、その間フレーム レートが 16 FPS を下回ったのが合計 4 回あり、合計の遅延時間が 8 秒であったと仮定すると、遅延の数: 4 回となります。吃音率: 8/120*100%=6.7%。上記の gfxinfo には、ラグ率に関するデータ情報もあります。

CPU/メモリ

  Solopi を例に挙げると、cpu には、アプリケーションのトップレベルのアクティビティが存在するプロセスの CPU 使用率と、単一プロセス アプリケーションの場合のグローバル CPU 使用率が含まれます。マルチプロセス プロセス アプリケーションの場合、このデータはトップレベルの UI プロセスの CPU 使用率を表し、プロセスの切り替えが発生すると、Soloπ は自動的に新しいプロセス データに切り替えることができます。

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

反応時間

  ソロピを例に挙げると、アプリケーションのクリックに対する応答時間と更新時間のデータが含まれます。アプリケーションディメンションデータに属します。ユーザーのクリックからシステムが最初にインターフェース更新を発行するまでの時間が応答時間、システムがインターフェースの更新を停止するまでの時間がリフレッシュ時間です。応答時間をカウントするロジックは、Solopi の公式 Web サイトによると、開始フレームと終了フレームを自動的に認識して応答時間をカウントするというものです。応答時間が正しくありません。たとえば、ユーザーが [スタート] をクリックしてからアプリケーション ページをクリックしたとき、真ん中にいる人の手の速度の操作時間が含まれており、この部分が応答時間にカウントされます。したがって、準備されたページの応答時間を計算する場合は、画面のみを記録し、ページの開始フレームと終了フレームを手動で識別する方がより正確です。画面フレームを記録するための具体的な手順は次のとおりです。

上記は、モバイル アプリケーションにおける一般的なパフォーマンス指標の意味と、それらを収集する方法に関する詳細な手順を理解したものです。クラッシュ等に関しては、今後のブログで詳しくご紹介させて頂きます。