2016-04-28 6 views
2

[Bearbeiten: Diese Frage möglicherweise engerer Bereich, so werde ich feststellen, dass ich derzeit Chrome 49.0.2623.112 m (64-Bit) mit Standardeinstellungen, wenn ich das merke. Ich bin derzeit mit HTTPS, aber ich beobachtete sie vor dem Schalter.]Was macht ein Web-Arbeiter, wenn der Besitzer nicht im Fokus ist?

Ich habe eine Anwendung, die auf dem Web-Arbeiter aus AJAX Polling gibt. Es ist keine unglaubliche Ersparnis in Bezug auf die Leistung, aber es macht die Anwendung leichter verständlich und bietet Potenzial für zukünftige Leistungsvorteile.

ich hinzufügen, eine Konsolenprotokollierung Linie an den Arbeitnehmer, so dass es nur sagt mir jedesmal, wenn die XHR Antrag gestellt wird. Wie Sie vielleicht wissen, wenn Duplikate von Protokollzeilen in Chrome eingehen, zeichnet der Inspector nur die Anzahl der Duplikate auf.

Da ich die Seite, kann ich in der Konsole sehen: (52) XHR invoked

Wenn ich die Seite im Fokus haben, ich sehe, dass integer alle 2 Sekunden erhöhen, je mein Abfrageintervall.

JEDOCH

Als ich für eine Weile auf einem anderen Tab zu wechseln, und dann wieder, dauert es einige Sekunden für diese Nummer zu aktualisieren, zu welchem ​​Zeitpunkt es nur Updates nach der anderen. Das liegt möglicherweise daran, dass der Worker tatsächlich pausiert, was in dieser bestimmten Anwendung in Ordnung ist, oder dass der Worker noch ausgeführt wird, aber die Konsolen-API die Protokollierungszeile vom Worker nicht empfangen kann, wenn der Elternteil nicht sichtbar ist . Nicht sicher.

Aber die wichtige Sache, die ich versuche zu lösen, ist die Verzögerung, wenn ich zur Registerkarte zurückkehre. Wenn es sich um eine ansprechende Aktualisierung des Dashboards handelt, ist eine Verzögerung von 10-60 Sekunden vor dem Fortfahren der Updates bemerkbar und ein UI-Leistungsfehler.

Kann jemand einen Einblick darüber geben, was mit dem Web Worker passiert, wenn der Besitzer den Fokus verliert? Steht es tatsächlich jede Arbeit an, die erledigt werden muss (auf XHR-Nachricht), und macht es dann, wenn der Besitzer zurückkommt?

Hält man den Abrufmechanismus manuell an, wenn der Fokus verloren geht?

+0

Haben Sie darüber nachgedacht einen Zeitstempel in die Log-Ausgabe hinzugefügt? Klingt nicht nach einer harten Sache ... –

+0

Es würde zum Beispiel verifizieren, ob es der Worker ist, der im Leerlauf ist, oder der Nachrichtenkanal oder die Konsole. Ich hatte Arbeiter einige Zeit für verschiedene Sachen benutzt und sie haben nicht angehalten, als ich die Registerkarte verließ, also habe ich Gründe zu denken, dass das Problem woanders liegt. –

+0

Wenn der Arbeiter noch lief, wie ich vermute, würden die Zeitstempel auf der Ausgabe kohärent sein (z. B. alle 30 Sekunden). Ehrlich gesagt, sollten Sie als erstes ein jsFiddle machen, das das Problem demonstriert. Jetzt rate ich nur, was das verursachen könnte. Kommt es sogar vor, wenn Sie den Code vereinfachen? –

Antwort

3

Dieses Verhalten variiert zwischen den Browsern. Die meisten von ihnen werden die JavaScript-Priorität reduzieren, um CPU-Zyklen und Performance-Overhead zu erhalten, wenn die Registerkarte nicht verwendet wird. Ich glaube, einige Browser setzen die Tab-Ausführung komplett aus, also wird es eine Pause sein, bis sie wieder im Fokus steht. Ich denke, Firefox hat eine Option, dies zu kontrollieren.

+0

Standardmäßig wird die Ausführung von Hauptthreads in jedem von mir verwendeten Browser ziemlich ungehindert fortgesetzt. Nun, in der Vergangenheit habe ich explizite Methoden implementiert, um das Polling zu pausieren (brauche die Daten nicht, warum fragst du danach?), Aber dieses unerwartete Verhalten hat mich neugierig gemacht. Irgendeine Idee, was Chrome-Strategie ist in Bezug auf Web Workers standardmäßig? –

0

WebWorker sind fest an die Seite gebunden, die sie erstellt hat. Das Standardverhalten ist das Anhalten eines WebWorker, wenn die Seite nicht aktiv ist.

Ein typisches Problemszenario ist ein WebWorker, der einen WebSocket verwaltet. Diese Netzwerkverbindung ist immer noch aktiv, wenn die Ausführung angehalten wird und Nachrichten empfangen, aber nicht verarbeitet werden. Dies führt dazu, dass die internen Netzwerkpuffer des WebSockets überlaufen - im Wesentlichen ein Speicherverlust, der das gesamte System zum Absturz bringen kann.

Die Lösung ist SharedWorkers zu verwenden, die nicht fest an der Seite gebunden, die sie erstellt und sind so konzipiert, um zwischen den Seiten zu arbeiten, Fokusverlust zu ignorieren. Das WebSocket-Szenario eignet sich perfekt für SharedWorker.

Die Anwendungsfälle für jeden SharedWorker sollten gut verstanden werden, da sie immer aktiv ist und die Leistung anderer Seiten und Anwendungen beeinflussen kann.

Jetzt spielen gehen: http://coolaj86.github.io/html5-shared-web-worker-examples