60fps 対 デバイスのリフレッシュ レート

作業する際に理解し、注意を払うべき主な領域が 5 つあります。これらは最も制御力があり、ピクセルから画面へのパイプラインの重要なポイントです:

• JavaScript。一般に、JavaScript は視覚的な変更を実現するために使用されます。たとえば、jQuery の animate 関数を使用して、アニメーションを作成したり、データ セットを並べ替えたり、いくつかの DOM 要素をページに追加したりできます。 JavaScript 以外にも、CSS アニメーション、トランジション、Web アニメーション API など、視覚的な変更を実現する一般的な方法があります。

• スタイル計算スタイル計算。これは、一致するセレクター (.headline や .nav > など) に基づいて、どの CSS ルールがどの要素に適用されるかを判断するプロセスであり、ルールがわかったら、それが適用され、各要素の最終的なスタイルが決定されます。

• レイアウトが計算されます。要素に適用されるルールがわかったら、ブラウザはその要素が占めるスペースの量と画面上の位置の計算を開始できます。 Web ページのレイアウト モードは、1 つの要素が他の要素に影響を与える可能性があることを意味します。たとえば、

  要素の幅は、ツリー内のすべての子要素とノードの幅に影響します。という処理が頻繁に発生します。

• 絵を描く。描画とはピクセルを埋めるプロセスです。これには、要素の目に見えるすべての部分を含む、テキスト、色、画像、境界線、影の描画が含まれます。描画は通常、複数のサーフェス (レイヤーと呼ばれることが多い) 上で行われます。

• 合成。ページの一部は複数のレイヤーに描画される場合があるため、ページを正しくレンダリングするには、正しい順序で画面に描画する必要があります。これは、別の要素と重なる要素の場合に特に重要です。間違えると、ある要素が別の要素の上に誤って表示される可能性があるためです。

パイプラインのあらゆる部分で不具合が発生する可能性があるため、コードがパイプラインのどの部分をトリガーするかを正確に知ることが重要です。

すべてのフレームが常にパイプラインのすべての部分を通過するわけではありません。実際、JavaScript、CSS、Web アニメーションのいずれを使用する場合でも、指定したフレームに対してパイプラインを実行するには、次の 3 つの方法があります。

1. ; 合成

要素の「レイアウト」属性を変更する場合、つまり要素の幾何学的プロパティ (幅、高さなど) を変更する場合、ブラウザは他のすべての要素をチェックする必要があります。次に、ページを「自動的にリフロー」します (ページをリフローします)。影響を受けるパーツは再ペイントする必要があり、最終的にペイントされた要素を合成する必要があります。

2. JS/CSS > 描画 > 合成

「ペイントのみ」のプロパティ (背景画像、テキストの色、影など) を変更する場合ページ レイアウトに影響を与えない場合、ブラウザはレイアウトをスキップしますが、描画は引き続き実行されます。

3. JS / CSS > スタイル > 合成

再レイアウトも再描画も必要としないプロパティを変更した場合、ブラウザは合成のみを実行します。この最後のアプローチはオーバーヘッドが最も少なく、アニメーションやスクロールなど、アプリケーションのライフサイクルにおけるストレスの高いポイントに最適です。

パフォーマンスとは、実行を回避し、実行する操作を可能な限り効率的にする技術です。 多くの場合、これにはブラウザに対してではなく、ブラウザとの連携が必要です。 上記のさまざまなパイプライン ジョブは計算オーバーヘッドが異なり、一部のタスクは他のタスクよりも高価であることに留意する価値があります。

JavaScript のパフォーマンス分析は芸術であると言えます。なぜなら、作成した JavaScript コードは、実際に実行されるコードとはまったく異なるからです。最新のブラウザは、JIT コンパイラとさまざまな最適化お​​よびトリックを使用して、可能な限り高速な実行を実現します。これにより、コードの動的な性質が大きく変わります。

アプリケーションが JavaScript を適切に実行するために役立ついくつかのこと:

• アニメーション効果の場合は、setTimeout または setInterval の使用を避け、requestAnimationFrame を使用してください。

• 長時間実行される JavaScript をメインスレッドから Web ワーカーに移動します。

• 小さなタスクを使用して、複数のフレームにわたって DOM 変更を実行します。

• Chrome DevTools のタイムラインと JavaScript プロファイラーを使用して、JavaScript の影響を評価します。

画面が視覚的に変化するときは、フレームの先頭で操作を実行するのが最善です。フレームの開始時に JavaScript が実行されることを保証する唯一の方法は、requestAnimationFrame を使用することです。

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame. */function updateScreen(time) {  // Make visual updates here.}
requestAnimationFrame(updateScreen);

フレームワークやサンプルでは、​​アニメーションなどの視覚的な変更を実行するために setTimeout または setInterval を使用することがありますが、このアプローチの問題は、コールバック関数がフレーム内の特定の時点 (おそらくフレームの最後) で実行されることです。これにより、フレームがドロップし、途切れが発生することがよくありました。 (コンポジットなどの js の実行には時間がかかり、UI の更新がブロックされます)。

実際、jQuery の現在のデフォルトのアニメーション動作は setTimeout を使用することです。requestAnimationFrame を使用するようにパッチを適用することを強くお勧めします。

JavaScript は、スタイルの計算、レイアウト、多くの場合描画とともにブラウザのメイン スレッドで実行されます。 JavaScript の実行時間が長すぎると、他の作業がブロックされ、フレーム落ちが発生する可能性があります。

したがって、JavaScript がいつ実行されるか、どのくらいの期間実行されるかを賢明に考慮してください。たとえば、スクロールなどのアニメーションを実行している場合、JavaScript を 3 ～ 4 ms の範囲内に保つ方法を見つけるのが最善です。これ以上の場合は時間がかかりすぎる可能性があります。時間が空いていれば、あまり時間を気にする必要はありません。

多くの場合、純粋な計算作業は Web ワーカーに移動できます。たとえば、DOM アクセス、データ操作、トラバース (並べ替えや検索など) を必要としないものは、読み込みやモデルの生成と同様に、このモデルによく適合します。 。

var dataSortWorker = new Worker("sort-worker.js?1.1.11");
dataSortWorker.postMesssage(dataToSort);// The main thread is now free to continue working on other things...dataSortWorker.addEventListener('message', function(evt) {   var sortedData = evt.data;   // Update data on screen...});

すべてのジョブがこのモデルに適しているわけではありません。Web ワーカーには DOM アクセス権がありません。操作をメイン スレッドで実行する必要がある場合は、大きなタスクを小さなタスクに分割し、それぞれのタスクにかかる時間は数ミリ秒以内で、フレームごとに requestAnimationFrame ハンドラー内で実行するバッチ アプローチを検討してください。

var taskList = breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);function processTaskList(taskStartTime) {  var taskFinishTime;  do {// Assume the next task is pushed onto a stack.var nextTask = taskList.pop();// Process nextTask.    processTask(nextTask);// Go again if there’s enough time to do the next task.taskFinishTime = window.performance.now();
  } while (taskFinishTime - taskStartTime < 3);  if (taskList.length > 0)
    requestAnimationFrame(processTaskList);
}

このアプローチは UX と UI に影響を及ぼします。タスクが処理されていることをユーザーが確実に認識できるように、進行状況またはアクティビティ インジケーターを使用する必要があります。いかなる状況でも、このメソッドはアプリケーションのメイン スレッドを拘束せず、メイン スレッドがユーザーの操作に対して常に迅速に応答できるようにします。

フレームワーク、ライブラリ、または独自のコードを評価するときは、JavaScript コードの実行のオーバーヘッドをフレームごとに必ず評価してください。これは、変換やスクロールなどのパフォーマンスが重要なアニメーション作業を実行する場合に特に重要です。

JavaScript のオーバーヘッドとパフォーマンスを測定する最良の方法は、Chrome DevTools を使用することです。通常、次のような単純なレコードが得られます。

メイン セクションには JavaScript 呼び出しのフレーム チャートが表示されるため、どの関数が呼び出されたか、それぞれにどれくらいの時間がかかったかを正確に分析できます

-JavaScript を実行すると、DevTools ユーザー インターフェイスの上部で JavaScript アナライザーを有効にすることができます:

この方法で JavaScript を分析するとオーバーヘッドが発生するため、JavaScript をより深く理解したい場合にのみ有効にしてください。ランタイム機能。このチェックボックスを有効にすると、同じアクションを実行できるようになり、JavaScript で呼び出される関数に関する詳細情報が得られます:

この情報を使用して、アプリケーションのパフォーマンスに対する JavaScript の影響を評価し、特定を開始できます。機能の実行に時間がかかりすぎるホットスポットを修正します。前に述べたように、長時間実行される JavaScript を削除するか、それが不可能な場合は Web ワーカーに移動して、メイン スレッドを解放して他のタスクの実行を継続する必要があります。

要素の offsetTop をリクエストする方が getBoundingClientRect() を計算するよりも速いなど、ブラウザーが関数のあるバージョンを別のバージョンより 100 倍高速に実行することを知るのは素晴らしいことかもしれませんが、フレームごとに呼び出しています。このような関数の程度はほとんどの場合小さいです。したがって、JavaScript のパフォーマンスのこの側面に焦点を当てることは、無駄な労力になることがよくあります。通常、節約できるのは 10 分の数ミリ秒だけです。

ゲームや計算量の多いアプリケーションを開発している場合は、一般的に 1 つのフレームに多くの計算を入れることになるため、このガイドの例外となる可能性があります。その場合、さまざまな方法が役立ちます。

つまり、マイクロ最適化は、構築しているアプリの種類に対応していないことが多いため、慎重に使用してください。 2/8 ルールに従って、最初にボトルネックから最適化を開始します。

スタイル計算の範囲と複雑さを絞り込みます

要素の追加や削除、プロパティやクラスの変更、またはアニメーションを通じて DOM を変更すると、ブラウザで要素のスタイルが再計算され、多くの場合、ページも変更されます。またはレイアウトされるページの一部（つまり、自動的にリフローされます）。このプロセスは計算されたスタイルと呼ばれます 計算。

スタイルを計算する最初の部分は、一致するセレクターのセットを作成することです。これは基本的に、ブラウザーが特定の要素に適用するクラス、疑似セレクター、ID を判断することです。

2 番目の部分では、一致するセレクターからすべてのスタイル ルールを取得し、この要素の最終的なスタイルを決定します。 Blink (Chrome と Opera のレンダリング エンジン) では、これらのプロセスのオーバーヘッドは、少なくとも現時点ではほぼ同じです:

以前は時間の約 50% 要素の計算されたスタイルの計算はセレクターの一致に使用され、残りの時間の半分は一致ルールから RenderStyle (計算されたスタイル表現) を構築するために使用されます。

• セレクターの複雑さを軽減します。BEM 仕様 (Block-Element_Modifer) などのクラス中心のアプローチを使用します。

• スタイルを計算する必要がある要素の数を減らします。

最も単純なケースでは、CSS には要素のクラスが 1 つだけあります:

.title {
/* styles */
}

ただし、プロジェクトが成長するにつれて、より複雑な CSS を作成できるようになり、最終的にはセレクターは次のようになります:

.box:nth-last-child(-n+1) .title {
/* スタイル */
}

スタイルを適用する必要があるかどうかを知るために、ブラウザは実際に「これは、まさに負の N 番目の子にボックス クラスを持つ 1 つの要素を加えたものを親とするタイトル クラスを持つ要素ですか?」と尋ねる必要があります。 " "使用するセレクタと対応するブラウザによっては、この結果の計算にかなりの時間がかかる場合があります。特定のセレクターをクラスに変更できます:

.final-box-title {
/* styles */
}

開発者はクラスの名前に問題があるかもしれませんが、ブラウザにとって作業ははるかに簡単です。以前のバージョンでは、要素がそのタイプの最後の要素であるかどうかを知るために、ブラウザはまず他の要素に関するすべてを知る必要があり、それに続く要素が N 番目の最後の子になるかどうかを知る必要がありました。これは、単純に一致させるよりも高速でした。要素へのクラスセレクターははるかに高価です。

レンダー ツリーを生成するときは、DOM 要素ごとに、一致するセレクターがすべてのスタイル ルールで見つかり、対応するスタイル ルールがマージされる必要があります。
CSS セレクターは右から左に解析されるため、共通のスタイルが CSSOM ツリーの親ノードに配置され、より具体的なスタイル (セレクターがより具体的) が子ノードに配置され、ノードの数が決まります。ブランチとトラバースが減少します。 CSS ルールを読み取るために左から右の方法を使用すると、ほとんどのルールが最後まで不一致であることがわかり、右から左の方法を使用している間に多くの無駄な作業が行われることになります。右端のセレクターが一致しないことが判明した場合に限り、一致するものがあれば、多くの無効な一致を避けるために直接破棄します。

パフォーマンスに関するもう 1 つの考慮事項、要素の変更時に計算する必要がある作業量は、多くのスタイル更新にとってより重要な要素です。

一般的に、計算されたスタイルを計算する最悪の場合のコストは、 要素は要素数とセレクター数を乗算したものです。 確認するには、各要素をすべてのスタイル ルールに対して少なくとも 1 回チェックする必要があります 一致する場合。

注: 以前は次のようでした: (たとえば) body 要素のクラスを変更した場合、ページのすべての子要素は計算されたスタイルを再計算する必要がありました。現在は少し異なります。変更時にスタイルが再計算される要素の場合、ブラウザによっては、そのような要素ごとに固有の小さなルール セットが維持されます。これは、ツリー内の要素の位置と変更された特定のプロパティによっては、要素を必ずしも再計算する必要がないことを意味します。

スタイル計算は、ページ全体を無効と宣言するのではなく、少数のターゲット要素に向けられることがよくあります。最近のブラウザでは、変更が影響する可能性のあるすべての要素を必ずしもチェックする必要がないため、これはあまり問題になりません。一方、古いブラウザは必ずしもそのようなタスクに対して最適化されているわけではありません。無効として宣言された要素の数は可能な限り減らす必要があります。

// Schedule our function to run at the start of the frame.requestAnimationFrame(logBoxHeight);function logBoxHeight() {  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
}

function logBoxHeight() {
  box.classList.add('super-big');    //样式更改后，浏览器必须先应用新的样式（重绘）之后才能获取当前的值，有时是多做无用功
  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
}

function logBoxHeight() {  // Gets the height of the box in pixels and logs it out.  console.log(box.offsetHeight);
  box.classList.add('super-big');
}

function resizeAllParagraphsToMatchBlockWidth() {  // Puts the browser into a read-write-read-write cycle.
  for (var i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = box.offsetWidth + 'px';
  }
}

// Read.var width = box.offsetWidth;function resizeAllParagraphsToMatchBlockWidth() {  for (var i = 0; i < paragraphs.length; i++) {// Now write.paragraphs[i].style.width = width + 'px';
  }
}