Jak wykryć, kiedy przeglądarka dławi liczniki i odłączanie gniazd sieciowych po tym, jak użytkownik opuści kartę lub wyłączy ekran? (javascript)

Kontekst

Gra dostarczana jako progresywna aplikacja internetowa, która ma liczniki czasu ( setTimeout, setInterval) i połączenia z gniazdem sieciowym , aby uzyskać komunikację w czasie rzeczywistym.

Co się dzieje

Wszystko jest w porządku, dopóki użytkownik pozostaje w aplikacji. Ale kiedy użytkownik przechodzi do innej karty lub innej aplikacji lub wyłącza ekran (w przypadku telefonu komórkowego), staje się on „piekielnie nieznanym światem”.

• Gniazda sieciowe mogą, ale nie muszą, zostać „wstrzymane” lub „wyłączone”
• Czasomierze wyglądają, jakby były dławione lub debugowane.

To zachowanie wydaje się zależeć od przeglądarki i platformy, a może nawet zależy od konkretnego zachowania użytkownika. Wydaje mi się, że przeglądarki i system operacyjny mają swój własny cykl życia / mechanizmy oszczędzania baterii i / lub obliczeń.

Gdy użytkownik powraca, aplikacja jest w nieznanym stanie i mam trudności z prawidłowym przywróceniem stanu.

Jeśli chodzi o websockets, mam automatyczne ponowne połączenie z socket.io i reconnecting-websocket, ale to nie wszystko, aby rozwiązać wszystko.

Poszukuję odpowiedzi

• Jakie są „cykle życia” różnych przeglądarek w odniesieniu do nich? Czy to jest udokumentowane? Kiedy decydują się na wyłączenie i otwarcie przepustnicy?
• Co robią dokładnie z gniazdami internetowymi? Przeglądarki po prostu je rozłączają?
• Co dokładnie robią z licznikami czasu? Przepustają je, ogłaszają, czy coś innego?
• Co się dzieje z wykonywaniem javascript w ogóle? Wstrzymano / zniszczono / dławiono?
• Czy istnieje sposób, aby dołączyć do jakiegoś wydarzenia w cyklu życia przeglądarki, gdy ma to wyłączyć? Jedyne, co mogłem znaleźć, to API widoczności

• Czy istnieje sposób na sztuczne odtworzenie tego zachowania w celu przetestowania rozwiązań? Jest to szczególnie trudne na komputerze. Websockets nie można wyłączyć, a programiści chromu nie wydają się spieszyć, aby pomóc w rozwiązaniu problemu z 2014 roku (!): Websockets nie są uwzględnione podczas korzystania z ograniczania połączenia

• Niezależnie od powyższego, czy istnieje pragmatyczne rozwiązanie dla różnych przeglądarek w celu wykrycia / rozwiązania tego problemu? (na przykład z doświadczenia Firefox wydaje się zachowywać zupełnie inaczej niż Chrome, a iPhone rozłącza się znacznie częściej niż Android)

powiązane linki

• Safari porzuca połączenie sieciowe z powodu braku aktywności, gdy strona nie jest ostra

Nie jestem pewien, ale możesz skorzystać z usług pracowników. O ile wiem, działają one w tle, nawet jeśli karta nie jest otwarta, i zostają przerwane, jeśli karta zostanie zamknięta.

Btw. cykle życia kart przeglądarki wydają się być różne w każdej przeglądarce, ponieważ każda przeglądarka obsługuje to inaczej. Z tego, co widzę, przeglądarka może zamrozić karty, jeśli przeglądarka potrzebuje więcej pamięci na inne rzeczy.

Oto dokumenty z Chrome .

Pamiętam, że istnieją pewne zdarzenia, takie jak obciążenie, które informują, czy użytkownik opuścił lub ponownie otworzył kartę. Możesz użyć tych zdarzeń do ponownego połączenia itp.

Dałbym różne porady dotyczące projektowania aplikacji. Rozumiem, że Twoim zamiarem jest dodanie większej logiki, aby zrozumieć, czy użytkownik nie jest już aktywny w przeglądarce. To pociąga za sobą inny problem, którym są specyficzne cechy przeglądarki, aby zaimplementować tę logikę. Mając to na uwadze, zamiast tego zainwestowałbym w lepszą obsługę błędów , zarówno na serwerze, jak i kliencie.

Błędy nie będą specyficzne dla przeglądarki. Ich obsługa sprawi, że Twoja aplikacja będzie bardziej odporna i agnostyczna wobec zmian w przeglądarce, co może ostatecznie zmienić, powiedzmy, sposób hibernacji karty, dowolną inną funkcję, którą dostawca może wdrożyć w przyszłości.

Jest to pomysł, który można znaleźć w architekturze usług, ale ten sam wzór dotyczy każdej aplikacji internetowej. Możesz poszukać Design-for-Failpojęć:

Złożoność sprawia, że ​​niemożliwe jest przyjęcie odporności systemów, na których się opiera. Zamiast tego należy zaprojektować systemy i aplikacje w dowolnej warstwie na stosie IT, aby założyć możliwość awarii na niższych poziomach. Projektowanie na wypadek awarii wymaga myślenia o tolerancji błędów na wszystkich warstwach. Twórcy aplikacji nie mogą już ograniczać się do myślenia o funkcjonalności.

https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html