2014-07-02 15 views
5

Il metodo setVideoURI di VideoView in Android sembra bloccare il thread dell'interfaccia utente. Non appena chiamo questo metodo, l'interfaccia utente diventa stanca, anche su dispositivi veloci. C'è un modo per migliorare le prestazioni qui? L'unico altro thread con quell'argomento che ho trovato qui:
https://groups.google.com/forum/#!topic/android-developers/eAAEAEDcksM
ma è piuttosto vecchio e non ha una risposta soddisfacente.Android VideoView setVideoURI blocca thread UI

+0

setVideoURI sembra chiamare internamente mMediaPlayer.prepareAsync(), quindi dovrebbe solo tornare senza bloccare ma non lo fa. Quindi passare a MediaPlayer da VideoView non sarebbe utile. – Alf

+0

Hai provato a inserire il codice all'interno di un asynctask? –

+3

Succede ogni volta che chiami 'setVideoUri()'? O solo dalla seconda volta in poi? – matiash

risposta

-1
VideoView myVideoView = (VideoView)findViewById(R.id.myvideoview); 
myVideoView.setVideoURI(Uri.parse(url)); 
myVideoView.setMediaController(new MediaController(this)); 
myVideoView.requestFocus(); 
myVideoView.start(); 

Ho usato questo codice può vi aiuterà a

+1

In che modo dovrebbe aiutarmi? Sto già utilizzando la chiamata setVideoURI e questa è la causa dei miei problemi di prestazioni – Alf

1

VideoView.setVideoURI() avvia un nuovo thread per la riproduzione multimediale, ma è la parte di decodifica multimediale che provoca più unica soluzione delay.The che potrebbero essere ok per voi è utilizzando alcuni hack NDK, ma non meriti per me

+0

In realtà mi risulta che quando la connessione a Internet è lenta, il blocco diventa molto più grave. Ciò direbbe che la decodifica è l'unica fonte dei ritardi. O c'è una spiegazione del perché la decodifica dei media bloccherebbe di più su una cattiva connessione? – Alf

+0

Non sono sicuro, dipende da cosa stai facendo in source, ma se la connessione è lenta, il decoder ha più personale da fare, perché calcola e fa ripetutamente operazioni che di solito non funzionano perché il buffer è cancellato tra l'attesa sui pacchetti –

2

Quello che ho fatto è stato posto il metodo setVideoUri() in un gestore con un looper cioè

new Handler(Looper.myLooper()).post(new Runnable(){ 
    @Override 
    public void run(){ 
     videoview.setVideoUri("uri"); 
    } 
}); 

questo esegue il codice all'esterno del thread principale dell'interfaccia utente, ma lo mantiene in un looper in modo che il codice possa essere eseguito senza generare un'eccezione

0

Ho riscontrato che VideoView non blocca il thread dell'interfaccia utente. In realtà nel ricevitore di "android.media.VOLUME_CHANGED_ACTION" che blocca il thread dell'interfaccia utente.

Il mio codice problema:

public void setVolume(int volume) { 
    try { 
     audioManager.setStreamVolume(AudioManager.STREAM_MUSIC, volume, 0); 
     ivVoice.setTag(volume != 0); 
     updateVoiceImage(); 
    } catch (Exception e) { 
     e.printStackTrace(); 
    } 

} 

setVolume chiamato dal ricevitore volume, ha chiamato 1000 volte durante la riproduzione di un mp4 5s.

audioManager.setStreamVolume richiede troppo tempo nella thread principale.

codice della soluzione:

public void setVolume(int volume) { 
    try { 
     //if volume not changed , do nothing. 
     if(volume != lastVolume){ 
      audioManager.setStreamVolume(AudioManager.STREAM_MUSIC,volume,0); 
      ivVoice.setTag(volume != 0); 
      updateVoiceImage(); 
      lastVolume = volume; 
     } 
    } catch (Exception e) { 
     e.printStackTrace(); 
    } 

} 

Quindi, si prega di controllare il ricevitore del volume. Forse può aiutarti.

Problemi correlati