Làm cách nào để phát hiện khi trình duyệt điều chỉnh bộ hẹn giờ và ngắt kết nối webs sau khi người dùng rời khỏi tab hoặc tắt màn hình? (javascript)


12

Bối cảnh

Một trò chơi được vận chuyển dưới dạng một ứng dụng web lũy tiến có kết nối bộ hẹn giờ ( setTimeout, setInterval) và websocket để có được giao tiếp thời gian thực.

Chuyện gì đang xảy ra

Mọi thứ đều ổn miễn là người dùng ở lại trong ứng dụng. Nhưng khi người dùng chuyển sang một tab khác, hoặc một ứng dụng khác hoặc tắt màn hình (trong trường hợp là điện thoại di động), nó sẽ trở thành một "thế giới vô danh".

  • Websockets có thể hoặc không thể "tạm dừng" hoặc "tắt"
  • Bộ đếm thời gian trông giống như chúng đang được điều chỉnh hoặc ra mắt.

Hành vi này dường như phụ thuộc vào trình duyệt và nền tảng và, thậm chí, có thể phụ thuộc vào hành vi người dùng cụ thể. Tôi đoán các trình duyệt và HĐH có vòng đời / cơ chế riêng để tiết kiệm pin và / hoặc tính toán.

Khi người dùng quay lại, ứng dụng ở trạng thái không xác định và tôi đang vật lộn để khôi phục trạng thái đúng cách.

Về websockets, tôi có tự động kết nối lại với socket.iokết nối lại websocket nhưng nó không đủ để giải quyết mọi thứ.

Tìm kiếm câu trả lời

  • "Vòng đời" của các trình duyệt khác nhau liên quan đến những trình duyệt này là gì? Đây có phải là tài liệu? Khi nào họ quyết định tắt và ga?
  • Họ làm gì chính xác với websockets? Trình duyệt chỉ ngắt kết nối chúng?
  • Họ làm gì chính xác để tính giờ? Họ điều tiết chúng hoặc ra mắt chúng hay cái gì khác?
  • Điều gì xảy ra với việc thực thi javascript nói chung? Tạm dừng / phá hủy / điều tiết?
  • Có cách nào để tham gia vào một số loại sự kiện vòng đời trình duyệt khi nó sẽ tắt mọi thứ không? Điều duy nhất tôi có thể tìm thấy có thể là API khả năng hiển thị
  • Có cách nào để tái tạo một cách giả tạo hành vi này để có thể thử nghiệm các giải pháp không? Nó đặc biệt khó trên máy tính để bàn. Websockets không thể tắt và các nhà phát triển crom dường như không vội vàng giúp đỡ một vấn đề từ năm 2014 (!): Không bao gồm các socket web khi sử dụng điều tiết kết nối

  • Bất kể ở trên, có một giải pháp trình duyệt chéo thực dụng để phát hiện / giải quyết vấn đề này? (ví dụ như từ trải nghiệm, Firefox trên máy tính để bàn dường như hoạt động hoàn toàn khác so với Chrome và iPhone sẽ ngắt kết nối thường xuyên hơn nhiều so với Android)

Liên kết liên quan


1
Đây chỉ là một bản nháp wicg.github.io/page-lifecycle .
norbertpy

Câu trả lời:


7

Không chắc chắn chính xác, nhưng bạn có thể sử dụng nhân viên dịch vụ. Theo tôi biết, chúng chạy trong nền ngay cả khi tab của bạn không được mở và bị chấm dứt nếu tab của bạn đóng lại.

Btw. vòng đời của các tab trình duyệt dường như khác nhau trên mỗi trình duyệt, vì mỗi trình duyệt xử lý nó khác nhau. Từ những gì tôi thấy rằng trình duyệt có thể đóng băng các tab nếu trình duyệt cần thêm bộ nhớ cho những thứ khác.

Đây là tài liệu từ Chrome .

Tôi nhớ rằng có một số sự kiện, như onload cho bạn biết nếu người dùng đã rời khỏi hoặc mở lại tab. Bạn có thể sử dụng những sự kiện này để kết nối lại, v.v.


Đây là một ý tưởng thú vị. Đây có phải là một cái gì đó bạn đã làm với một số mã để chia sẻ?
Kev

Tôi xin lỗi, tôi không có mã ví dụ ngay bây giờ, nhưng nếu bạn tìm kiếm nhân viên dịch vụ, có rất nhiều hướng dẫn cách thiết lập chúng. Điều duy nhất bạn phải làm chỉ là đặt một mã nhỏ nơi bạn kết nối với máy chủ ws của bạn và console.log()khi bạn nhận được tin nhắn từ máy chủ ws. Trong chrome, bạn có thể mở bảng điều khiển của nhân viên dịch vụ và do đó bạn có thể kiểm tra xem các tin nhắn có bị thu hồi khi bạn rời khỏi tab không.
Mointy

0

Tôi sẽ đưa ra lời khuyên khác nhau về cách thiết kế ứng dụng của bạn. Từ những gì tôi hiểu ý định của bạn là thêm logic hơn để hiểu nếu người dùng không còn hoạt động trong trình duyệt. Điều này đòi hỏi một vấn đề khác đó là đặc thù của trình duyệt để thực hiện logic đó. Với ý nghĩ đó, thay vào đó tôi sẽ đầu tư vào việc xử lý lỗi tốt hơn , cả trong máy chủ và máy khách.

Lỗi sẽ không dành riêng cho trình duyệt. Xử lý những thứ đó sẽ làm cho ứng dụng của bạn trở nên linh hoạt hơn và không tin vào những thay đổi của trình duyệt, cuối cùng có thể thay đổi, giả sử, cách chúng ngủ đông một tab, bất kỳ tính năng nào khác mà nhà cung cấp có thể thực hiện trong tương lai.

Đây là một ý tưởng mà bạn có thể tìm thấy trong kiến ​​trúc dịch vụ, nhưng mẫu tương tự áp dụng cho bất kỳ ứng dụng web nào. Bạn có thể muốn tìm kiếm các Design-for-Failkhái niệm:

Sự phức tạp làm cho không thể giả định sự mạnh mẽ trên một phần của các hệ thống mà người ta dựa vào. Thay vào đó, người ta cần thiết kế các hệ thống và ứng dụng ở bất kỳ lớp nào trong nhóm dựa trên ngăn xếp CNTT để giả định khả năng thất bại ở các cấp thấp hơn. Thiết kế cho sự thất bại đòi hỏi phải suy nghĩ về khả năng chịu lỗi ở tất cả các lớp. Các nhà phát triển ứng dụng không còn có thể tự giới hạn suy nghĩ về chức năng.

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


Bạn đang nghĩ về loại "xử lý lỗi tốt hơn"?
Kev
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.