Quando si è fuori dal thread principale, come posso far funzionare un po 'di codice sul thread principale il più velocemente possibile?

Question

Possiedo un'interfaccia utente parzialmente basata sul Web (WebView). È collegato all'interfaccia utente Android tramite un Javascript Interface. Quando si tocca un elemento in WebView, javascript chiama ad Android e Android riceve la chiamata sul thread javascript/web. Non il thread UI (principale).

Arriva in Android in 1 o meno millisecondi. Nessun problema lì. Tuttavia, poiché ora voglio cambiare l'interfaccia utente, devo passare al thread dell'interfaccia utente. (Android genera un'eccezione se modifichi l'interfaccia utente dal thread principale). Attualmente sto usando un gestore sul thread UI e chiamando post().

Questo codice (a Runnable) viene quindi chiamato ovunque tra 120 e 300 ms in seguito. Questo è un ritardo molto evidente per l'interfaccia utente per cambiare dal tocco dell'utente.

C'è un modo per ottenere un po 'di codice per l'esecuzione sul thread dell'interfaccia utente più veloce? Ecco qualche esempio di codice: class

Un'interfaccia:

public class JSInterface { 

    public void test() { 
     // Arrives here in 1ms after calling AndroidInterface.test(). Arrives n the web thread. 

     runOnUiThread(new Runnable() { 

      @Override 
      public void run() { 
       // Arrives here 100ms to 300ms after calling AndroidInterface.test(). Arrives on the main (UI) thread. 
      } 

     }); 

    } 

} 

aggiunta ad un WebView come questo:

webview.addJavascriptInterface(new JSInterface(), "AndroidInterface"); 

Chiamato in javascript come questo:

AndroidInterface.test(); 

Grazie!

Answer 1

C'è un modo per ottenere un po 'di codice per l'esecuzione sul thread dell'interfaccia utente più veloce?

runOnUiThread() e parentela mettono un messaggio su una coda di messaggi che il thread dell'applicazione principale funziona. La maggior parte delle volte, il lavoro del thread dell'applicazione principale consiste nel rimuovere un messaggio dalla coda e elaborarlo. Tuttavia, il thread dell'applicazione principale è responsabile anche della chiamata della maggior parte delle callback.

Se state vedendo "120 e 300 ms" ritardi, questo significa che una delle due cose non-mutuamente esclusive:

1. La coda ha piuttosto l'arretrato

2. Il filo principale è occupato l'esecuzione di qualche altro codice

il rapporto tra WebView, la coda, e il thread principale è piuttosto misteriosa, compar ai widget normali, perché WebView non è un widget classico reso in codice Java. Quindi, non ho idea se ci sia qualcosa che sta accadendo nel tuo contenuto Web che potrebbe spiegare questo, o se questo è abbastanza normale per WebView. Potresti provare un esperimento con contenuti Web più semplici e vedere se ottieni ritardi simili o se i ritardi sono in qualche modo più legati al contenuto Web specifico che stai rendendo.

Premere entra, inserire Handler e postAtFrontOfQueue(). Come nota the JavaDocs for that method, tuttavia, questo è pericoloso.