Android TextureView против производительности VideoView

Мне нужно иметь возможность поворачивать видео на экране, поэтому я создал пользовательский TextureView, который обеспечивает уровень удобства над MediaPlayer, похожий на то, как выполняется текущая реализация VideoView. В этом сообщении в блоге Android говорится о TextureView:

Поскольку содержимое SurfaceViews не живет в окне приложений, оно не может быть эффективно преобразовано (перемещено, масштабировано, повернуто). Это затрудняет использование SurfaceView внутри ListView или ScrollView. SurfaceView также не может нормально взаимодействовать с некоторыми функциями инструментария пользовательского интерфейса, например, затухающими краями или View.setAlpha().

Чтобы решить эти проблемы, Android 4.0 представляет новый виджет TextureView, который опирается на аппаратный ускоренный 2D-рендеринг и SurfaceTexture. TextureView предлагает те же возможности, что и SurfaceView, но, в отличие от SurfaceView, ведет себя как обычный вид. Например, вы можете использовать TextureView для отображения сцены OpenGL или видеопотока. Сам TextureView может быть анимированным, прокрученным и т.д.

Однако, похоже, что TextureView пытается воспроизвести видео. На целевом устройстве, на котором я тестирую его, есть двухъядерный процессор Rockchip RK3066 с тактовой частотой 1,2 ГГц, четырехъядерный графический процессор Mali-400 (ARM) и 1 ГБ оперативной памяти. Тот же код с помощью VideoViews на этом устройстве отлично работает, но TextureViews либо "заикаются" во время воспроизведения, либо вообще не отображаются (черный ящик с белыми квадратами в левом верхнем углу), в зависимости от конкретного устройства. TextureViews отлично работают на эмуляторе с помощью устройства x86, поставляемого Intel.

Ожидается ли эта производительность, или я должен искать в другом месте, чтобы найти проблему? Благодаря

Ответ 1

Да, ожидается TextureView. TextureView заставляет видео проходить нормальный просмотр-компоновку для рендеринга, в отличие от SurfaceView, который скомпонован непосредственно в графическом процессоре (конвейер декодирования передает непосредственно в область экрана, где вы помещаете SurfaceView). Хотя рендеринг TextureView аппаратно ускоряется, он все еще выполняет больше шагов для дополнительной гибкости, и есть определенный успех. Кроме того, любой код, запущенный в UI-потоке, может влиять на TextureView в отличие от SurfaceView.

Дополнительная информация:

Ответ 2

Вы можете увидеть эту статью

SurfaceView и TextureView заполняют похожие роли, но имеют очень разные реализации. Чтобы решить, что лучше всего, нужно понимать компромиссы. Поскольку TextureView является надлежащим гражданином иерархии View, он ведет себя как любой другой вид и может перекрываться или перекрываться другими элементами. Вы можете выполнять произвольные преобразования и извлекать содержимое в виде растрового изображения с помощью простых вызовов API.

Основной удар против TextureView - это выполнение шага композиции. С SurfaceView содержимое записывается на отдельный слой, который SurfaceFlinger объединяет, в идеале с наложением. С TextureView композиция View всегда выполняется с помощью GLES, а обновления к ее содержимому могут также вызвать перерисовку других элементов View (например, если они расположены поверх TextureView). После завершения рендеринга представления слой пользовательского интерфейса приложения затем должен быть скомпонован с другими слоями SurfaceFlinger, поэтому вы эффективно составляете каждый видимый пиксель дважды. SurfaceView предлагает гораздо лучшую производительность для полноэкранного видеопроигрывателя или любого другого приложения, которое фактически представляет собой элементы пользовательского интерфейса, расположенные поверх видео.