React: どのような状況で、unstable_shouldYieldはtrueを返しますか？

作成日 2019年02月08日  ·  4コメント  ·  ソース: facebook/react

Scheduler.jsでは、

function unstable_shouldYield() {
  return (
    !currentDidTimeout &&
    ((firstCallbackNode !== null &&
      firstCallbackNode.expirationTime < currentExpirationTime) ||
      shouldYieldToHost())
  );
}

現在のDidTimeoutがfalseの場合、unstable_shouldYield（）はtrueを返し、shouldYieldToHost（）はtrueを返しますが、なぜですか？

shouldYieldToHost = function() {
  return frameDeadline <= getCurrentTime();
};

shouldYieldToHost（）がtrueを返すということは、このアイドル期間に時間が残っていないことを意味します
currentDidTimeoutがfalseの場合、スケジュールがタイムアウトしていないことを意味します
それらの間にはどのような関係がありますか、unstable_shouldYield（）がそれらに依存するのはなぜですか？

Question
ソース
picture xilixjd

最も参考になるコメント

ブラウズがユーザー入力を含む着信イベントを処理できるように、定期的に（16ミリ秒ごとに）ホスト環境に譲ります。 frameDeadlineは、生成する予定のタイムスタンプ（元々はnow() + 16msようなものに設定されています）であるため、その時間が経過すると、shouldYieldToHostはtrueを返します。 次に、requestIdleCallbackとrequestAnimationFrameを組み合わせて使用​​し、次の作業をすぐに処理できるようにします。

理想的なケースでは、これらの小さな16msスライスですべてのレンダリングを終了できます。 ただし、同時に他の多くのことが起こっている場合、Reactの作業は「飢え」、小さなスライスで完全にレンダリングできない可能性があります。 したがって、2番目のチェックがあります。保留中のすべてのレンダリングまたは状態の更新には「有効期限」（通常は100ミリ秒から5000ミリ秒）があります。レンダリングが終了せずにその時間が経過すると、更新が完了するまで同期モードに切り替わります。 これは理想的ではありませんが、すべての更新が長く待たずに処理されることを保証します。

同じ有効期限のタイマーをブラウザーに設定します（たとえば、setTimeoutを使用）。 そのタイマーが起動した場合、作業を同期的に実行する必要があることがわかります。 これが発生した場合、 currentDidTimeoutはtrueに設定されるため、譲歩しません。

将来的には、新しいisInputPendingブラウザAPI（https://github.com/WICG/is-input-pending）を使用して、作業を続行し、新しいユーザー入力がある場合にのみ譲歩できるようにする予定です。 、常に16msごとに生成するのではなく。

picture sophiebits 2019年02月09日
👍6

全てのコメント4件

ブラウズがユーザー入力を含む着信イベントを処理できるように、定期的に（16ミリ秒ごとに）ホスト環境に譲ります。 frameDeadlineは、生成する予定のタイムスタンプ（元々はnow() + 16msようなものに設定されています）であるため、その時間が経過すると、shouldYieldToHostはtrueを返します。 次に、requestIdleCallbackとrequestAnimationFrameを組み合わせて使用​​し、次の作業をすぐに処理できるようにします。

理想的なケースでは、これらの小さな16msスライスですべてのレンダリングを終了できます。 ただし、同時に他の多くのことが起こっている場合、Reactの作業は「飢え」、小さなスライスで完全にレンダリングできない可能性があります。 したがって、2番目のチェックがあります。保留中のすべてのレンダリングまたは状態の更新には「有効期限」（通常は100ミリ秒から5000ミリ秒）があります。レンダリングが終了せずにその時間が経過すると、更新が完了するまで同期モードに切り替わります。 これは理想的ではありませんが、すべての更新が長く待たずに処理されることを保証します。

同じ有効期限のタイマーをブラウザーに設定します（たとえば、setTimeoutを使用）。 そのタイマーが起動した場合、作業を同期的に実行する必要があることがわかります。 これが発生した場合、 currentDidTimeoutはtrueに設定されるため、譲歩しません。

将来的には、新しいisInputPendingブラウザAPI（https://github.com/WICG/is-input-pending）を使用して、作業を続行し、新しいユーザー入力がある場合にのみ譲歩できるようにする予定です。 、常に16msごとに生成するのではなく。

sophiebits picture sophiebits 2019年02月09日
👍6

返信ありがとうございます
まだいくつか質問があります、

  1. unstable_shouldYield()は、スケジュールで作業を中断できるかどうかを表していると思いますが、それは正しいですか？
  2. 「16ms」はactiveFrameTime指しますか？
  3. firstCallbackNode.expirationTime < currentExpirationTimeいつtrueを返しますか？ 次の作品の優先順位が前の作品よりも高いということですか？
xilixjd picture xilixjd 2019年02月10日

  1. 各レンダリングタスクは、unstable_shouldYield（）を頻繁にチェックする必要があります。 （ツリー内の各コンポーネントの後に大まかに呼びます。）ほとんどの場合、falseを返します（つまり、続行します）が、trueを返すと、レンダリングを一時停止する必要があります。

  2. はい。

  3. 既存のレンダリング中に、より新しい、より優先度の高い作業がキューに入れられた場合、条件は真であると思います。 その場合、そのタスクに切り替えることができるようにtrueを返したいと思います。

sophiebits picture sophiebits 2019年02月10日
👍2

本当にありがとうございました！

xilixjd picture xilixjd 2019年02月10日
このページは役に立ちましたか？
0 / 5 - 0 評価

関連する問題

framerate picture framerate  ·  3コメント
bloodyowl picture bloodyowl  ·  3コメント
tleunen picture tleunen  ·  3コメント
jimfb picture jimfb  ·  3コメント
zpao picture zpao  ·  3コメント