Per vari motivi, ho bisogno di runOnUiThread() l'istanziazione effettiva & inizializzazione di WebView.È possibile separare i thread UI e HTTP di WebView?
Ciò significa che anche le connessioni HTTP sottostanti sono eseguite sul thread dell'interfaccia utente?
Se ciò è vero, è possibile separare l'interfaccia utente WebView dal thread connessioni HTTP?
Se è possibile, qual è il modo corretto di farlo?
Lo trovo molto difficile credere che Android esegua richieste HTTP remote sul thread dell'interfaccia utente, supponendo che si inizino le richieste tramite WebView.loadUrl(). Ciò renderebbe una terribile esperienza utente.
Appena eseguito, ho eseguito un'app Android nel debugger, con un numero di base WebView e interrotto nel debugger. Ecco quello che vedo:
Se WebViewCoreThread, WebViewWorkerThread, o http0-http3 non sono la manipolazione del connessioni di rete per WebView oggetti, quindi
Inoltre, se si considera questa risposta da uno degli utenti con la reputazione più elevata dello stack overflow, loadUrl() is asynchronous. Un rapido passaggio nel debugger mi dice che loadUrl(), che viene chiamato sul thread dell'interfaccia utente (noto anche come main), è troppo veloce perché la connessione venga gestita in modo sincrono sul thread dell'interfaccia utente. (Ho inserito un breakpoint prima e dopo la chiamata a loadUrl() con un URL che so che non viene servito molto rapidamente).
Quindi, la mia risposta è che hai finito ... sono già separati! (sì!)
Quello che dici ha senso, ma nel mio overload loadUrl() effettivamente registro l'id del thread (usando 'android.os.Process.myTid()') ed è ** esattamente la stessa discussione id come l'interfaccia utente **. Mi sto perdendo qualcosa? Stai dicendo che le richieste HTTP effettive sono fatte sui thread chiamati 'http0' -' http3'? Esiste un modo * per me * per registrare gli ID thread effettivi nell'applicazione per questi thread HTTP? Grazie. –
@BillTheApe, sei corretto. 'loadUrl()' è chiamato sul thread dell'interfaccia utente. Questo è previsto. Ma, quello che succede (molto probabilmente) è che all'interno dell'implementazione di Android di 'loadUrl()', prende l'URL (un oggetto 'String' o 'URL') e lo inserisce in una coda thread-safe. Appena ciò è fatto, 'loadUrl()' completa e restituisce il controllo al thread chiamante (ad esempio il thread dell'interfaccia utente). Quindi, passa un altro thread (non il thread dell'interfaccia utente) e recupera l'URL dalla coda thread-safe e lo utilizza per aprire una connessione al server web. Quindi recupera i dati e infine ... – Nate
... notifica il thread dell'interfaccia utente per il rendering del contenuto recuperato in 'WebView'. Non so che questo è ** esattamente ** come funziona, ma questo è un esempio in cui l'attività di rete viene gestita su un thread non dell'interfaccia utente, ma l'esperimento mostra ancora che 'loadUrl()' viene chiamato sull'interfaccia utente filo. La chiave è che al termine del completamento di 'loadUrl()', 'WebView' probabilmente non ha tutto il contenuto effettivamente reso sullo schermo (o persino recuperato dalla rete). Ha senso? – Nate