iQIYI APP Androidローエンドマシンのパフォーマンス最適化

背景導入

スマートフォン市場ではハイエンドモデルが注目されることが多いですが、ローエンドモデルも無視できないシェアを占めています。ローエンド市場のニーズを満たすために、多くのメーカーがローエンドシリーズの携帯電話を発売し続けています。さらに、ここ数年の中高級モデルは、システムハードウェアの急速な更新に伴い、ローエンドモデルに分類されるようになりました。 iQiyi APP には膨大なユーザーベースがあり、その中にはローエンドモデルのユーザーもかなりの割合を占めています。ローエンドマシンの最適化により、これらのユーザーに安定した、スムーズで効率的なユーザーエクスペリエンスを提供できます。以下では、iQiyi APP のローエンドマシン向けの最適化戦略を、コールドスタート、流暢性、読み込み速度の 3 つの側面から紹介します。

ローエンドマシンのグレーディング戦略

最適化を導入する前に、ローエンドマシンの基準を見てみましょう。通常、ローエンドマシンの判断は、デバイスモデル、メモリサイズ、システムバージョンなどの要素に基づいて行われます。 iQiyi APP には独自のローエンドマシングレーディング戦略があり、ポリシーバックグラウンドでシナリオ (起動、流暢性など) および層 (メモリ、モデル、システムなど) ごとに最適化戦略を構成して、さまざまな環境で最高のエクスペリエンスを保証できます。シナリオ。

最適化の開始

起動は、アプリがユーザーに開く最初のドアであり、その時間はユーザーのその後の視聴エクスペリエンスと維持に直接影響し、ビジネス指標に大きな影響を与えます。したがって、起動の最適化は技術的な最適化の方向で重要な作業内容となります。

最適化の実践

オープンスクリーンのホームページのマージ

初期の頃、iQiyi APP には開始画面とホームページの 2 つのアクティビティがありました。この 2 つのアクティビティにより、ユーザーエクスペリエンスに問題が発生しました。画面を開いてホームページに入るときに、ローエンドマシンでは明らかに遅れが生じました。はすぐには表示されず、ユーザーはホームページのデータを最初から読み込みます。

画面開始フェーズのほとんどのシーンには、画面開始広告とホームページを 1 つのアクティビティに結合します。画面開始広告フェーズを使用して、画面開始ページの下にホームページを読み込み、ホームページデータと UI を分離します。この段階を最大化することで、起動画面の最後にすぐにホームページが表示され、ローエンドマシンでの遅延が大幅に改善されます。

ホームページのレンダリングも、画面広告の開始に一定の影響を与えます。広告のカウントダウン表示が不安定で、一部の広告のエフェクトがスムーズではありません。ホームページの読み込みは、広告のコールバックをトリガーする問題を解決するために、多くのステップに分割されています。カウントダウン表示では、安定性を確保するために surfaceView レンダリングが使用されます。

タスクスケジュールの最適化

スタートアップの種類に基づいて、ユーザーができるだけ早く目的のページを確認できるように、スタートアップフェーズでのタスクの実行順序を進める、遅らせる、または実行しないように調整します。以下は、ローエンドマシンの通常の起動パスにあるタスクに対して iQiyi によって行われた調整です。

ロック競合を解決する

ネイティブライブラリのロードロックの競合: C 層のライブラリのロードがロックされています。Java 層は、C 層に到達した後も、Lib ライブラリをロードするために複数のスレッドを開きます。これにより、Java 層のスレッドがブロックされます。そして待ってください。 iQIYI は、アプリケーションステージで Lib ライブラリをロードする必要があり、メインスレッドがロードの完了を待った後、再生モジュールが外部目的で再生ページをプルアップする状況が発生したときに、関連する JNI メソッドを呼び出す必要があります。再生をプリロードする必要があります。関連する Lib ライブラリが必要です。これにより、メインスレッドが待機状態になります。起動フェーズでターゲットのランディングページを特定することで、再生関連の Lib ライブラリのプリロードを実行するかどうかを決定できるため、通常はホームページにアクセスし始めるほとんどのユーザーの遅延を回避できます。 (テスト機 Redmi K40、Android12系)

リソースロックの競合: iQiyi ホームページが表示される前に、他のモジュールがサブスレッドにレイアウトファイルをプリロードするため、LayoutInfalter / ResourceManager / AssertsManager レイヤーロックの激しい競合が発生します。ホームページの表示後にレイアウトをプリロードするタスクを実行するようにスケジュールし、プリロードされたレイアウトが同じサブスレッドで実行されるように制限することで、改善後はロック競合の数が大幅に減少していることがわかります。ホームページの表示が速くなります。

ベースラインプロファイル

ベースラインプロファイル: Google は 2022 年にベースラインプロファイルを開始し、開発者がカスタマイズされたホットスポットコードのベースラインプロファイルを APK に構築できるようにします。 APP のインストール中、システムは構成ファイルを通じて事前にホットスポットコードをプリコンパイルします。ランタイムに含まれるコードパスの解釈とジャストインタイムコンパイルの手順をスキップして、最初の起動コードの実行速度を向上させることができます。

スタートアッププロファイル:スタートアッププロファイルは、前述のベースラインプロファイルのサブセットです。スタートアッププロファイルを使用すると、APK の DEX ファイル内のコードレイアウトが改善され、含まれるクラスとメソッドがさらに最適化されます。 iQiyi APP は、起動構成ファイルを通じて起動フェーズコードを同じ DEX ファイルに構築します。上記の 2 つの戦略を使用すると、一部のモデルでの iQiyi APP の最初の起動速度が約 10% 向上します。

外部リンク起動の最適化

外部リンクの取得も重要な開始方法です。これは通常、H5、共有、サードパーティ APP などによって開始されます。通常のコールドスタートとの違いは、外部リンクがホームページではなく、特定のターゲットであることが多いことです。ページ。 iQiyi の最も一般的なシナリオは、事前にランディングページ (アプリケーション段階) を特定しておけば、外部リンクがプレイページをプルアップするときに、ランディングページのタスクの優先順位を調整できます。事前に再生ページを特定し、それにプレーヤーを関連付けます。タスクは事前に初期化されます。この戦略により、ローエンドのオンボード外部リンクはブロードキャストを約 1.5 秒高速化できます。

流暢さの最適化

関連紹介

iQiyi APP のほとんどのページは、自社開発の Card フレームワークに基づいて開発されています。カードフレームワークは、再利用性の高い UI フレームワークであり、ネイティブコードを使用して基本的な UI レイアウトとビジネスロジックを実装することに基づいて、バックエンドによって発行される CSS コントロールによって基本的なコンテナスタイルが制御され、ページブロック全体と動的な再利用が実現されます。コンテンツスタイルの微調整。これは、ページ全体の再利用と両端 (Android と IOS) でのローカル微調整を実現するためのソリューションです。このフレームワークに基づいて、アプリ内のページの滑らかさが最適化されています。カードフレームワークには次の機能があります。

高い再利用性:コンテンツブロック (ブロック) はコントロールで構成され、行は複数のブロックで構成され、カードは複数の行で構成され、リストページ全体は複数のカードで構成されます。再利用可能なビジネスの最小単位はブロックです。
非常に動的:バックグラウンドでの CSS ファイルの構成と、特定の UI のスタイル (テキストサイズ、色、丸い角など) の動的変更をサポートします。

最適化の実践

スタイルネイティブ

カードページのダイナミクスと再利用性により、UI のレイアウトが複雑になります。ブロックのタイプは、複数のスタイルと互換性がある必要があります。たとえば、画像の 4 隅にさまざまなタイプの添え字ロジックを埋め込む必要があります。添え字タイプには、純粋な画像、プレーンテキスト、画像 + テキスト、およびオプションの選択が含まれます。中型。さまざまなスタイルを実装すると、多数のビューと深いネストレベルが発生し、一部のページがローエンドマシンでスライドするのに十分スムーズではなくなります。

この状況を最適化するために、ビジネス形式が安定しているカードをいくつか選択し、それらのカードのスタイルを固定し、レイアウトを大幅に合理化しました。これにより、上下にスライドする際のフレームレートが大幅に向上します。たとえば、ウォーターフォールフローカードでは、実装されたビューの数を 40 以上から 17 に減らし、さまざまなローエンドマシンでレイアウトレベルを 6 から 2 レイヤーに減らしました。これにより、約10% から 20% のスライディングフレームがもたらされました。レートが増加しました。

マージ図面を表示する

上記のレイアウト簡素化戦略による改善効果は明らかですが、ビジネス形態の多様化により、必要なビューの一部を削除できない場合があります。ビューの数とレベルをさらに減らすために、一般的に使用されるブロックレイアウト内の複数のビューがカスタムビューにマージされ、ビューのキャンバスを使用してテキスト、ピクチャ、ボタン、その他のスタイル情報が描画されます。この方法では、ビューとネストレベルの数を効果的に減らすことができますが、それでもクリックイベントと各要素のプレス効果を処理する必要があります。ローエンドマシンでは、この戦略によりフレームレートが約 1 ～ 2fps増加します。

事前作成と非同期読み込み

レイアウトの事前作成：上図で紹介した3種類のカードのうち、同じブロックタイプを使用しています（上図と下図）。これらの一般的に使用され再利用性の高いブロックレイアウトは、起動フェーズ中にキャッシュプールにプリロードされるため、事前に作成されたレイアウトをリストスライドで直接使用できるため、UI 描画のインフレート時間が短縮されます。

レイアウトの非同期作成: 事前作成は一般的に使用されるレイアウトに良い効果をもたらしますが、依然として一般的ではないレイアウトが大部分を占めます。このタイプのレイアウトでは、スクロールプロセス中に表示されるレイアウトを非同期的に作成し、レイアウトの作成時間を短縮します。 UI スレッドのスクロールレイアウトと同時に、RecyclerView のプリフェッチの効率も向上します。

RecyclerView のプリフェッチ:多くの iQiyi APP ページは、ネストされた RecyclerView を使用して、水平スクロールの製品フォームを作成します。このフォームのほとんどのカードは、さまざまなカウント (setInitialPrefetchItemCount、デフォルトは 2) に応じて 3 ～ 5 個の項目を表示します。このタイプのカードが露出されている場合の遅延を軽減できます。

メインスレッドにより非UIタスクの実行が削減される: スクロールプロセス中にメインスレッドを検出するのに時間がかかり、一部の非描画タスクがメインスレッドで実行されることがわかります。などを作成し、それらを非同期タスクに入れて実行します。

コールドスタート UI メッセージのスケジュール設定

ローエンドマシンのコールドスタートプロセス中、リソース消費は徐々にピーク状態に達します。実行する必要がある UI メッセージ (UI スレッドで実行する必要がある) やその他のバックグラウンドタスクが多数あります。インターセプトと埋め込みポイントの分析を通じて、この段階では 4,000 を超えるメッセージ (15 秒以内) を UI スレッドで実行する必要があります。これらのメッセージの実行時間は、ローエンドマシンでは 1 ミリ秒から 150 ミリ秒の範囲です。これらのメッセージが実行されると、システムの UI レンダリングメッセージが遅延し、ユーザーはアプリの最初の起動時にスライドラグやクリック応答の遅さなどの問題に直面します。

この問題に対処するための解決策は、UI スレッドに送信されたすべてのメッセージをインターセプトしてカスタムメッセージキューに追加し、システム UI メッセージキューがアイドル状態かどうかを監視し、アイドル状態の場合はカスタムキューからメッセージを取り出してリダイレクトすることです。さらに、一部の高品質メッセージをリリースするためにホワイトリストメカニズムが追加されます。例外を処理するためのフォールバックメカニズムがあります。

UI メッセージをスケジュールすることにより、コールドスタートフェーズ中のローエンドマシンの遅延が大幅に改善され、オンラインビッグデータモニタリングを通じて、フリーズフレームとドロップフレームの数が大幅に減少しました。コールドスタート段階では、フレームレートが約 8fps 増加します。

パフォーマンス低下戦略

ローエンドマシンでは、一部のエフェクトをダウングレードすると、特定のシナリオでの遅延を効果的に軽減できます。iQiyi APP は次のダウングレード戦略を実装しています。

モーションエフェクトのダウングレード: 上部および下部のナビゲーションモーションエフェクトが静止画像にダウングレードされ、再生コントロールモーションエフェクトがオフになり、一部の製品機能でモーションエフェクトが簡略化されます。

再生のダウングレード: ローリング遅延再生や一部のシーンを開始しないなどの戦略。

ViewPager のプリロードダウングレード: 左右のタブのプリロードを無効にし、ビューの描画時間とメモリオーバーヘッドを削減します。

画像のダウングレード: 一部のページアニメーションが再生されず、画像は 565 ピクセル形式を使用します。

読み込み速度の最適化

関連紹介

前述の起動時の最適化に加えて、いくつかの重要なページの最適化にも重点を置いています。これらのページはユーザーが非常に頻繁にアクセスするものであり、その最適化によってユーザーエクスペリエンスが大幅に向上するためです。たとえば、検索はユーザーが頻繁に使用する機能の 1 つであるため、検索の動作を注意深く分析し、検索の各ステップを最適化しました。

最適化の実践

事前リクエスト

通常、ページのレンダリングプロセスはアクティビティの onCreate メソッドから開始されます。次に、ネットワーク要求を行って必要なデータを取得します。特定のデータを取得した後、以前の検索シナリオでもこのプロセスに従いました。

必要なデータを事前に入手することはできますか？

実際、ユーザーがホームページの検索ボックスをクリックすると、ネットワークリクエストに必要なパラメータがすでに揃っています。これにより、クリック時にネットワークリクエストを事前に開始することができ、ネットワークリクエストとページジャンプが同時に実行されるため、ネットワークリクエストの時間が短縮されます。マシンのパフォーマンスが低下すると、ページをクリックして onCreate メソッドに到達するまでの時間が長くなり、最適化にかかる時間が長くなります。ローエンドマシンでの検証時間は約 200 ミリ秒短縮されます。

一括発行

ユーザーがページに入ると、最初の画面のデータのみが表示され、ページ下部のデータはユーザーがスライド操作するまで表示されません。そのため、ファーストスクリーンデータの確実な表示を優先し、ファーストデータ配信のサイズを小さくすることで、データ取得、データ送信、データ解析にかかる時間を短縮します。最初の画面データのレンダリングが完了した後、ユーザーがスライド操作を実行したときに後続のデータがすぐに表示されるようにするために、インターフェイスリクエストを再度開始します。このソリューションは、ホームページ、ハーフプレイページ、検索などの多くの主要なページの最適化に使用されます。たとえば、このソリューションを検索シナリオで使用すると、検証時間が約 200 ミリ秒短縮されます。

事前に作成された

レイアウトの事前作成: 検索中間ページがアイドル状態の場合、ページが実際にレンダリングされるときに、事前に作成されたレイアウトがビューのインフレートの時間を回避するために、事前にキャッシュに作成されます。

フラグメントの事前作成: 検索中間ページがアイドル状態の場合、結果ページのフラグメントコンテナーが事前に作成されます。結果ページが表示されるときに、対応するコンテナーを作成する必要がなく、コンテナーの作成に必要な時間が短縮されます。

メインスレッドの最適化

ページがロードされるとき、そのページに関連するメインスレッドのタスクができるだけ最初に実行されることが望まれます。重要なタスクのスケジューリングが優先されると、ページのレンダリング効果が影響を受けます。メインスレッドの Looper.loop() を引き継ぐ内部の自己開発 Tracepeed ツールを通じて、メインスレッド内の時間のかかるタスクを発見できます。時間がかかる優先度の低いタスクが最初に実行されることがわかった場合は、重要なタスクが最初に実行されるようにタスクのスケジュールを調整できます。

たとえば、検索結果ページの読み込みプロセス中、画像の読み込みは重要なタスクです。ただし、ローエンドマシンでは、場合によっては別のタスクがメインスレッドをプリエンプトし、画像の読み込みに最大 1 秒かかることがあります。このシナリオでは、イメージ読み込みタスクが最初に実行されるようにタスクのスケジュールを調整し、消費時間が 100 ミリ秒以上に安定します。

ビジネスロジックの最適化

さまざまなビジネスについて、特定のビジネスロジックも分析し、関連するロジックを最適化しました。

空の画像の最適化: 一部のシナリオでは、選択内容が読み込まれると、バックエンドが空の画像を配信し、この空の画像も読み込まれるため、ページの読み込み時間が増加します。そのため、空の画像の読み込みを制限します。
高周波ロジックの最適化: 最適化する際、高周波メソッドに注目する必要があります。一般的に使用されるいくつかの高周波メソッドを最適化することで、各ページの消費時間を最適化できます。たとえば、基本的な制御の初期化では、無駄なメソッドの実行が回避され、そのような高頻度のメソッドの時間が削減されます。
時間のかかるメソッドの非同期実行: ページの読み込みプロセス中に、優先度の低いビジネスロジックも存在します。これらのロジックが検出されると、非同期フレームワークを通じて実行できるため、ページの読み込み時間が短縮されます。

劣化防止

継続的な最適化の後、ページの読み込み時間は安定したレベルに達しました。ただし、進行中の開発反復中に、時間の消費が若干増加していることに気づきました。この種の劣化の発生を効果的に防ぐにはどうすればよいでしょうか?

主要なメソッドをコードに埋め込むことで、パイプラインタスクが毎日定期的に実行され、複数回の実行後に平均値が計算されます。視覚的な方法を使用して、ページ読み込みの変動を検出します。劣化がある場合、タスクの比較により2つのタスクの時間差を直感的に把握し、時間差を分析して最適化することができます。

概要と展望

ローエンドマシンの最適化には、さまざまな側面が含まれます。いくつかの主要なビジネスシナリオで紹介した最適化手法には、主要なパフォーマンス問題を優先し、ローエンドマシンの動作パフォーマンスを効果的に向上させるものがあります。その中には、ツール分析、オンラインモニタリング、測定基準などがあります。ここでは説明しませんが、これらもパフォーマンスを最適化するための重要なツールです。Android は断片化が深刻で、ローエンドの携帯電話を最適化するまでの道のりは長いです。今後も最適化のブレークスルーポイントを磨き続け、技術革新により安定的かつスムーズなユーザーエクスペリエンスをユーザーに提供し、質の高い成長を推進してまいります。

この記事は、WeChat パブリックアカウント - iQIYI テクノロジー製品チーム (iQIYI-TP) から共有されたものです。
侵害がある場合は、削除について [email protected] までご連絡ください。
この記事は「OSC ソース作成計画」に参加していますので、読んでいる方もぜひ参加して共有してください。