我需要能够旋转屏幕上的视频，所以我创建了一个自定义的TextureView其在MediaPlayer的类似于目前的实施VideoView如何确实提供了便利层。 这个Android的博客文章说，有关TextureView如下：
因为SurfaceView的内容并不住在应用程序的窗口，它不能改变（移动，缩放，旋转）有效。 这使得它很难用一个SurfaceView一个ListView或滚动型内。 SurfaceView也不能与UI工具包的某些功能正确的交互诸如衰落边缘或View.setAlpha（）。
为了解决这些问题，Android 4.0的引入了一个新的widget称为TextureView依赖于硬件加速2D渲染管线和表面纹理。 TextureView提供相同的功能，SurfaceView，但不像SurfaceView，表现为普通视图。 例如你可以使用TextureView显示的OpenGL场景或视频流。 该TextureView本身可以是动画，滚动等。
然而，它看起来像TextureView正在奋力播放视频。 我测试它在目标设备上拥有1.2GHz的瑞芯微RK3066双核CPU，四核的Mali-400 GPU（ARM）和1GB RAM。 使用此设备上VideoViews相同的代码执行罚款，但TextureViews无论是“口吃”，同时播放或在所有（在左上角白色方块黑匣子）不显示，这取决于具体的器件。 在TextureViews上使用Intel提供的86“设备”仿真器进行精细。
这是性能损失预期，或者我应该寻找其他地方发现问题？ 谢谢
是的，它有望与TextureView 。 TextureView使视频要经过正常的视图合成进行渲染，不同于SurfaceView这是在GPU直接合成（解码管线直接渲染到您放置在屏幕的面积SurfaceView ）。 虽然TextureView渲染硬件加速，它仍然是经历了额外的灵活性更多的步骤，并有一定的性能损失。 此外，UI线程上运行的任何代码可能会影响TextureView不像SurfaceView 。
附加信息：
- 高级UI基本面：开发和设计
- AOSP图形架构：SurfaceView或TextureView？
你可以看到这个文章
SurfaceView和TextureView填写类似的角色，但有非常不同的实现。 要决定哪些是最需要权衡的理解。 因为TextureView是View层次结构中的一个适当的公民，它的行为就像任何其他视图，并且可以重叠或通过其它元件重叠。 您可以执行任意的变换和简单的API调用位图检索内容。
针对TextureView主击是所述组合物步骤的性能。 与SurfaceView，内容被写入到一个单独的层，其SurfaceFlinger的复合材料，理想地与覆盖。 与TextureView，在视图组合物总是与GLES执行，并且更新其内容可能导致（如果他们定位在TextureView的顶部例如）其他视图元素重绘为好。 视图渲染完成后，应用程序UI层然后必须通过SurfaceFlinger的其他层复合，所以你有效地合成每一个可见的像素的两倍。 对于全屏幕视频播放器，或任何其他应用程序，实际上是分层视频的顶部正好UI元素，SurfaceView提供了更好的性能 。
