HTML5 を使用して QQ スペースにダイナミック フォト アルバムを作成する例。私は it_html/css_WEB-ITnose を使用した経験が豊富です。

「ダイナミック アルバムについて聞いたことがありますか?」 ダイナミック アルバムは、QQ スペースで静止画像をダイナミック ビデオ アルバムに簡単に変換できます。キャリアは HTML5 (H5 と呼ばれます) ページです。いつでも自分のスペースや友達のサークルに共有して、友達が楽しめるようにすることができます。

モバイル版は、PC 時代のアルバムビデオとは異なり、デバイスのパフォーマンスの制限により、アニメーションの細部を慎重に最適化する必要があります。今日は、開発におけるアニメーションのパフォーマンスの検出と最適化の問題について説明します。ダイナミックアルバムのプロセス。

1. 最初にツールを使用します – Chrome タイムラインとレンダリング

パフォーマンス分析の前に、まずツールを見てみましょう。 Chrome ブラウザーが提供する 2 つのツールは、タイムラインとレンダリングです。タイムライン

タイムラインは、ブラウザーでの一連の操作を記録することにより、js 計算やページの再描画を含むプロセスのすべての詳細なデータを記録します。 、複合レイヤーの消費などを確認しながら、このプロセスの各フレームのスクリーンショットも保存します。

使用方法: Chrome デベロッパー ツールを開き、タイムラインを選択します。左上隅の小さなドットをクリックして操作を記録し、検出するページ上で一連の対話型操作を実行します。操作が完了したら、最後の操作中にもう一度ドットをクリックして一連のデータを停止します。パネルではチャートやその他の形式で提示されます。

4 つの色に対応する 4 つのイベントがあります。以下の図に示すように、ネットワークと DOM の解析 (青)、JavaScript の計算 (黄)、スタイルの再計算とレイアウト (紫)、および描画と合成 (緑) のイベントが表示されます。

フレームモード、イベントモード、メモリーモードの3つのモードがあります。

(1) フレームモード フレームモードをオンにするフレームビュー (棒グラフボタン) を選択する必要があります。このモードは、アニメーションのパフォーマンスをチェックするために最も一般的に使用されるモードです。

フレーム ビューアには 30fps と 60fps の 2 本の分割線があることに注意してください。

これには、fps (1 秒あたりのフレーム数) の概念を見直す必要があります。

つまり、スムーズさを確保するには、fps が 60 に近い必要があります。 ここをクリックすると、30fps と 60fps の明確な違いがわかります。フレーム モードのヒストグラムに戻ると、ヒストグラムの列の高さが小さいほど、アニメーションが滑らかになることがわかります。

同時に、ヒストグラムをクリックすると、CPU とメモリの詳細を確認したり、対応するスクリプトとノードの場所を見つけることもできます。

基本的な使い方:

(2) イベントモードとメモリーモード

イベントボタン (写真左側の青色) をクリックしてイベントモードをオンにする必要があります)、メモリ モードでは、フレーム モードまたはイベント モードを同時に表示するには、メモリ パネルをチェックするだけです。

イベント モードはイベント指向であり、記録室での操作のイベント プロセスを観察して、より頻繁なイベントを占める操作を見つけやすくします。同時に、メモリ パネルと組み合わせることで、どのイベントが最もメモリを消費しているか、ガベージ コレクション (GC) が適切に実行されているかどうかを確認できます。

また、ここで [スクリーンショット] パネルがチェックされていることにも注目してください。このパネルは、プロセス中にスクリーンショットを記録するため、パフォーマンス上の問題がある動作範囲を見つけて問題を発見することが容易になります。

レンダリング

レンダリングは開発者ツールの非表示パネルにあり、Chrome デベロッパー ツールを開き、ESC キーを押して開きます。

これには 4 つの機能があります:

2. 洞察力 – パフォーマンスの問題を見つける方法

上記のパフォーマンス分析ツールには、次のものがあります。アニメーションのパフォーマンスの問題を検出する方法について話しましょう。アニメーションのパフォーマンス分析では、主にタイムライン フレーム モード + レンダリングを使用して描画のちらつきをオンにし、階層境界線を表示します。

使用法 1: 遅延を確認します

フレーム モードをオンにし、記録ボタンをクリックしてページ操作の記録を開始し、記録を終了してヒストグラムを表示します。 60fps 未満の列が見つかった場合は、特定のフレーム レートの列をクリックしてレコードの詳細を表示し、以下に示すように左側の情報に基づいて問題を特定します。

使用法 2 : ビューの階層と冗長なレイアウト ブロック

適切に表示または非表示になっているブロックのレイヤーが多すぎることが原因である可能性があります。スクリーンショットのレンダリングは、機能パネルのペイント タブから有効にできます。

この機能をオンにした後、再度操作を記録すると、詳細データ パネルで各縦棒グラフのリアルタイム レンダリング スクリーンショットを確認できます。移動して検索するとどのブロックがあるかがわかります。そこには存在しないはずなので、削除してください。

使用法 3: 冗長ノードまたは繰り返しレンダリングされたノードを表示する

[ペイントの点滅を有効にする] と [レンダリングでレイヤー境界を表示する] をオンにします。ページを直接操作することで、操作中に予期しないブロックのレンダリングが発生するかどうかを確認できます (レンダリングされたノードが緑色の枠で表示されます)。問題がある場合は、冗長なノードを削除して再試行し、問題のあるノードを徐々に見つけます。 。

上記の 3 つの関数は、パフォーマンスに関する多くの問題を見つけるのに役立ちます。

3. Jianghu Deeds – ダイナミック アルバム パフォーマンス ケース

ここまで述べましたが、開発プロセス中の 3 つの簡単なパフォーマンス ケースを共有しましょう。

1. カバー拡散アニメーション

ダイナミック アルバムのカバー ページは、共通のページ フッターを使用します。アニメーションは非常にシンプルで、中央から両側に広がる円です。実装も非常に早いので、ボーダーを0pxから1000pxに変更すればPCでも問題なく表示できるので、これを思いつきました。

しかし、Xiaomi 2S で見たとき、前の要素を見ると、最後に非常にスタックしていることがわかり、すべてフェードアニメーションになっていました。それは不可能だったので、タイムラインツールを使用しました。それを分析してください。

緑がいっぱい！パフォーマンスの問題はペイント（レンダリング）が原因であると説明されているので、アニメーションが原因であることは間違いありません。同時に、ペイントパネルも確認しました。

非常に大きなレイヤー (緑色の部分) が描画されていることがわかり、背景の境界線に問題があることがわかりました。ノード。そこで、ノードのアニメーションを確認しました。

このノードの境界アニメーションが原因でしょうか?次に、別の書き方を試して、境界線の値を固定し、transform:scale でサイズを変更すると、同じ効果が得られます。

もう一度タイムラインを見てみませんか?

ああ!描画開始時の消費を除けば、それ以外の時間帯ではそれほど深刻な消費はなく、全体的な FPS は 60 以上を維持しており (非常にスムーズ)、レイヤーのサイズは自然に減少しています。

結論: 境界線アニメーションは、ローエンドのマシンではパフォーマンスの問題を引き起こす可能性があります。状況に応じて、代わりに他の方法を使用してください。

2. 前景拡大アニメーション

招待状テンプレートには、前景が小さいものから大きいものに変化するアニメーションがありますが、以下に示すように、Android マシンでは重大なレンダリング例外が発生します。

いつものようにタイムラインを確認したところ、IOS マシンでは再表示されませんでした。以上のような異常はなく、引き続きスムーズに演奏できることが分かりました。それで、何が問題なのでしょうか？

この領域のコードを確認しました。これは、アルバム間の写真切り替えエフェクトです。先ほどのエフェクトの最後に、.animate-b クラスが追加されます。このクラスにはフェード アニメーションがあり、.animate クラスを追加するだけで新しいページの再生が開始されます。これは、js を介して 2 つのクラスを制御し、異なる種類のアニメーションを切り替えることで実現されます。

それで、問題はここにあるのでしょうか?そこで、フェード アニメーションを削除し、再生後にページを直接非表示にしてアニメーションが再生されないようにしてから、フェードインせずに直接再生されるように新しいアニメーションを調整しました。

ついに、問題が解決されたことがわかりました。効果は図に示すとおりです。

結論: 背後にあるアニメーションが現在のアニメーションの再生に影響を与える可能性があります。Android 4.0 システムでは、レンダリング例外の問題が発生する可能性があります。現在再生されていないアニメーションは停止する必要があります。

3. Android のフレームごとのレンダリングのバグ

これ以上のパフォーマンスの問題は深刻なパフォーマンスを引き起こすことはなく、せいぜいわずかな遅延が発生する程度です。ただし、Android 4.0 ではレンダリング例外が頻繁に発生するため、これについては別の例を探します。以下は、ハロウィーンのアクティビティを行っているときに発見した問題です。具体的なパフォーマンスは写真に直接示されています。

これは Meizu のより優れたマシンですが、それでもフレームバイが発生します。フレームのレンダリングの問題。前の例に基づいて、最初に考えられるのは、他のアニメーションが影響を与えているかどうかです。このアニメーション機能には手を振り続けるアニメーションがあるのですが、振り終わった後、そのアニメーションがバックグラウンドでループ（無限）再生されて終わらないことが分かりました。

これしかないと思ったので削除しました:

結果は思った通りで、やっとページが滑らかになりました:

要約: パフォーマンス テストを実行する場合、問題を探すときにツールが役に立たない場合があります。問題が存在する可能性が非常に高くなります。コードはその背後で別の無関係な動作を実行しているため、問題が見つからない場合は、現在のページの上流と下流から始めるとよいでしょう。

4. 実践は完璧 – パフォーマンス最適化の経験とスキル

いくつかの具体的な操作方法について話しましたが、最後に開発プロセスで蓄積した経験について話しました。

1. 次の属性に対するより良い解決策

左側の属性はパフォーマンスの問題を引き起こす可能性があります。

2. アニメーションの落とし穴

兄弟要素間のアニメーションは相互に影響します

現在再生中のアニメーションは、まだアニメーション化されていない他のノードは影響を受け、Android マシンではフレームごとのレンダリングのパフォーマンスが表示されます。

解決策: 表示領域で再生されるアニメーションに加えて、その背後で再生されるアニメーションを display:none または anime-play-state:pause に設定します。

Z インデックスの設定が不適切です

兄弟要素が複合レイヤーでレンダリングされ、Z インデックスがメイン要素より小さい場合、メイン要素も複合レイヤーのレンダリングに追加されます。 この問題について述べた記事があります。

解決策: アニメーションに使用される兄弟要素に適切な Z インデックス値を設定します。

3. CSS アニメーションを上手に使う

これらは、CSS3 を使用して一般的な JS エフェクトを解決するいくつかの方法です。

4. GPU アクセラレーションが必要ですか?

最後に、この問題について議論しましょう。 GPU アクセラレーションをオンにすると、ページのアニメーションが確実にスムーズになりますが、すべての要素をオンにする必要があるということでしょうか?絶対にそうではありません。次のような欠点があります:

やみくもに使用すると、無関係な要素が複合レイヤーにレンダリングされます。

複合レイヤーをビットマップにレンダリングするとメモリが消費され、時間がかかります。

その結果、携帯電話のバッテリーの消費が早くなります。

GPU を使用する要素が多い場合、メモリの消費量がアニメーションの消費量よりもはるかに大きくなる可能性があり、これは少し本末転倒であることがわかります。したがって、アニメーション レイヤを適切に処理し、アニメーション レイヤを統合し、GPU アクセラレーションをオンにすることが最善の方法です。

元のリンク

この記事はインターネットからのものです。あなたの権利が侵害されている場合は、時間内に QQ: 123464386 にご連絡ください。できるだけ早く対応いたします。