Як виявити, коли браузер відключає таймери та веб-розетки після того, як користувач залишає вкладку або вимикає екран? (javascript)

Контекст

Гра поставляється як прогресивний веб-додаток, у якому є таймери ( setTimeout, setInterval) та підключення до веб- розетки для спілкування в режимі реального часу.

Що відбувається

Все добре, поки користувач залишається в додатку. Але коли користувач переходить на іншу вкладку чи іншу програму або вимикає екран (у випадку мобільного), він стає "пекельним невідомим світом".

• Веб-розетки можуть або не можуть бути "призупиненими" або "вимкненими"
• Таймери виглядають так, ніби їх відкидають або знімають з ладу.

Така поведінка, схоже, залежить від веб-переглядачів та платформи та, можливо, навіть залежить від конкретної поведінки користувача. Я думаю, що у браузерів та ОС є власний життєвий цикл / механізми для економії акумулятора та / або обчислень.

Коли користувач повертається, додаток перебуває в невідомому стані, і я намагаюся відновити стан належним чином.

Що стосується вебсокетів, у мене є автоматичне підключення до socket.io та повторно з'єднання-websocket, але цього недостатньо для вирішення всього.

Шукаєте відповіді

• Які "життєві цикли" різних браузерів щодо них? Це документально підтверджено? Коли вони вирішують вимкнути і заглушити?
• Що вони роблять саме з веб-розетками? Браузери їх просто відключають?
• Що вони роблять саме для таймерів? Вони їх придушують, чи розберуть, чи щось інше?
• Що відбувається із виконанням javascript взагалі? Призупинено / знищене / заглушене?
• Чи є спосіб підключитися до якоїсь події життєвого циклу браузера, коли він буде вимикати речі? Єдине, що я міг знайти, це API видимості

• Чи існує спосіб штучного відтворення такої поведінки, щоб мати можливість перевірити рішення? Особливо важко це на робочому столі. Веб-розетки не можна вимкнути, і розробники хрому не поспішають допомогти проблемі з 2014 року!

• Незалежно від сказаного, чи існує прагматичне крос-браузерне рішення для виявлення / вирішення цієї проблеми? (наприклад, з досвіду, Firefox на робочому столі, схоже, поводиться зовсім інакше, ніж Chrome, а iPhone відключатиметься набагато частіше, ніж Android)

Пов'язані посилання

• Підключення веб-розетки Safari через неактивність, коли сторінка не в фокусі

Не зовсім впевнений, але ви можете скористатися сервісними працівниками. Наскільки я знаю, вони працюють у фоновому режимі, навіть якщо вкладка не відкрита і припиняється, якщо закривається вкладка.

Btw. життєвий цикл вкладок браузера, здається, різний у кожному браузері, оскільки кожен браузер обробляє його по-різному. З того, що я бачу, що браузер може заморожувати вкладки, якщо браузеру потрібно більше пам’яті для інших речей.

Ось документи з Chrome .

Я згадав, що є деякі події, як-от завантаження, які повідомляють вам, чи користувач залишив або знову відкрив вкладку. Ви можете використовувати ці події для підключення тощо.

Я б дав різні поради щодо розробки програми. Наскільки я розумію, ваш намір полягає в тому, щоб додати більше логіки, щоб зрозуміти, чи користувач більше не активний у браузері. Це тягне за собою іншу проблему, яка полягає в специфіці браузера для реалізації цієї логіки. Зважаючи на це, я б замість цього інвестував у покращення керування помилками як на сервері, так і на клієнті.

Помилки не залежать від браузера. Поводження з ними зробить ваш додаток більш стійким та агресивним до змін у веб-переглядачах, які можуть з часом змінити, скажімо, спосіб переходу в сплячку на вкладку, будь-яку іншу функцію, яку постачальник може застосувати у майбутньому.

Це ідея, яку ви можете знайти в архітектурі сервісів, але однаковий зразок стосується будь-якого веб-додатку. Ви можете шукати Design-for-Failпоняття:

Складність робить неможливим припустити стійкість із боку систем, на які спирається людина. Натомість потрібно проектувати системи та програми на будь-якому заданому рівні в ІТ-стеці, щоб припустити можливість виходу з ладу на нижчих рівнях. Конструкція для відмови потребує роздумів про стійкість до відмов на всіх шарах. Розробники програм більше не можуть обмежуватись думками про функціональність.

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