Degradare con grazia con i lavoratori Web
-
19-09-2019 - |
Domanda
Quindi, sto iniziando a sentire di più e di più su Web Workers . Penso che sia assolutamente fantastico, ma la domanda che non ho visto nessuno affrontare davvero finora è come sostenere i browser meno recenti che non hanno ancora il supporto per la nuova tecnologia.
L'unica soluzione che ho potuto venire con finora è quello di fare una sorta di involucro attorno alle funzionalità Web Worker che sarebbe caduta di nuovo a qualche soluzione basata timer folle che avrebbe simulare l'esecuzione multi-threaded.
Ma anche in questo caso, come si fa a rilevare se i lavoratori web è una funzionalità supportata del browser attualmente in esecuzione il javascript?
Grazie!
Soluzione
Questa è l'annoso problema dello sviluppo web: cosa fare sui browser che non supportano quello che ti serve. Attualmente, sono favorevole solo con lavoratori web per complessi compiti, di lunga durata, che può essere suddiviso, e per qualche motivo, non può essere fatto sul lato server. In questo modo, se non si dispone di lavoratori web, è sufficiente attendere più a lungo. In caso contrario, si dovrebbe fare un pasticcio del vostro codice con involucri e quant'altro che si tenta di evitare un secondo momento. La mia strategia degradazione avviene non appena la pagina viene caricata.
funzione onload pseudocodice:
if( window.Worker /*check for support*/ )
someObject.myFunction = function() { /*algorithm that uses Web Workers*/ }
else
someObject.myFunction = function() { /* sad face */ }
È ancora scrivere l'algoritmo due volte, ma si dovrebbe farlo comunque se si desidera supportare i browser, senza Operai Web. In modo che porta ad una domanda interessante: vale la pena il tempo (e denaro) per scrivere qualcosa due volte, solo così si può andare un po 'più veloce per alcune persone
Altri suggerimenti
Dopo la masticazione su questo per un paio di giorni, ho finito per scrivere un articolo sul mio blog:
http://codecube.net/2009/07/cross-platform-javascript -webworker /
L'idea è che, quando WebWorker non è definita, v'è un'API involucro che appena utilizza tecniche incorporati. Anche se il campione in questo articolo è molto semplice, funziona in tutti i browser: -)
Ecco cosa ha detto John Resig rispondendo a un commento sul suo blog
Ho pensato a questo - ma sarà difficile. Si dovrebbe rendere l'uso del codice di elaborazione setTimeout / setInterval fin dall'inizio (il codice dovrebbe finire a lavorare sia in un lavoratore e su un sito web normale). Così, mentre il risultato sarebbe leggermente più lento per i browser dei lavoratori abilitati almeno sarebbe lavorare in entrambi i casi.
ho avuto il problema divertente che il mio compito senza il supporto Web Worker era troppo lento in Firefox (sceneggiatura non risponde), ma abbastanza veloce in tutti gli altri browser moderni. Con i lavoratori Web ha funzionato in tutti i browser tranne Opera (10,50) che non supporta lavoratori web a tutti, ma Opera ha funzionato bene senza di loro.
Così ho scritto un WorkerFacade che utilizza l'API Web Worker quando disponibile o finge l'API con alcune aggiunte minori al lavoratore effettivo JS. Potete trovare WorkerFacade come un succo su GitHub . Ha funzionato bene per me, potrebbe aiutare qualcun altro, anche.
È possibile utilizzare Modernizr ( http://modernizr.com/download/#-webworkers ) per rilevare se il browser supporta webworkers, a quel punto si poi avere due versioni ... potete vedere i browser con webworkers a http://caniuse.com/webworkers
if(Modernizr.webworkers)
{}
else
{}
@ geowa4
//globals
var useWorer={}
,noWorkerClosure=function(){...}
,myWorkerClosure=function(){...}
;
function init(){
if(!!window.Worker){
noWorkerClosure=null;
useWorer=new myWorkerClosure();
}
else{
useWorer=new noWorkerClosure();
myWorkerClosure=null;
}
}
In questo modo si liberare memoria onload e non c'è bisogno di chiedere il supporto di volta in volta.