背景
インターネット技術の継続的な革新とテレビ業界の急速な発展により、テレビを介してオンラインビデオを視聴することは、徐々に大衆にとって重要な娯楽方法になってきました。 Kiwi アプリは、テレビ デバイス上で最もユーザー アクティビティが多いアプリケーションの 1 つとして、ユーザーに豊富なコンテンツ再生サービスを提供します。また、メンバーシップの操作、特別なイベント、およびユーザーに非常に高いオンライン効率を必要とするその他のサービスも提供します。後者の要求を満たすために、現在主流のダイナミックおよびクロスエンド テクノロジである H5、Flutter、React Native を調査し、開発効率、人件費、ダイナミック機能およびパフォーマンスの観点から最終的に H5 ソリューションを選択しました。 H5 ページは、Kiwi アプリ内の多数のレジ係、運営活動、特別なトピック、その他のビジネスを処理します。ただし、私たちが直面している主な問題は、H5 ページが TV デバイスに読み込まれるのに時間がかかりすぎることです。TV デバイスでの H5 ページのユーザー エクスペリエンスを改善する方法は、緊急に解決する必要がある問題です。
直面する課題
課題 1:テレビ機器の買い替えサイクルが長く、システムの断片化問題が深刻 現在、テレビシステムのバージョンが 5.0 未満の機器が約 30% と非常に高い割合を占めています。最適化で最初に直面するのはバージョンの範囲であり、下位バージョンとの互換性が主な考慮事項です。次の図は、TV システムのバージョンの割合を示しています。
課題 2:テレビ機器の性能が低い テレビ機器は、主にテレビ、ボックス、プロジェクターの 3 つのタイプに分けられます。これらの機器の構成は、同時期の主流の携帯電話の構成よりも著しく低いです。分類では、CPU はコア A53 アーキテクチャの 4 A デバイスで、1.5G 以上のメモリは高性能デバイスとして分類できます。低パフォーマンスのデバイスの中には、A7 アーキテクチャのプロセッサまたは 512M のメモリを搭載したデバイスもまだ多くあります。
課題 3:現在の TV 業界の協力状況は複雑であるため、アプリのバージョンは大幅に細分化されており、従来の TV メーカーは安定性を追求しており、安価なデバイスが多数販売されています。販売後のメンテナンスはほぼ不要です。連携モデルの複雑さにより、カスタマイズが多くなり、アップグレードが難しくなり、SDK レベルでの最適化と起動に大きな課題が生じます。
最適化プロセス
1. 準備
最適化の前に最も重要な作業は、パフォーマンス基準を統一し、統計指標を策定することです。口径レベルでは、従来のフロントエンド ページの読み込み時間は考慮せず、ユーザーの実際のエクスペリエンスに沿ったシナリオを採用しました。つまり、ユーザーがボタンをクリックしてから実際のユーザーに表示されるまでの時間です。ユーザー。これにより、統計指標の全体的な消費時間が増加しますが、評価後は、この指標はその後の最適化作業の方向性により役立ちます。インジケーターの口径は次のように説明されています
1) ページが表示されるまでにかかる時間:クライアントのクリックから開始 -> クライアントのページジャンプ -> Web コンテナの初期化 -> フロントエンド DOM レンダリングが完了して表示されます。
2 ) 合計インタラクティブ時間: ページの表示時間 + ユーザーのリモコン ボタンに応答できる合計時間。
3) ネイティブ ページには時間がかかります。クライアント ページのジャンプには時間がかかります。
4) Webview の初期化: Web コンテナの初期化には時間がかかります。
5) h5 の呼び出しに時間がかかる: loadUrl から h5 までのコードの最初の行を実行するのに時間がかかります。
6) h5 のロードにかかる時間: h5 がコードの最初の行の実行を開始してからページに表示されるまでにかかる時間。
7) h5 がインタラクティブになるまでに時間がかかります。h5ページが表示され、ページが応答するまでに時間がかかります。
統計基準が統一された後、上記の時点をwebSDKレベルで配信し、オンラインデータを収集し、指標からフィードバックされた課題に基づいてターゲットを絞った最適化を実行します。最適化を行わないと、H5 の読み込み速度は平均約 5.5 秒となり、ユーザー エクスペリエンスは非常に劣ります。オンライン データ分析を通じて、H5 の読み込み時間が全体の大きな割合を占めているため、H5 の読み込み時間の最適化は早急に解決する必要がある課題です。
2. H5 ロード時間の最適化
H5 の読み込み時間は主にフロントエンド部分の最適化に依存します。記事の長さが限られているため、次のような従来の H5 ページ最適化作業については詳しく説明しません。
5) 同じアドレスの下で異なるモードでロードされる非同期ルーティング
3. SSRの最適化
上記の最適化に加えて、SSR（サーバーサイドプリレンダリング）技術が登場しました。SSRは、サーバー側で初期HTMLを生成することで、WebアプリケーションのパフォーマンスとSEOを最適化する技術です。検索エンジンのパフォーマンスとユーザーエクスペリエンス。適切なフレームワークを選択し、ルートを作成し、コンポーネントを作成し、サーバー構成とデータを取得することにより、開発者はサーバー側レンダリングを実装できるため、ユーザーに優れた Web アプリケーション エクスペリエンスを提供し、最初の画面のレンダリングを確実に高速化できます。
エンド側の処理圧力を軽減するこの方法は、TV エンド機器のパフォーマンスが低いシナリオに非常に適しています。 SSR には独自の欠点もあります。たとえば、ページの全体的な読み込み速度は向上しますが、ページの漸進的な読み込みには役立ちません。実験とオンライン データを繰り返し行った後でも、私たちは SSR の全体的な利点がプラスであると信じており、研究開発を開始しました。実験により、SSR ソリューションにより H5 ページの読み込み速度が大幅に向上することが証明されました。
SSR によって最適化された H5 ページの読み込みプロセスを次の図に示します。
上記のフロントエンド ソリューションを最適化した結果、各バージョンの読み込み速度が大幅に向上しました。 H5 レンダリング部分にかかる時間は平均 4 秒から 1.5 秒未満に短縮され、合計時間は約 3.5 秒に短縮されました。現時点では、純粋にフロントエンド視点で最適化し続けることがボトルネックとなり、入出力比率も低く、クライアント全体の視点で最適化方法を考え続ける必要があります。
4. リソースのオフライン キャッシュ
CDN はいくつかの主要な H5 リソース (css、js、png、ttf など) をデプロイします。その多くはフロントエンド バージョン サイクル中に変更されず、サイズが大きいため、クライアントは適切なタイミングでそれらを事前ダウンロードします。 。ページをレンダリングするときに、WebView カーネルの shouldInterceptRequest コールバックを使用して、オンライン H5 URL のロード要求をインターセプトできます。リソースがオフライン キャッシュに見つからない場合は、オンライン ネットワークを通じてロードされます。オフライン キャッシュで見つかった場合は、ローカル ディスクからリソースを直接読み込み、WebView に戻ります。この方法により、リソースの読み込み速度が大幅に向上します。
オフライン キャッシュ ソリューションの一般的なフローチャートは次のとおりです。
同時に、プロセス中に、下位バージョンの Android ネイティブ リクエスト ライブラリ HttpUrlConnection がまだ http1.0 の段階にあり、http2.0 の最適化 (チャネルの再利用など) を享受できないことがわかりました。プリロードに時間がかかります。現在、TV 側にはバージョン 5.0 未満の低バージョンのデバイスが多数存在するため、TV 側が独自に開発したネットワーク ライブラリに切り替えることにしました。このネットワーク ライブラリは http2.0 をサポートしており、これによりリクエストのパフォーマンスが向上します。バージョンの低いデバイス。さらに、ユーザーがクリックしてから H5 ページが開くまでには一定のシステム スケジュール時間があり、この時間は最適化、つまり後述する並列読み込みにも使用できることがわかります。
5. 並列ロード
JS/CSS やその他のリソースを事前にキャッシュするための上記のソリューションに加えて、HTML ページを事前にキャッシュすることも業界で一般的な最適化方法です。ページが SSR になる前は、このキャッシュ メカニズムは良い結果を達成できませんでした。パフォーマンスのボトルネックは HTML データのダウンロードではなく、レンダリング データが生成された後、このメソッドは理論的にはより大きな役割を果たすことができます。
しかし同時に、パーソナライズされたアルゴリズムがビジネスで広く使用されているため、ページを事前にキャッシュし、コンテンツを一定期間変更しないで保存するという方法は、ページを保持するというビジネス要件と矛盾することになりました。リアルタイムで更新されるデータの競合。そのためには、ビジネス シナリオにより適した最適化された技術ソリューションを見つける必要があります。
Android システムは、アクティビティのページ ジャンプ切り替えを行うときにシステム時間を消費します。この時間の消費は、ページ ジャンプの切り替え中にユーザーの Web ページをクリックをインターセプトして、事前にタスクを開始し、SSR を読み込みます。 H5 ページの並列データ。次に、URL と Cookie パラメータに基づいて一意のトークンが生成されます。実際に WebView をレンダリングするときが来たら、URL をキャッシュにリダイレクトします。同時に、マルチスレッド ロック同期およびタイムアウト メカニズムが使用され、H5 の読み込み速度がさらに向上します。
並列ロード ソリューションの一般的なフローチャートは次のとおりです。
これらの最適化が完了した後も、読み込み速度は引き続き 3.5 秒から約 2.8 秒に最適化され、約 23% 増加しました。前述の一連の最適化策により、H5 の読み込み時間は初期の平均 5.5 秒から約 2.8 秒に短縮されました。ただし、純粋なネイティブ (Native) ページと比較すると、読み込み速度には依然として大きな差があり、より効果的な最適化方法を引き続き模索する必要があります。ユーザーエクスペリエンスをさらに向上させるために、私たちはさまざまな技術的な試みを行い、他の技術チームとの積極的なコミュニケーションと協力を通じて新しいアイデアを生み出しました。
6. 容器の予熱
APP が開始され、メイン スレッドがアイドル状態のときに、WebView エンジンを予熱して WebView キャッシュ プールを構築すると、予熱されたコンテナーが再利用され、WebView の読み込み速度が向上します。この最適化戦略は主に、大容量メモリを搭載した中～高性能デバイスおよび低パフォーマンス デバイスを対象としています。デバイスがアイドル状態の場合、WebView コンテナーを予熱し、予熱されたコンテナーをキャッシュ プールに追加します。
その後の使用では、予熱された WebView コンテナを WebView キャッシュ プールから直接取得します。これにより、Web コンテナーと jscore の作成時間が節約されます。
7. ページのプリレンダリング
テレビ側の H5 には、多くのリアルタイム ビジネス シナリオの制限があり、特に時間に非常に敏感な運用活動がそのため、最適化に一定の制限が課せられます。ただし、カスタマイズおよび最適化できるシナリオがいくつか見つかりました。たとえば、非会員ユーザーが会員限定コンテンツを視聴する場合、通常は 6 分間の無料トライアル時間があり、トライアル時間が終了すると自動的にジャンプします。 H5まで。このタイプのシナリオでは、プリレンダリングに当然の利点が得られます。同様のシナリオでは、カウントダウンの開始時にプリレンダリングが自動的にトリガーされ、H5 コンテンツを事前にロードして、H5 のインスタント オープニング効果を実現できます。以下の GIF に示すように、上の図は最適化を行わないロード プロセスであり、明らかな黒い画面とロード プロセスがわかります。下の図は、プリレンダリングの最適化の結果であり、真の 2 秒間の起動を実現しています。
上記の最適化措置を完了し、昨年の同じ期間のデータを比較した後、オンライン データから、ロード時間が非 SSR シナリオの初期平均 5.5 秒、SSR シナリオの 3.5 秒からさらに短縮されたことがわかります。シナリオの実行時間が現在の平均 2 秒に短縮され、ユーザー エクスペリエンスが大幅に向上しました。
業績
最後に最適化に関するAB実験を行いました。分割して平均した後のテストデータでは、最適化対策により注文生成ページのコンバージョン率が平均約 21% 向上し、決済成功率のコンバージョン率も平均 2.4% 向上したことがわかりました。
主要なビジネス ページの読み込み速度とユーザー エクスペリエンスを向上させることは、ビジネスに非常に直接的なプラスの影響を与えることが実験によって証明されており、これは私たちに今後も最適化を推進し続ける十分な自信とモチベーションにもなります。
これからの計画
将来的には、パフォーマンス指標をさらに削減し、平均ページ時間を 2 秒未満に制御し、劣化を制御するためのより多くの方法を見つけたいと考えています。
さらに、平均データが実際のユーザー エクスペリエンスを完全に反映していないことにも気づきました。90 パーセンタイル以降もユーザーが遭遇する実際の状況を引き続き分析し、ターゲットを絞った最適化を実行します。同時に、レジカウンターなどの重要なビジネスシナリオに合わせてカスタマイズされた最適化を継続して実行し、主要ビジネスの読み込み速度をさらに向上させ、ユーザーエクスペリエンスとビジネスコンバージョンを継続的に向上させます。
この記事は、WeChat パブリック アカウント - iQIYI テクノロジー製品チーム (iQIYI-TP) から共有されたものです。
侵害がある場合は、削除について [email protected] までご連絡ください。
この記事は「OSC ソース作成計画」に参加していますので、読んでいる方もぜひ参加して共有してください。
