FPSおよびコードを待機させます

こんにちは、Habrの読者の皆さん。 この記事は、フロントエンド、JavaScript、およびFPSに関するものです。 そして今日は、「ブラインド」コードに関する私の考えを共有したいと思います。これは実際にはランタイム環境のパフォーマンスを考慮していません。 そして、もちろん、別のサイクリングバイクを作成します。

まえがき

最近のGeektimesの記事がありました- 「MozillaはクライアントPCのハードウェア統計をリリースしました 。 」 そして、主な問題を表現するschetilinからの素晴らしいコメント-

私たちのサイト作成者がこれらの統計を見ることを望みます。 そして今、彼らはi7 32Gbでは不十分なサイトを作成しています。

また、 「伝統的なJavaScriptベンチマークに関する真実」という記事も取り上げられました。 その本質は、オウムはオウムの比較には適していますが、実際の使用には適していません。

何とか何とか...

状況を想像してみてください-スーパー開発者のVasyaが座って彼のクールなコードを作成し、同様にクールな「ポピー」で起動します。 そして...サイトはうまく機能し、アニメーションは美しく、スクロールは高速でスムーズです。



しかし、ユーザーのPetyaはラップトップに座って、Vasyaがコードを書いているオンラインストアのWebサイトにアクセスすることにしました。 そして...それは始まりました-アニメーション化されたギャラリー、バナー、ポップアップ、およびサーバーからのデータの解析の腸内のどこかが起動されます。 これらすべてには、待機アイコンが定期的に表示されます。 Petyaのラップトップはショック状態にあり、Petya自身が不在でVasyaを呪い始めました。 誰が「極度」であるかを把握しましょう。



「Petyaは上級ユーザーです。ハードウェアを更新してください」とあなたは言います。 しかし、ユーザーは各サイトに適応する必要はありません。高品質のインターフェースを提供するのはサイトのビジネスです。



「Vasyaは悪い開発者です！」-あなたは言います。 そして無駄に、Vasyaは自分のコードを最適化するために最善を尽くしていますが、すべてのプラットフォームで鉄のすべての構成をテストすることはできません。 そして、ここではブラウザ開発者に質問があります。なぜ、JSコードが実行されるシステムのパフォーマンスに関する少なくともいくつかの情報をWeb開発者に提供しないのですか。 たとえば、ユーザーがどのブラウザを使用しているかを知ることができますか？ これにより、開発者はどの構文とAPIを使用できるかを知ることができます。 また、これは、たとえばリソースを大量に消費するタスクを複数の部分に分割するときにタイムアウトを選択する場合に役立ちます。 ブラウザ/エンジンの各バージョン、オペレーティングシステムおよびハードウェア構成ごとに、最適なタイムアウトは異なります。



Web開発者が、OSの種類とハードウェア構成を考慮した少なくともおおよそのパフォーマンスインデックスを持っていると想像してください。 次に、10のうち2のインデックスを使用すると、すべてのアニメーションを完全にオフにすることができ、逆の場合は、10で最大限に使用します。 まあ、各インデックスの典型的なタスク（テーブルに100行を挿入するなど）の実行時間を含む統計テーブルがあると便利です。 しかし、私が知る限り、この種のものはありません。

カウンター

さて、コードが実行されるシステムのパフォーマンスに関する直接的なデータはありません。 しかし、FPS（フレーム/秒）-優れた間接的な指標があります。 高FPSは、ユーザーが快適なナビゲーションに必要なものであり、これは開発者が測定できるものです。 そして、測定できる場合は、いくつかの条件でこのメトリックを使用できます。 さあ、先に進みましょう...



ヘルプ：

FPSは、モニター画面上の1秒あたりのフレーム数です。 ブラウザーの場合、これはブラウザーがインターフェースを更新するときの1秒あたりの回数です。



一般に、ブラウザでのレンダリングプロセスはそれほど単純ではありません。 ブラウザはページ全体を再描画しないようにし、ページをレイヤーとすべての束に分割します。悪魔は何を知っています。 このプロセスのジャングルに登ると、今では意味がなく、レンダリングアルゴリズムはバージョンによって異なる場合があります。 原則として、覚えておく必要があります、1つのルール-DOM要素に頻繁にアクセスする場合は、メイン構造からそれを引き出す必要があります。 固定または絶対配置します。

したがって、FPSを測定する必要があります。 ブラウザが1秒間に約60回インターフェースを更新しようとすることが知られています（つまり、理想的なFPSは60です）。 また、次にインターフェイスを再描画する前にコードの実行をスケジュールできるrequestAnimationFrame（）メソッドがあります。 このメソッドは、システムの負荷を増加させる強制再描画を引き起こす可能性があるsetTimeout / setIntervalの代わりに、すべてのアニメーションに強く推奨されます。



FPSカウンターを記述します。

let frameCount = function _fc(timeStart){ let now = performance.now(); let duration = now - timeStart; if(duration < 1000){ _fc.counter++; } else { _fc.fps = _fc.counter; _fc.counter = 0; timeStart = now; console.log(_fc.fps); } requestAnimationFrame(() => frameCount(timeStart)); } frameCount.counter = 0; frameCount.fps = 0; frameCount(performance.now())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カウンターは、これがコンソールで確認できると考えています。 しかし、それは数秒で動作し、コードははるかに高速に実行されます-単位とミリ秒の小数部。 たとえば、カウント期間を100ミリ秒に最小化してみましょう。 もちろん、これは必然的に精度を低下させますが、速度の増加は10倍にもなります。



高速FPSカウンター：

 let frameCount = function _fc(timeStart){ let now = performance.now(); let duration = now - timeStart; if(duration < 100){ _fc.counter++; } else { _fc.fps = _fc.counter * 10; _fc.counter = 0; timeStart = now; console.log(_fc.fps); } requestAnimationFrame(() => frameCount(timeStart)); } frameCount.counter = 0; frameCount.fps = 0; frameCount(performance.now())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それは私に気づきました-なぜ両方のカウンターを使用しないのですか。 これにより、特定のカウンタシステムが得られます。1つは高速でもう1つは正確です。 見てみましょう...

 let frameCount = function _fc(fastTimeStart, preciseTimeStart){ let now = performance.now(); let fastDuration = now - (fastTimeStart || _fc.startTime); let preciseDuration = now - (preciseTimeStart || _fc.startTime); if(fastDuration < 100){ _fc.fastCounter++; } else { _fc.fastFPS = _fc.fastCounter * 10; _fc.fastCounter = 0; fastTimeStart = now; console.log(_fc.fastFPS); } if(preciseDuration < 1000){ _fc.preciseCounter++; } else { _fc.preciseFPS = _fc.preciseCounter; _fc.preciseCounter = 0; preciseTimeStart = now; console.log(_fc.preciseFPS); } requestAnimationFrame(() => frameCount(fastTimeStart, preciseTimeStart)); } frameCount.fastCounter = 0; frameCount.fastFPS = 0; frameCount.preciseCounter = 0; frameCount.preciseFPS = 0; frameCount.startTime = performance.now(); frameCount()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、少なくとも何らかの形で実行環境の現在の状態を評価できます。 しかし、すべて同じように、私はすべてが終わっていなかったという感覚を残しませんでした。 そして再び私は実験することにしました...







この図は、カウンターのリセットに1つのメジャー（フレーム）を費やし、実際のカウントは次のメジャーから開始することを示しています。 カウント時間を短縮すると、カウンターはリセットされません。 また、FPSのカウント速度がわずかに向上します。 カウント期間の新しい値は、高速カウンターでは（100/6）* 5 = 83 、正確なカウンターでは（1000/60）* 59 = 983と定義されています。

タイムアウト

ガイドの対象となるメトリックが抽出されました。 ここで、コードの実行時間を制御するメカニズムが必要です。 そして、タイムアウトやデルタなどのパラメーターが必要なので、タイムアウトの量が変わります。 しかし、これらのパラメーターの最適値をどのように決定するのかという疑問がすぐに生じます。 答えは簡単です-すぐに、方法はありません。 データが必要であり、統計が必要です。 タイムアウト制御メカニズム自体は非常に定義可能ですが。 それは非常に簡単です：

 timeoutCorrection(){ if(fastFPS <= 2 && timeout < 1000){ timeout += delta; } else if(fastFPS > 2 && timeout > 16) { timeout -= delta; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードから、参照が20 FPS （fastFPS * 10）の値、またはもう少し-" <= "の値になることがわかります。 16および1000の値は制限です。 最小タイムアウトは16で、60 FPSに対応します。 また、1 FPSに対応する最大値の1000が選択されます。



高速FPSカウンターの新しい値が設定されるたびに、タイムアウト調整機能が呼び出されることが想定されています。

出演者

FPSが測定され、タイムアウトが制御されます。 ここで、エグゼキュータが必要です-このデータに基づいて、コードの実行を制御するか、必要に応じて呼び出しを遅くするだけの関数です。 私たちは書いています...

 let requestAdaptiveAnimation = function _raa(cb, priority, timeout, ...args){ if( !_raa.cbsStore.has(cb) || timeout){ _raa.cbsStore.add(cb); _raa.queue = _raa.queue.then(()=>{ return new Promise((res)=>{ setTimeout(()=>{ requestAnimationFrame(()=>{ cb(...args); res(); }); }, timeout || 0); }); }); return; } if(frameCount.fastFPS >= 4 || priority){ requestAnimationFrame(()=>cb(...args)); return; } if( frameCount.preciseFPS < 15){ _raa.queue = _raa.queue.then(()=>{ return new Promise((res)=>{ requestAnimationFrame(()=>{ cb(...args); res(); }); }); }); return; } setTimeout(()=>{ requestAnimationFrame(()=>cb(...args)); }, _raa.timeout); } requestAdaptiveAnimation.cbsStore = new Set(); requestAdaptiveAnimation.queue = Promise.resolve();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数は、このメソッドの基礎であるため、 requestAnimationFrameに似た意図的な名前が付けられています。 つまり requestAnimationFrameを介して行うインターフェースの更新。 ただし、このメソッドを使用してタイムアウトを設定することはできないため、setTimeoutを使用してラッパーを作成します。



Promiseのチェーンに基づいて、非同期キューが編成されます。これは、まずタイムアウトを設定できるようにし、次に「アバランシェ」コードの実行を防止します。



requestAdaptiveAnimationアルゴリズムは次のとおりです。

• 送信されたコールバックが初めて使用されるか、タイムアウトが指定された場合、コールバックの実行は汎用キューに入れられます。
• アニメーションで、同じコールバックが複数回呼び出された場合、高速FPSカウンターの値が高い場合、直接requestAnimationFrameが呼び出されます。
• 正確なFPSカウンターの値がクリティカルしきい値15を下回ると、コールバックはキューに入れられます。 視覚的には、一時的なフリーズアニメーションのように見えます。 数字の15は主観的に選択されていますが、私の意見では、スクロールページの値はまだ許容可能と呼ばれます。
  
  
• デフォルトでは、調整されたタイムアウトを通じてrequestAnimationFrameを呼び出します。

テスト

すべてをまとめてテストするときです。 さらに、タイムアウトとデルタを含む未解決のタスクがまだありました。 テストのために、私は小さなスタンドを書き、タイムアウトとデルタのさまざまな比率を調べ始めました。



最初に、タイムアウトとデルタをアニメーション化されたオブジェクトの数と相関させることにしました。 そして、私はそのような考慮事項がありました-要素が多いほど、開始タイムアウト値が大きくなり、それぞれデルタが小さくなります。そうでなければ、タイムアウトとアニメーションに強い変動があります。



したがって、計算は次のように削減されました。

 timeout = numberObjects; delta = 1/numberObjects;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、それはひどく機能し、私は補正係数- 比率を導入することにしました。 計算は次のように削減されました。

 timeout = numberObjects/ratio; delta = ratio/numberObjects;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はこの係数を変更し、チャートを見始めました。



100個のオブジェクト：







500個のオブジェクト：







1000個のオブジェクト：







2000個のオブジェクト：







このグラフは、FPSが15フレーム未満の「保存」キューメカニズムが含まれているという点で興味深いものです。



比較プレート：







プレート上で、最適なオプションを選択し、テストを続けます。



ここで少し明確にする必要があります。 実際、最初の呼び出しキューのために1000個の要素をアニメーション化するように指示していますが、同時にアニメーション化したのは300個以下です。これは、たとえば、300番目の要素のアニメーションが開始されたときに、最初の要素のアニメーションが既に終わっているためです。



外観は次のとおりです（約300個の要素）。







1000個のオブジェクト、短いアニメーション（表の最高のものの比較）：







次に、アニメーションの長さを増やし（ページを最大ズームしただけです）、もう一度テストします。



現在の外観（すべての要素は1000です）：







これで、すべての要素が同時にアニメーション化されていることがわかります。



1000個のオブジェクト、長いアニメーション（表の最高のものの比較）：







グラフは、キューの「保存」メカニズムが、 タイムアウト （要素/比率）およびデルタ （比率/要素）が1-グラフ上のピンクの線に等しい場合にのみオンにならないことを示しています。



そこで、タイムアウトとデルタを決定しました。 今こそ、ネイティブメソッドsetInterval 、 setTimeout 、 requestAnimationFrameと比較するときです。







グラフは、少数の要素で最小限のオーバーヘッドがあることを示しています。 適応メカニズムをオンにすると、もちろんコード実行の期間は長くなりますが、FPSはレベル30のままです。 ネイティブメソッドはFPSを7-8に引き下げます。



それがすべてのようでした。 しかし、いや、ラップトップですべてのテストを実行しました。この落書きの最初の目標は、さまざまな構成のさまざまなシステムで動作することでした。 そのため、デスクトップ上ですべて同じことを確認します。



短いアニメーションのネイティブメソッドとの比較：







長いアニメーションのネイティブメソッドとの比較：





ラップトップ（CPU：A8、RAM：8Gb）およびデスクトップ（CPU：i5、RAM：8Gb）で、メカニズムは同様に動作することがわかります-FPSは30に保たれます。唯一の違いは、コード実行が時間とともにどれだけ伸びるかです。

まとめ

良い：

• メカニズムは機能しており、FPSはシャットダウンされています
• ブラウザ（Firefox、Chrome）に関係なくFPSレベルを保存する
• システムパフォーマンスに関係なくFPSを維持する

悪い：

• さまざまなアニメーションの独立性。 このため、特定の条件下で後で実行されるアニメーションは早く終了する場合があります。

さて、これですべてです。 しかし、その奇妙な感じ...そして私は再び決めました...

PS

みんな、いい気分。 コメントと批判を歓迎します。 あなたが「マイナス」を入れた場合、唯一の要求は、何のために、何行かをドロップします。