วิธีการตรวจสอบเมื่อเบราว์เซอร์ throttles ตัวจับเวลาและ websockets ขาดการเชื่อมต่อหลังจากที่ผู้ใช้ออกจากแท็บหรือปิดหน้าจอ? (จาวาสคริปต์)

บริบท

เกมที่จัดส่งเป็นแอปเว็บโปรเกรสซีฟซึ่งมีตัวจับเวลา ( setTimeout, setInterval) และการเชื่อมต่อ websocket เพื่อรับการสื่อสารตามเวลาจริง

เกิดอะไรขึ้น

ทุกอย่างเรียบร้อยตราบใดที่ผู้ใช้ยังอยู่ในแอพ แต่เมื่อผู้ใช้ไปที่แท็บอื่นหรือแอพอื่นหรือปิดหน้าจอ (ในกรณีที่ใช้มือถือ) มันจะกลายเป็น "โลกที่ไม่รู้จักชั่วร้าย"

• เว็บซ็อคเก็ตอาจหรือไม่อาจกลายเป็น "หยุดชั่วคราว" หรือ "ปิด"
• ตัวจับเวลาดูเหมือนว่าพวกเขาจะถูกควบคุมปริมาณหรือเลิก

พฤติกรรมนี้ดูเหมือนจะขึ้นอยู่กับเบราว์เซอร์และแพลตฟอร์มและบางทีอาจขึ้นอยู่กับพฤติกรรมของผู้ใช้ ฉันเดาว่าเบราว์เซอร์และระบบปฏิบัติการมีวงจร / กลไกของตัวเองเพื่อประหยัดแบตเตอรี่และ / หรือการคำนวณ

เมื่อผู้ใช้กลับมาแอปนั้นอยู่ในสถานะที่ไม่รู้จักและฉันกำลังพยายามกู้คืนสถานะอย่างถูกต้อง

เกี่ยวกับเว็บซ็อกเก็ตฉันมีการเชื่อมต่ออัตโนมัติกับsocket.ioและเชื่อมต่ออีกครั้ง - websocketแต่มันก็ไม่เพียงพอที่จะแก้ปัญหาทุกอย่าง

กำลังมองหาคำตอบ

• "วงจรชีวิต" ของเบราว์เซอร์ต่าง ๆ ที่เกี่ยวข้องกับสิ่งเหล่านี้คืออะไร? เป็นเอกสารนี้หรือไม่? พวกเขาตัดสินใจปิดและเค้นเมื่อไหร่?
• พวกเขาทำอะไรกับ websockets อย่างแน่นอน? เบราว์เซอร์เพิ่งยกเลิกการเชื่อมต่อหรือไม่
• พวกเขาทำอะไรกับตัวจับเวลาอย่างแน่นอน? พวกเขาเร่งเร้าพวกเขาหรือหักหลังพวกเขาหรืออย่างอื่น
• เกิดอะไรขึ้นกับการใช้งานจาวาสคริปต์โดยทั่วไป? หยุดชั่วคราว / ทำลาย / ควบคุมปริมาณ?
• มีวิธีที่จะขอเข้าสู่วงจรชีวิตของเบราว์เซอร์บางประเภทเมื่อกำลังจะปิดบางสิ่งหรือไม่? สิ่งเดียวที่ฉันสามารถค้นหาได้คือAPI การมองเห็น

• มีวิธีในการทำซ้ำพฤติกรรมนี้เพื่อทดสอบวิธีการแก้ปัญหาได้หรือไม่? มันยากมากบนเดสก์ท็อป ไม่สามารถปิดเว็บและนักพัฒนา Chromium ไม่รีบร้อนที่จะช่วยปัญหาตั้งแต่ปี 2014 (!): เว็บไม่รวมอยู่เมื่อใช้การควบคุมปริมาณการเชื่อมต่อ

• ไม่ว่าข้างต้นจะมีวิธีแก้ปัญหาข้ามเบราว์เซอร์ในทางปฏิบัติในการตรวจสอบ / แก้ปัญหานี้หรือไม่? (เช่นจากประสบการณ์ Firefox บนเดสก์ท็อปดูเหมือนจะทำงานแตกต่างอย่างสิ้นเชิงเมื่อเทียบกับ Chrome และ iPhone จะตัดการเชื่อมต่อบ่อยกว่า Android)

ลิ้งค์ที่มีความเกี่ยวข้อง

• Safari ปล่อยการเชื่อมต่อเว็บซ็อกเก็ตเนื่องจากไม่มีการใช้งานเมื่อไม่ได้อยู่ในโฟกัส

ไม่แน่ใจ แต่คุณสามารถใช้พนักงานบริการได้ เท่าที่ฉันรู้พวกเขาทำงานในพื้นหลังแม้ว่าคุณจะไม่ได้เปิดแท็บและถูกยุติหากแท็บของคุณปิด

Btw อายุการใช้งานของแท็บเบราว์เซอร์ดูเหมือนจะแตกต่างกันไปในทุกเบราว์เซอร์เนื่องจากทุกเบราว์เซอร์จัดการแตกต่างกัน จากสิ่งที่ฉันเห็นว่าเบราว์เซอร์สามารถตรึงแท็บถ้าเบราว์เซอร์ต้องการหน่วยความจำเพิ่มเติมสำหรับสิ่งอื่น ๆ

นี่คือเอกสารจากChrome

ฉันจำได้ว่ามีบางเหตุการณ์เช่น onload ที่บอกคุณว่าผู้ใช้ได้ออกหรือเปิดแท็บอีกครั้ง คุณสามารถใช้เหตุการณ์เหล่านี้เพื่อเชื่อมต่อ ฯลฯ

ฉันจะให้คำแนะนำที่แตกต่างกันเกี่ยวกับวิธีการออกแบบแอปของคุณ จากสิ่งที่ฉันเข้าใจความตั้งใจของคุณคือการเพิ่มตรรกะเพิ่มเติมเพื่อให้เข้าใจว่าผู้ใช้ไม่ได้ใช้งานในเบราว์เซอร์อีกต่อไป สิ่งนี้ก่อให้เกิดปัญหาที่แตกต่างกันซึ่งเป็นข้อมูลเฉพาะของเบราว์เซอร์ที่จะใช้ตรรกะนั้น โดยที่ในใจฉันจะลงทุนแทนที่จะมีข้อผิดพลาดที่ดีกว่าการจัดการทั้งในเซิร์ฟเวอร์และลูกค้า

ข้อผิดพลาดจะไม่เฉพาะเบราว์เซอร์ การจัดการสิ่งเหล่านี้จะทำให้แอปของคุณยืดหยุ่นและไม่เชื่อเรื่องการเปลี่ยนแปลงของเบราว์เซอร์มากขึ้นซึ่งอาจเปลี่ยนแปลงได้ในที่สุดสมมติว่าวิธีที่พวกเขาจำศีลแท็บคุณสมบัติอื่นใดที่ผู้ขายอาจนำไปใช้ในอนาคต

นี่เป็นแนวคิดที่คุณสามารถพบได้ในสถาปัตยกรรมบริการ แต่รูปแบบเดียวกันนี้ใช้กับเว็บแอพใดก็ได้ คุณอาจต้องการค้นหาDesign-for-Failแนวคิด:

ความซับซ้อนทำให้เป็นไปไม่ได้ที่จะคาดเดาความทนทานของระบบที่ใช้งานอยู่ แต่เราต้องการออกแบบระบบและแอพพลิเคชั่นที่ชั้นใด ๆ ใน IT-based stack เพื่อสมมติความเป็นไปได้ของความล้มเหลวในระดับที่ต่ำกว่า การออกแบบเพื่อความล้มเหลวจำเป็นต้องคำนึงถึงความทนทานต่อความผิดพลาดในทุกชั้น นักพัฒนาแอปพลิเคชันไม่สามารถ จำกัด ตัวเองให้คิดถึงการทำงานได้อีกต่อไป

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