製品が成熟し、機能が競合製品に追いつき、小集団効果が徐々に現れてくると、性能は表面化しますが、影響は微妙です。
1. 背景
モバイル プロジェクトが成熟するにつれ、多くのアプリやライバル企業は当初、市場シェアを獲得する段階を過ぎ、維持、返済、ユーザーの定着率を高める軌道に入り始めています。初期段階 アーキテクチャ上の制約などによるレガシー問題により、一部の機能は実装されているものの、ユーザーエクスペリエンスが良くなく、一度問題が発生するとユーザーが崩壊し、ユーザーが離れてしまいます。
もちろん、その製品がユニークで必要なものであれば、その性能によってユーザーからの苦情が起こることもありますが、現状では使い続けなければならないという状況があり、昔は12306もあったのですが、今は使い慣れてきています。 Meituan、Ctrip、Fliggy などは、「感覚的に」優れた安定したアプリを長期的に使用しています。
したがって、製品がオプションである場合、「感覚体験」はユーザーの維持、返済、ユーザーの粘着力に影響を与える主要なテストになります。たとえば、私は昔から生放送を見ながら昼寝をする習慣がありました。2017年まではDouyuクライアントを使用していました。その後、Douyu PCクライアントでは長時間プレイすると「カクつき」が頻繁に発生するようになりました。 「再生」、「オーディオとビデオが同期していません」、さらには黒い画面でスタックした場合でも、Huya Live に切り替えました。Douyu が後で新しいバージョンでこれらの問題を修正した可能性がありますが、私は Huya のバージョンを使用していたので、大きな問題はありませんでした使用中に交換することはなく、現在まで使用しています。
パフォーマンスの最適化は常に特別な取り組みであり、継続的な注意が必要です。機能を追いつくには、効率性や収益だけでなく、長期的な持続可能な最適化も考慮する必要があります。一度大きな一歩を踏み出すと、簡単にユーザーを失ってしまいます。
2. パフォーマンス項目の解釈とその影響
1. 肉体的な職業
1.1 パッケージの容積
1>パッケージボリュームとは、インストールパッケージのサイズを指します
2>影響:
2.1>共有
新しいユーザーを引き付ける一般的な方法の中で、共有は重要な部分を占めます。たとえば、アプリのアクティビティ ページから [共有] をクリックして、APK を WhatsApp チャット ボックスに自動的に移動するのが一般的です (一部の企業は、スピードバージョン、およびいくつかのモジュールをインストールした後、Wi-Fiネットワーク経由でダウンロードします）
2.2>ダウンロードしてインストールする
一部のシナリオでは、パッケージ サイズが大きすぎるため、ユーザーがダウンロードしてインストールするかどうかの決定に影響を与える可能性があります。たとえば、ユーザーがダウンロードにデータを使用する場合、ユーザーの携帯電話の容量が不足している場合などです。
1.2 スペース（物理メモリ）の占有
1>スペース使用量は通常、アプリケーション使用量、データ使用量、キャッシュで構成されます
2>影響:
2.1>実行
スペースの使用量が増えると、Android デバイスの負荷が増加し、動作のスムーズさに影響し、場合によってはクラッシュや ANR などが発生することがあります。
2. 起動時間
2.1 コールドスタート
1>コールド スタートは一般に、バックグラウンドでアプリケーション プロセスが存在しないとき (キープアライブ マシンによって収集されたデータを区別する)、ユーザーがアプリを起動するところから始まり、その間にシステムがプロセスを作成してアプリケーションに割り当てることを指します。 、アプリケーションの初期化 (SplashActivity) が完了した後、ホームページに入ります。
2>影響力
2.1> より迅速な入力により、ユーザーはより優れた、より高速なエクスペリエンスを得ることができます。一部の企業は、画面広告を設定することで起動が遅いという問題もカバーします。
2.2> 一般に、コールド スタートの 2/5/8 原則を参照できます。2 秒以内は許容可能、5 秒以内に最適化する必要がある、8 秒以内はエクスペリエンスが低下し、それを超えると事故になります8秒〜
2.2 ホットスタート
1>ホット スタートは、バックグラウンドでプロセスを実行してアプリを起動するのにかかる時間です (プロセスはアクティブです)。
2>影響力
2.1>カットイントランザクションの処理を迅速に完了し、ユーザーができるだけ早く使用を再開できるようにします。
2.2>ホット リスタートは、一般的に 1/2/4 原則を指します。同様に、アプリがバックグラウンドに切り替えてから元に戻り、プロセスがアクティブな場合、この場合、4 秒を超えて操作することはできません。アプリを最適化し、RD と QA を直接最適化します。
2.3 完全な起動
1> 場合によっては、シナリオに応じて、ユーザーがアプリのアイコンをクリックしてからホームページ上で最初に操作可能なフレームが表示されるまでの時間に注目することがあります。この種の統計は、よりユーザーの視点に近く、アプリのアイコンのクリック時間に焦点を当てています。 「体性感覚」起動。ホームページの論理的判断がここで考慮される場合があります。、キャッシュ、データロード、レンダリングなど。
2>影響力
完全な起動が高速化すると、ユーザーのエクスペリエンスが向上し、待機コストが削減されます。
2.4 ディープリンクの起動
1>特定のシナリオでは、ランディング ページを共有してアプリを起動するときなど、ディープリンクの起動時間、起動からジャンプまでのページ レンダリングまでの合計時間に注意が払われます。時間が長すぎると、影響を受けます。アクティビティの最終的な変換。
2>影響力
ディープリンクから起動されるシナリオには通常、特定の目的があります。たとえば、アクティビティのランディング ページは、アプリ内の指定されたアクティビティ ページに戻ります。その後、ジャンプ パス上の必須でない要素を読み込まないか、読み込まないかを選択できます。
2.5 ネットワークなしで開始する
1>一般に、ネットワークがない場合の読み込み、再試行、およびデフォルトの表示期間に重点を置きます。
2>影響力
私は一度、再起動する以外に回復できないネットワークの問題が原因で起動エラーに遭遇しました。デフォルト ページ、更新、再試行ボタンがなく、設定インターフェイスさえも失敗しましたが、後続のインターフェイスでは再試行が制限されていませんでした。 ;
ユーザーが再起動するたびにかかるコストに注意を払う必要があります。これは、高い流暢性が要求される特定のシナリオにとって致命的です。
3.PSS（メモリ使用量）
3.1 Android システムでは、他のプロセスとメモリを共有する (共有ダーティ) ことに加えて、各 APP プロセスはプライベート メモリ (プライベート ダーティ) も使用します。通常、APP のパフォーマンスを測定するには PSS (プライベート メモリ + 比例共有メモリ) を使用します。 .メモリのオーバーヘッド。モバイル デバイスのメモリは固定されているため、メモリ消費量が多すぎるとアプリケーションがフリーズしたりクラッシュしたりするため、メモリをテストする必要があります。通常の状況では、アプリケーションはあまり多くのメモリ リソースを占有すべきではなく、アプリケーション全体の安定性と流暢性を確保するために適時にメモリを解放できます。
adb shell dumpsys meminfo packageName を通じて取得できます。
3.2 影響
Kill: アプリがバックグラウンドに配置されている場合、Android システムがメモリ オーバーヘッド不足の特定の状況に遭遇すると、PSS の降順でプロセスの強制終了を開始します。
クラッシュ：クラッシュ
その他：OOM（メモリリーク）が発生した場合、プログラムラグ、応答遅延、再起動、ANR等が発生する場合もあります。
4.CPU
CPUテストを行う際には、デバイス自体の性能特性に加えて、現在の環境の性能負荷にも注意を払います（例えば、国内のユーザーは通常、WeChat、音楽ソフトウェア、カメラソフトウェアなどを使用しています） . バックグラウンドで開いており、一部の海外地域のユーザーは通常開いています。Facebook、WhatsApp、Instagram など。パフォーマンス テストを行うときは、テスト対象のアプリがデバイスにもたらすパフォーマンスのプレッシャーを考慮することに加えて、次のことを行う必要があります。また、さまざまなデバイスのパフォーマンス負荷下でのテスト対象アプリのパフォーマンスも考慮します。
4.1 留意点
1>全体的な CPU 使用率
2>アプリケーションのCPU使用率
4.2 メソッドに従う
1>Android 独自の DDMS 視覚化ツール
2>Android Studio 3>Linux システムの /proc/stat および /proc/<pid>/stat ファイルを使用して占有率を計算します。
3> top コマンドまたは dumpsys cupinfo などのコマンドを使用して、現在の CPU 状況をリアルタイムで確認します。
4.4 影響
今年後半の King of Kings の特定のバージョンでは、プレイすると非常に熱いことがわかります。システムの互換性の特性に加えて、高い CPU 使用率も高い割合の理由です。 ; アプリケーションの CPU 使用率に注意を払うときは、実効占有率が妥当な範囲内に制御されるようにするために、さまざまな動作環境や機器のパフォーマンス負荷の下での流量、温度、電力などの検証にも注意を払う必要があります。
過度の CPU 使用率は、動作プロセス、温度、消費電力に影響を与えるだけでなく、アプリの再起動、クラッシュ、ANR などの致命的な問題を引き起こす可能性があります。
5.FPS
5.1 FPS (流暢さ)、FPS ゲームをプレイする学生にはよく知られているはずです理論的に言えば、FPS がシステムの期待を満たしていれば (Android システムでは通常、各フレームが 16 ミリ秒以内に描画される必要があります)、明らかな遅延は発生しません。 16ms以内は遅延がありません。描画が完了するとフレームドロップが発生し、ユーザーの注意を引きます。
5.2 影響
フレーム落ちが発生する原因としては、不合理なレイアウト、過剰な描画、頻繁なガベージ コレクションなどが考えられます。フレーム落ちが発生すると、ユーザーは引っかかりやスムーズさの低下を感じ、また、画面のティアリングやオフセットなどの問題が発生します。 FPS ゲームの場合、これは非常に重要な指標です。たとえば、チキンをプレイすると、誰かに会うたびにフリーズします。ネットワークの問題ではなく、FPS の低下である可能性があります。フレームの問題~
6.GPUレンダリング（プロファイルGPUレンダリング）
6.1 GPU レンダリングは一般に各フレームのレンダリング消費量を指し、通常、描画時間、実行時間、処理時間の 3 つの部分で構成されます。ほとんどの Android マシンには GPU レンダリングのデバッグ機能があります。
6.2 影響
GPU レンダリングは一般に FPS の滑らかさに影響します
GPU オーバードロー:
青: 1 回オーバードローされます。
緑: 2 回オーバードロー。
ピンク: 3 回オーバードロー。
赤：4回以上オーバードロー。
7.消費電力
7.1 APP の消費電力は、APP の動作中に関係するすべてのコンポーネントの合計消費電力です。
Wakelock: デバイスのバッテリー寿命を可能な限り延ばすために、Android システムは電力を節約するためにさまざまなハードウェア モジュールを継続的にシャットダウンします。アプリがスリープ中にネットワーク リクエストを行う場合は、まずデバイスをウェイクアップしてからネットワーク リクエストを行い、一定時間が経過すると、デバイスは再びゆっくりとスリープ状態に入ります。
デバイスがフォアグラウンドで実行されている場合、CPU (I/O、処理)、ネットワーク (ネットワークによって送信されるデータ量)、さまざまなセンサー (ジャイロスコープ、GPS) などの使用状況がすべてアプリの能力を決定します。消費ランキング。
7.2 影響
過剰かつ急速な電力消費は、一部のシナリオではユーザーの使用意欲に影響します。シナリオ内の不要なトランザクションをチェックすることで電力消費を最適化できます。また、ユーザー指向以外のタスクを延期し、一部のトランザクションの処理のタイミングなどの戦略を設定することもできます。充電中のデータのバックアップなど）、または特定のリソースの Wi-Fi ダウンロード、分散したタスクの結合など、非充電状況での電力消費に対するユーザーの認識を向上させます。
8. 消費電流
8.1 現在、Android アプリケーション市場には、アプリの実行プロセス中のトラフィック消費統計を視覚的に観察できるトラフィック統計ソフトウェアが多数あります。
8.2 統計的次元
1>Wi-Fi
2>3G/4G/5G
8.3 影響
一般に、ユーザーは、ネットワーク オーバーヘッドの高いアプリはトラフィックを大量に消費するだけでなく、電力も大量に消費すると考えており、携帯電話の動作時の遅延、過熱、クラッシュなどの問題はこれが原因であるとさえ考えています。したがって、トラフィック消費量が多いというユーザーの認識を減らすために、不必要なリソース要求、キャッシュ、リソースダウンロードのタイミングなどをチェックして、ネットワーク消費量に注意を払う必要があります。
9. 互換性
9.1 互換性テストとは、ソフトウェアが特定のハードウェア製造プラットフォーム、異なるアプリケーション ソフトウェア、異なるオペレーティング システム プラットフォーム、異なるネットワーク、その他の環境で適切に動作するかどうかをテストすることを指します。
9.2 影響
異なる Android ブランド、モデル、解像度、異なるアーキテクチャの CPU、異なるオペレーティング システムなどはすべて、ソフトウェアのパフォーマンスに影響します。
10. 安定性
10.1 安定性 クラッシュ、ANR、およびパフォーマンスの側面に加えて、ビジネスの高可用性にも注意を払う必要があります。一部のコア プロセスでは、ユーザーの数が増加し、ビジネスの訪問数が増加すると、安定性の問題が発生しやすくなります。したがって、コアプロセスの安定性を保証することが非常に必要です。
10.2 分類
1>クラッシュ
2>ANR
3>パフォーマンス
4>ビジネスの高可用性
10.3 影響
より高い安定性は、ユーザーの日々の製品ニーズを満たすだけでなく、製品の信頼性を高め続けます。これは、ユーザーの自己宣伝と自己分裂のための重要な前提条件の 1 つです。安定性は、保持と返済に影響を与えるだけでなく、副作用もあります. 成長指標: 監視や自動化などの早期警告メカニズムを通じて、安定性の保証を改善し、安定性の問題に対処するために必要な時間を短縮できます。
3. パフォーマンストライアングル
性能試験を開始する前に、性能試験用のデータを準備することが非常に重要です。製品の視聴国、対象ユーザー、機器環境、ネットワーク環境などに基づいて総合的に策定する必要があります。
1. 設備と環境
過去の性能テストでは、通常、まず現行製品の対象となる上位モデルや上位システム（バージョン）などの関連データをハイブで確認し、性能データ収集機器の割合が高いモデルを選択することで、より性能に近いものを選択します。実際のシーンデータ。
デバイスを入手したら、app_listをインストールしたユーザーを収集し、その国や年齢層などのユーザーを取得するなど、製品が主にカバーしている国に基づいてローカルユーザーのさまざまな環境をシミュレートします。ウェブサイトを分析し、アプリの習慣とサイクルを利用して環境を準備します。
例: 私がかつて実施した海外の音楽ソフトウェア アプリのパフォーマンス テストでは、デバイスの 1 つとして、最大のユーザー ベースを持つ Redmi Note 4 が選択されました。
1>デバイスの主なパラメータ: 4 GB メモリ + 64 GB フラッシュ メモリ、最大 CPU 周波数 2.1 GHz、5.5 インチ画面、4100 mAh バッテリー、5 V/2A 充電、センサー (赤外線、ジャイロスコープ、周囲光センサーなど)、 GPS、指紋認証、デュアルSIMデュアルスタンバイ、MIUI8など。
2>環境の主なパラメータ:
2.1>インストール済み: テスト対象のアプリ、Facebook、WhatsApp、instagram、soloP、メッセンジャー、Snapchat、Twitter、Paytm、Zomato、Swiggy、KFC、ピザハット、Amazon、My More Store、Big Basket、Google Map、Tinder、Book Myショー、インド鉄道、ジュグヌーなど
2.2>開始: テスト対象のアプリ、メッセンジャー、WhatsApp、soloP、およびいくつかの基本的な Google サービスとその他のアプリケーションのバックグラウンド プロセス。
2.3>ネットワーク: 特定の状況によって異なります。
2. シーン
性能テストシナリオの選定についても、基幹業務のカバー率が高い5つの主要プロセスに焦点を当てて整理し、これらのプロセスのシナリオを設計し、設計完了後にレビュー、経路最適化を経て最終計画を決定しました。 、など。
3.指標
ほとんどのパフォーマンス指標には 2 つの曲線があり、1 つは業界平均、もう 1 つは競合製品の曲線です。通常、標準バージョンのパフォーマンス指標は業界平均を下回らず、競合製品の指標にも追いつくように設定されています。一定期間経過後、増分バージョンの性能指標に注目する必要がある 現在のバージョンと前バージョンの性能データが大きく異なる場合、機能実装が適切かどうかを分析する必要がある合理的であれば、パフォーマンス データ ログを分析し、問題のシナリオを特定し、特別な最適化を実行します。
4. 性能アイテム取得ツール
1. 肉体的な職業
1.1 パッケージの容積
Jenkins 統計/APK パッケージ サイズ統計
1.2 スペース（物理メモリ）の占有
システムアプリケーション統計
2. 起動時間
adb/PerfDog/AirtestIDE
3.PSS（メモリ使用量）
adb/Android プロファイラー(Android Studio)/PerfDog/soloP
4.CPU
adb/Android プロファイラー(Android Studio)/PerfDog/soloP
5.FPS
adb/GT/PerfDog
6.GPUレンダリング
Android システム開発者ツール/プロファイル GPU レンダリング/PerfDog
7.消費電力
adb/バッテリーヒストリアン/PerfDog
8. 消費電流
adb/Android プロファイラー(Android Studio)/PerfDog
9. 互換性
クラウドテスト/自動化
10. 安定性
特別なガバナンス/監視/自動化
5. パフォーマンスの自動化とCI（継続的インテグレーション）
1. 物理占有率: Python または他の言語スクリプトを使用して取得します。
2. 起動時間: AirtestIDE (poco+画像認識)+adb を使用して取得。
3. PSS、CPU: AirtestIDE+SoloP を使用して UI オートメーション シーンの外側のネストされたパフォーマンスを記録し、Python スクリプトを通じてパフォーマンス データを分析および計算します。
4. FPS、GPU、消費電力、電流消費: 同様に、airtestIDE+PerfDog+Python を使用して自動データ収集を実現できます。
5. Jenkins とシェル スクリプトを通じてこれらの機能を統合し、既存のパッケージング ツール、仮想マシン、または実マシンを統合して、パフォーマンスの自動化を継続的に統合します。
6. 添付文書
GT パフォーマンス テスト Android バージョンの使用説明書
Jenkins 自動デプロイメントを開始するための詳細なチュートリアル
一生懸命働くことによってのみ合格でき、一生懸命働くことによってのみ優秀になれます〜