React: Unter welchen Umständen gibt unstable_shouldYield true zurück?

Erstellt am 8. Feb. 2019  ·  4Kommentare  ·  Quelle: facebook/react

In Scheduler.js

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

unstable_shouldYield () gibt true zurück, wenn currentDidTimeout false ist, und shouldYieldToHost () gibt true zurück, aber warum?

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

shouldYieldToHost () return true bedeutet, dass in dieser Leerlaufzeit keine Zeit mehr verbleibt
currentDidTimeout ist false bedeutet, dass der Zeitplan kein Timeout ist
Welche Beziehung zwischen ihnen, warum hängt unstable_shouldYield () von ihnen ab?

Question

Hilfreichster Kommentar

Wir geben der Host-Umgebung regelmäßig - etwa alle 16 ms - nach, damit die Suche eingehende Ereignisse einschließlich Benutzereingaben verarbeiten kann. frameDeadline ist der Zeitstempel, zu dem wir nachgeben möchten (ursprünglich auf now() + 16ms ). Sollte also YieldToHost nach Ablauf dieser Zeit true zurückgeben. Dann verwenden wir eine Kombination aus requestIdleCallback und requestAnimationFrame, damit wir die nächste Arbeit bald verarbeiten können.

Im Idealfall können wir das gesamte Rendering in diesen kleinen 16-ms-Schnitten beenden. Wenn jedoch viele andere Dinge gleichzeitig passieren, kann es sein, dass die React-Arbeit "verhungert" und nicht in der Lage ist, die kleinen Slices vollständig zu rendern. Wir haben also eine zweite Überprüfung: Jedes ausstehende Render- oder Statusupdate hat eine "Ablaufzeit" (normalerweise zwischen 100 ms und 5000 ms). Wenn diese Zeit ohne Abschluss des Renderings vergeht, wechseln wir in einen synchronen Modus, bis dieses Update abgeschlossen werden kann. Dies ist nicht ideal, stellt jedoch sicher, dass alle Aktualisierungen verarbeitet werden, ohne zu lange zu warten.

Wir stellen im Browser einen Timer ein (z. B. mit setTimeout) für dieselbe Ablaufzeit. Wenn dieser Timer ausgelöst wird, wissen wir, dass wir die Arbeit synchron ausführen müssen. In diesem Fall wird currentDidTimeout auf true gesetzt, sodass wir nicht nachgeben.

In Zukunft planen wir die Verwendung einer neuen isInputPending Browser-API (https://github.com/WICG/is-input-pending), damit wir die Verarbeitungsarbeit fortsetzen und nur dann nachgeben können, wenn neue Benutzereingaben vorliegen , anstatt immer alle 16ms nachzugeben.

Alle 4 Kommentare

Wir geben der Host-Umgebung regelmäßig - etwa alle 16 ms - nach, damit die Suche eingehende Ereignisse einschließlich Benutzereingaben verarbeiten kann. frameDeadline ist der Zeitstempel, zu dem wir nachgeben möchten (ursprünglich auf now() + 16ms ). Sollte also YieldToHost nach Ablauf dieser Zeit true zurückgeben. Dann verwenden wir eine Kombination aus requestIdleCallback und requestAnimationFrame, damit wir die nächste Arbeit bald verarbeiten können.

Im Idealfall können wir das gesamte Rendering in diesen kleinen 16-ms-Schnitten beenden. Wenn jedoch viele andere Dinge gleichzeitig passieren, kann es sein, dass die React-Arbeit "verhungert" und nicht in der Lage ist, die kleinen Slices vollständig zu rendern. Wir haben also eine zweite Überprüfung: Jedes ausstehende Render- oder Statusupdate hat eine "Ablaufzeit" (normalerweise zwischen 100 ms und 5000 ms). Wenn diese Zeit ohne Abschluss des Renderings vergeht, wechseln wir in einen synchronen Modus, bis dieses Update abgeschlossen werden kann. Dies ist nicht ideal, stellt jedoch sicher, dass alle Aktualisierungen verarbeitet werden, ohne zu lange zu warten.

Wir stellen im Browser einen Timer ein (z. B. mit setTimeout) für dieselbe Ablaufzeit. Wenn dieser Timer ausgelöst wird, wissen wir, dass wir die Arbeit synchron ausführen müssen. In diesem Fall wird currentDidTimeout auf true gesetzt, sodass wir nicht nachgeben.

In Zukunft planen wir die Verwendung einer neuen isInputPending Browser-API (https://github.com/WICG/is-input-pending), damit wir die Verarbeitungsarbeit fortsetzen und nur dann nachgeben können, wenn neue Benutzereingaben vorliegen , anstatt immer alle 16ms nachzugeben.

Danke für die Antwort
Ich habe noch einige Fragen,

  1. Ich denke, unstable_shouldYield() steht dafür, ob die Arbeit im Zeitplan unterbrochen werden kann oder nicht. Ist das richtig?
  2. Beziehen sich die "16ms" auf activeFrameTime ?
  3. Wann wird firstCallbackNode.expirationTime < currentExpirationTime true zurückgeben? Bedeutet das, dass die Priorität der nächsten Arbeit höher ist als die der vorherigen?
  1. Jede Rendering-Aufgabe sollte häufig unstable_shouldYield () überprüfen. (Wir nennen es ungefähr nach jeder Komponente im Baum.) Meistens gibt es false zurück (was bedeutet, dass Sie weitermachen), aber wenn es true zurückgibt, bedeutet dies, dass das Rendern angehalten werden muss.

  2. Ja.

  3. Ich glaube, dass diese Bedingung erfüllt ist, wenn während eines vorhandenen Renderings eine neuere Arbeit mit höherer Priorität in die Warteschlange gestellt wird. In diesem Fall möchten wir true zurückgeben, damit wir zu dieser Aufgabe wechseln können.

Vielen Dank. Es ist wirklich nett von dir!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen