2015-12-24 4 views
1

Я работаю над приложением, которое использует объект MediaPlayer для воспроизведения видео H.264 MP4 с WallpaperService, поскольку это приложение для живых обоев. Слив батареи происходит, когда устройство (Nexus 5, Android 6.0.1) находится в режиме ожидания и сна, если я приостановил/остановил MediaPlayer с помощью mediaPlayer.pause() или mediaPlayer.stop(). Слив составляет около 3-7%/час, как проверено несколько раз в течение ночи. Как только я выпущу медиаплеер с mediaPlayer.release(), разряд батареи возвращается к более нормальному 1%/час. Я приостанавливаю/останавливаю медиаплеер, когда onVisibilityChanged вызывает false. В телефоне сообщается, что он будет спать как на Android-карте Android, так и на Better Battery Stats.Не выпуская MediaPlayer вызывает утечку аккумулятора

Как этот дренаж батареи объясняется, если CPU успешно переходит в состояние ожидания?

EDIT: Что-то новое, что я обнаружил, заключается в том, что при вызове mediaPlayer.setSurface (null) прямо перед mediaPlayer.pause() обычное использование батареи возвращается к норме. Затем я могу сделать mediaPlayer.setSurface (поверхность), чтобы установить его обратно до mediaPlayer.start(). Проблема в том, что есть несколько черных артефактов в течение нескольких секунд после перезапуска.

ответ

0

Я не могу дать вам точный ответ, но может дать вам то, что нужно искать. Я подозреваю, что происходит, так это то, что pause() проверяет события достаточно часто, чтобы процессор не входил в более глубокий сон/C-состояния. Напротив, stop() не нуждается в проверке событий, и поэтому процессор переходит в состояние глубокого сна. Я написал an article on sleep states несколько лет назад.

Я подозреваю, что авторы функции решили проверить чаще, чем это необходимо. Это очень распространенная ошибка из-за того, что разработчики думают, что более короткие спящие/более частые проверки приводят к лучшему ответу (чего почти никогда не бывает). Вы можете проверить это, используя монитор мощности процессора, который фактически проверяет аппаратные состояния сна. К сожалению, большинство из них не проверяют и не проверяют независимые от процессора «эквиваленты».

Итак, давайте вернемся к вашему вопросу: что вы можете с этим поделать. Я могу дать вам несколько советов, но ни один из них не очень приятно:

  1. Проверьте наличие API или структуру данных, которая позволяет установить проверки интервала паузы(). Кстати, я ничего не знаю.
  2. Напишите свой собственный. Конечно, это усложняет написание независимых от платформы приложений
  3. Используйте альтернативный медиа-плеер, который сделал это правильно
  4. Молоток на Google, пока это не фиксированный

Как я уже сказал, все это не очень приятно. Кстати, идя в сеть, я обнаружил доказательства того, что это произошло не раз с новыми релизами Android.

Удачи и сообщите нам, что произойдет.

+0

Спасибо за предложения. Заглядывая в pause(), это приводит к собственному методу, который я не могу проверить. Что-то новое, что я обнаружил, заключается в том, что если я делаю mediaPlayer.setSurface (null) прямо перед mediaPlayer.pause(), использование батареи в режиме ожидания возвращается к норме. Затем я могу сделать mediaPlayer.setSurface (поверхность), чтобы установить его обратно до mediaPlayer.start(). Проблема в том, что некоторые черные артефакты делают это в течение пары секунд после перезапуска. – Flyview

+0

Новое редактирование: то же самое происходит с mediaPlayer.stop(). Если вы не делаете mediaPlayer.release(), разряд батареи продолжается. – Flyview

Смежные вопросы