2014-07-02 24 views
5

Phương thức setVideoURI của VideoView trong Android có vẻ như đang chặn chuỗi giao diện người dùng. Ngay sau khi tôi gọi phương thức này, giao diện người dùng bị lag, ngay cả trên các thiết bị nhanh. Có cách nào để cải thiện hiệu suất ở đây không? Chỉ có chủ đề khác với chủ đề mà tôi có thể tìm thấy tại đây:
https://groups.google.com/forum/#!topic/android-developers/eAAEAEDcksM
nhưng nó khá cũ và không có câu trả lời thỏa mãn.Android VideoView setVideoURI chặn chuỗi giao diện người dùng

+0

setVideoURI dường như gọi mMediaPlayer.prepareAsync() nội bộ, vì vậy nó chỉ cần trả lại mà không bị chặn nhưng không được. Vì vậy, việc chuyển sang MediaPlayer từ VideoView cũng sẽ không hữu ích. – Alf

+0

Bạn đã cố gắng để đặt mã của bạn bên trong một asynctask? –

+3

Điều này có xảy ra mỗi khi bạn gọi 'setVideoUri() '? Hay chỉ từ lần thứ hai trở đi? – matiash

Trả lời

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

tôi sử dụng mã này có thể nó sẽ giúp bạn

+1

Theo cách nào có nghĩa vụ phải giúp tôi? Tôi đã sử dụng cuộc gọi setVideoURI và đó là nguyên nhân gây ra sự cố về hiệu suất của tôi – Alf

1

VideoView.setVideoURI() bắt đầu một chủ đề mới để phát lại phương tiện truyền thông, nhưng nó là một phần phương tiện truyền thông giải mã gây thêm delay.The chỉ giải pháp mà có thể được ok cho bạn đang sử dụng một số hacks NDK, nhưng không Worths cho tôi

+0

Thực ra tôi nhận thấy rằng khi kết nối internet chậm, việc chặn trở nên nghiêm trọng hơn nhiều. Điều đó sẽ chống lại việc giải mã là nguồn duy nhất của sự chậm trễ. Hoặc là có một giải thích tại sao giải mã phương tiện truyền thông sẽ chặn nhiều hơn về một kết nối xấu? – Alf

+0

Tôi thực sự không chắc chắn, điều đó phụ thuộc vào những gì bạn đang làm trong nguồn, nhưng nếu kết nối chậm, thì bộ giải mã có nhiều nhân viên hơn để làm, bởi vì nhiều lần tính toán và thực hiện các thao tác thường không vì bộ đệm bị xóa giữa chờ đợi trên các gói –

2

những gì tôi đã làm là nơi các phương pháp setVideoUri() vào một handler với một looper tức

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

điều này chạy mã bên ngoài luồng giao diện người dùng chính, nhưng giữ mã trong một looper để mã có thể được thực thi mà không cần ném một ngoại lệ

0

Tôi đã phát hiện thấy VideoView không chặn luồng giao diện người dùng. Trên thực tế, người nhận chặn chuỗi giao diện người dùng chặn "android.media.VOLUME_CHANGED_ACTION".

mã vấn đề của tôi:

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

} 

setVolume gọi từ máy thu khối lượng, nó đã được gọi là 1000 lần khi chơi một mp4 5s.

audioManager.setStreamVolume quá dài trong chuỗi chính.

đang giải pháp:

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(); 
    } 

} 

Vì vậy, hãy kiểm tra thu khối lượng của bạn. Có lẽ nó có thể giúp bạn.

Các vấn đề liên quan