Pracownik serwisu wydaje się automatycznie zatrzymywać w pewnym momencie. Takie zachowanie w sposób niezamierzony zamyka połączenie WebSocket ustanowione podczas aktywacji.Zapobieganie automatycznemu zatrzymywaniu pracownika serwisowego
Kiedy i dlaczego się zatrzymuje? Jak mogę programowo wyłączyć to nieoczekiwane działanie, aby pracownik serwisu pozostał uruchomiony?
To, co widzisz, to oczekiwane zachowanie i prawdopodobnie nie ulegnie zmianie.
Pracownicy usług celowo mają bardzo krótką żywotność. Są "zrodzeni" w odpowiedzi na określone zdarzenie (install, activate, message, fetch, push itd.), Wykonują swoje zadanie, a następnie "umierają" krótko po tym. Długość życia jest zwykle wystarczająco długa, aby można było obsłużyć wiele zdarzeń (to jest install może być poprzedzone przez activate, po którym następuje fetch), zanim pracownik umrze, ale w końcu umrze. Dlatego bardzo ważne jest, aby nie polegać na żadnym stanie globalnym w skryptach i ładować żadnych informacji o stanie, które są potrzebne za pośrednictwem IndexedDB lub interfejsu API Cache Storage, gdy uruchamia się pracownik serwisowy.
Pracownicy serwisowi to skutecznie procesy w tle, które są instalowane za każdym razem, gdy odwiedzasz określone strony internetowe. Jeśli te procesy w tle mogły działać bezterminowo, istnieje zwiększone ryzyko negatywnego wpływu na baterię i wydajność urządzenia/komputera. Aby zmniejszyć to ryzyko, przeglądarka uruchomi te procesy tylko wtedy, gdy uzna to za konieczne, tj. W odpowiedzi na zdarzenie.
Przypadku użycia dla WebSockets polega na tym, aby klient nasłuchiwał niektórych danych z serwera. W tym przypadku, przyjazną dla pracownika alternatywą dla używania WebSockets jest użycie Push Messaging API i poproszenie pracownika serwisu o reakcję na zdarzenia push. Pamiętaj, że w aktualnej implementacji Chrome musisz wyświetlać powiadomienie widoczne dla użytkownika podczas obsługi zdarzenia push. "Milczący" przypadek użycia push nie jest teraz obsługiwany.
Jeśli zamiast odsłuchiwać dane z serwera, używałeś WebSockets jako sposobu wysyłania danych z twojego klienta na serwer, niestety nie ma na to wielkiego sposobu obsługi. W pewnym momencie w przyszłości może istnieć sposób zarejestrowania pracownika serwisu, który zostanie przebudzony przez zdarzenie okresowe/oparte na czasie, w którym to momencie użytkownik może użyć fetch() do wysłania danych do serwera, ale obecnie nie jest obsługiwany w żadnym przeglądarki.
P.S .: Chrome (zwykle) nie zabije pracownika serwisu, gdy masz otwarty interfejs DevTools, ale tylko po to, aby ułatwić debugowanie i nie jest zachowaniem, na którym powinieneś polegać w przypadku prawdziwej aplikacji.
To naprawdę bardzo zła wiadomość dla mnie. Od punktu, w porównaniu z SharedWorker, ServiceWorker ma po prostu ** dłuższy okres istnienia, ale tymczasowy okres życia ** zamiast dłuższej żywotności. IMHO, powinno być przy życiu co najmniej do czasu, aż wszystkie strony zależne zostaną zamknięte (jak SharedWorker). Kiedyś uwielbiam ServiceWorker, ale moje serce jest teraz całkowicie zepsute z tego powodu. – Lewis
ServiceWorker służy do obsługi zdarzeń, które muszą być uruchamiane poza kontekstem strony. Nie jest to przeznaczone do przetwarzania w tle, właśnie do tego służy SharedWorker. Jeśli spróbujesz użyć go do przetwarzania, prawdopodobnie zablokuje on zdarzenia pobierania, które są straszne dla wydajności. Mamy nadzieję włączyć SharedWorkers * wewnątrz * ServiceWorkers, ponieważ są one dla różnych rzeczy. –
Z ciekawości, dlaczego nie używasz do tego SharedWorkers? –
@ JaffaTheCake Tylko dlatego, że ServiceWorker jest wystarczająco złożony dla mojej małej aplikacji offline. Kiedyś implementowałem podejście AppCache SharedWorker +, ale przełączyłem się na ServiceWorker ze względu na * dłuższą żywotność *. Ponadto, SharedWorker ma [błąd] (http://stackoverflow.com/questions/28913545/shared-worker-is-teminated-on-reloading-page) na stronie przeładowania. – Lewis