web-dev-qa-db-ja.com

この過剰な「複合レイヤー」、「スタイルの再計算」、「レイヤーツリーの更新」サイクルの原因は何ですか。

「複合レイヤー」、「スタイルの再計算」、そしていずれかのWebアプリケーションの「レイヤーツリーの更新」イベントの数が多すぎることに非常に興味をそそられます。ここでそれらを引き起こしているのは何だろうと思います。

Chrome=動きの速いストリームの1つを指す場合は、 https://choir.io/player/beachmonks/github と言い、 "FPSメーター」を選択すると、アプリがほとんどの場合、上にいるときに約60 fpsを達成できることがわかります。

ただし、いくつかのメッセージを下にスクロールして画面をそのままにするとすぐに、FPSレートは約10以下に劇的に低下します。ここでコードが実行しているのは、各受信メッセージをレンダリングし、先頭に先頭に追加し、リストを新しいメッセージの高さであるNpxまで上にスクロールして、ビューポートの位置をそのまま維持することです。

(scrollTopは画面を無効にすることを理解していますが、レイアウトのスラッシングを回避するために操作を注意深く注文しました。また、毎秒発生する同期再描画も認識しています。これはjquery.sparklineが原因ですが、この説明には関係ありません。)

これをプロファイリングしようとしたときに表示されるのは次のとおりです。 low fps profiling result

大量のレイヤー操作の原因は何だと思いますか?

28
Alex Dong

CSSプロパティwill-change: transform再描画が必要なすべての要素で、複合レイヤーが多すぎるという問題が解決しました。

8
Anoian

同じ問題がありました。画像のサイズを小さくして修正しました。

スクロール可能なリストにいくつかのサムネイルがありました。各サムネイルのサイズは3000x1800でしたが、CSSによって62x44にサイズ変更されました。 62x44の画像を使用すると、「コンポジットレイヤー」にかかる時間が短縮されました。

2
Charles