Kullanıcı bir sekmeden ayrıldıktan veya ekranı kapattıktan sonra tarayıcı zamanlayıcıları ve websockets bağlantılarını ne zaman kısaltır? (JavaScript)


12

bağlam

Gerçek zamanlı iletişim elde etmek için zamanlayıcılar ( setTimeout, setInterval) ve websocket bağlantılarına sahip aşamalı bir web uygulaması olarak gönderilen bir oyun .

Ne oluyor

Kullanıcı uygulamada kaldığı sürece her şey yolunda. Ancak kullanıcı başka bir sekmeye veya başka bir uygulamaya gittiğinde veya ekranı kapattığında (mobil durumda), "cehennem bilinmeyen bir dünya" haline gelir.

  • Web soketleri "duraklatıldı" veya "kapatıldı" olabilir veya olmayabilir
  • Zamanlayıcılar kısılmış veya açılmış gibi görünüyor.

Bu davranış, tarayıcılara ve platforma, hatta belki de belirli kullanıcı davranışına bağlı gibi görünmektedir. Sanırım tarayıcılar ve işletim sistemi pil ve / veya hesaplama tasarrufu için kendi yaşam döngüsüne / mekanizmalarına sahiptir.

Kullanıcı geri geldiğinde, uygulama bilinmeyen bir durumda ve düzgün devlet geri yüklemek için mücadele ediyorum.

Websockets ile ilgili olarak socket.io ve reconnecting-websocket ile otomatik yeniden bağlantım var, ancak her şeyi çözmek için yeterli değil.

Cevap aranıyor

  • Bunlarla ilgili olarak farklı tarayıcıların "yaşam döngüleri" nelerdir? Bu belgelendi mi? Ne zaman kapanmaya ve gaz vermeye karar veriyorlar?
  • Web soketlerine tam olarak ne yapıyorlar? Tarayıcılar sadece bağlantılarını kesti mi?
  • Zamanlayıcılara tam olarak ne yapıyorlar? Onları kısıyorlar mı, yok ediyorlar mı yoksa başka bir şey mi?
  • Genel olarak javascript yürütülmesine ne olur? Duraklatıldı / yok edildi / kısaltıldı mı?
  • Bir şeyleri kapatacakken bir tür tarayıcı yaşam döngüsü olayına bağlanmanın bir yolu var mı? Bulabildiğim tek şey görünürlük API'sı olabilir
  • Çözümleri test edebilmek için bu davranışı yapay olarak yeniden üretmenin bir yolu var mı? Özellikle masaüstünde zor. Websockets kapatılamaz ve krom geliştiricileri 2014'ten itibaren bir soruna yardımcı olmak için acele etmiyorlar (!): Bağlantı kısma kullanılırken websockets dahil değildir

  • Yukarıdakilerden bağımsız olarak, bu sorunu tespit etmek / çözmek için pragmatik bir çapraz tarayıcı çözümü var mı? (örneğin deneyimden, masaüstündeki Firefox, Chrome'a ​​kıyasla tamamen farklı görünüyor ve bir iPhone'un Android'den çok daha sık bağlantısı kesilecek)

İlgili Bağlantılar


1
Bu sadece bir taslak wicg.github.io/page-lifecycle .
norbertpy

Yanıtlar:


7

Tam olarak emin değilim, ancak servis çalışanlarını kullanabilirsiniz. Bildiğim kadarıyla, sekme açılmasa bile arka planda çalışır ve sekmeniz kapanırsa sonlandırılır.

Btw. tarayıcı sekmelerinin yaşam döngüleri her tarayıcıda farklı gibi görünmektedir, çünkü her tarayıcı farklı işliyor. Gördüğüm kadarıyla, tarayıcının başka şeyler için daha fazla belleğe ihtiyacı varsa tarayıcının sekmeleri dondurabildiğinden.

İşte Chrome'dan dokümanlar .

Bir kullanıcının sekmeyi terk edip etmediğini veya yeniden açtığını söyleyen onload gibi bazı olaylar olduğunu hatırladım. Bu olayı yeniden bağlanmak vb. İçin kullanabilirsiniz.


Bu ilginç bir fikir. Bu, paylaşmak için bazı kodlarla yaptığınız bir şey mi?
Kev

Üzgünüm, şu anda bir örnek kodum yok, ancak servis çalışanlarını ararsanız, bunları nasıl kuracağınızla ilgili bir ton öğretici vardır. Yapmanız gereken tek şey, ws-sunucunuza bağlandığınız küçük bir kod koymak ve ws-server'dan console.log()mesaj aldığınızda. Chrome'da, servis çalışanınızın konsolunu açabilir ve sekmeden ayrıldığınızda mesajların revize edilip edilmediğini test edebilirsiniz.
Mointy

0

Uygulamanızı nasıl tasarlayacağınız konusunda farklı tavsiyeler veririm. Niyetimi anladığım kadarıyla, kullanıcının tarayıcıda artık aktif olup olmadığını anlamak için daha fazla mantık eklemektir. Bu, bu mantığı uygulamak için tarayıcıya özgü farklı bir soruna neden olur . Bunu göz önünde bulundurarak, hem sunucuda hem de istemcide daha iyi hata işlemeye yatırım yapmak istiyorum .

Hatalar tarayıcıya özgü olmaz. Bunları ele almak uygulamanızı tarayıcı değişikliklerine karşı daha dayanıklı ve agnostik hale getirecektir;

Bu, hizmet mimarisinde bulabileceğiniz bir fikirdir, ancak aynı model herhangi bir web uygulaması için de geçerlidir. Design-for-FailKavramları aramak isteyebilirsiniz :

Karmaşıklık, sistemin bağlı olduğu kısımda sağlamlık almayı olanaksız kılar. Bunun yerine, daha düşük seviyelerde arıza olasılığını üstlenmek için BT yığınında herhangi bir katmandaki sistemleri ve uygulamaları tasarlamak gerekir. Başarısız tasarım, tüm katmanlardaki hata toleransı hakkında düşünmeyi gerektirir. Artık uygulama geliştiricileri kendilerini işlevsellik hakkında düşünmekle sınırlayamazlar.

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


Ne tür bir "daha iyi hata yönetimi" düşünüyorsunuz?
Kev
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.