Android TextureView/绘图/绘画性能

Question

我正在尝试使用 TextureView 制作绘图/绘画应用程序在安卓上。我想支持高达 4096x4096 像素的绘图表面，这对于我的最小目标设备(我用于测试)来说是合理的，它是 Google Nexus 7 2013，它有一个很好的四核 CPU 和 2GB 内存。

我的要求之一是我的 View 必须位于允许放大、缩小和平移的 View 内，这是我编写的所有自定义代码(想想 iOS 中的 UIScrollView)。

我试过在 OnDraw 中使用常规 View (不是 TextureView )，性能绝对糟糕 - 每秒不到 1 帧。即使我拨打 Invalidate(rect) 也会发生这种情况只有 rect 发生了变化。我尝试关闭 View 的硬件加速，但没有渲染，我认为是因为 4096x4096 对于软件来说太大了。

然后我尝试使用 TextureView性能要好一点 - 大约每秒 5-10 帧(仍然很糟糕但更好)。用户绘制位图，然后使用后台线程将其绘制到纹理中。我正在使用 Xamarin，但希望代码对 Java 人员有意义。

private void RunUpdateThread()
{
    try
    {
        TimeSpan sleep = TimeSpan.FromSeconds(1.0f / 60.0f);
        while (true)
        {
            lock (dirtyRect)
            {
                if (dirtyRect.Width() > 0 && dirtyRect.Height() > 0)
                {
                    Canvas c = LockCanvas(dirtyRect);
                    if (c != null)
                    {
                        c.DrawBitmap(bitmap, dirtyRect, dirtyRect, bufferPaint);
                        dirtyRect.Set(0, 0, 0, 0);
                        UnlockCanvasAndPost(c);
                    }
                }
            }
            Thread.Sleep(sleep);
        }
    }
    catch
    {
    }
}

如果我将 lockCanvas 更改为传递 null 而不是 rect，则性能在 60 fps 时非常出色，但是 TextureView 的内容闪烁并损坏，这是令人失望的。我原以为它只是在下面使用 OpenGL 帧缓冲区/渲染纹理，或者至少可以选择保留内容。

除了在 Android 中的原始 OpenGL 中执行所有操作之外，是否还有其他选项可以在绘制调用之间保留的表面上进行高性能绘图和绘制？

Answer 1

首先，如果您想了解幕后发生的事情，您需要阅读 Android Graphics Architecture document .它很长，但如果你真诚地想了解“为什么”，它就是开始的地方。

关于TextureView

TextureView 是这样工作的:它有一个 Surface，它是一个具有生产者-消费者关系的缓冲区队列。如果您使用软件 (Canvas) 渲染，则会锁定 Surface，从而为您提供缓冲区；你在上面画画；然后你解锁 Surface，它将缓冲区发送给消费者。在这种情况下，消费者处于同一进程中，称为 SurfaceTexture 或(在内部，更恰本地)GLConsumer。它将缓冲区转换为 OpenGL ES 纹理，然后渲染到 View 。

如果关闭硬件加速，GLES 将被禁用，TextureView 将无法执行任何操作。这就是为什么当您关闭硬件加速时您一无所获。 The documentation非常具体:“TextureView 只能在硬件加速窗口中使用。在软件中渲染时，TextureView 不会绘制任何内容。”

如果指定dirty rect，软件渲染器会在渲染完成后将之前的内容memcpy到帧中。我不相信它会设置剪辑矩形，因此如果您调用 drawColor()，您将填满整个屏幕，然后覆盖这些像素。如果您当前没有设置剪辑矩形，您可能会从中看到一些性能优势。 (虽然我没有检查代码。)

脏矩形是一个输入输出参数。当您拨打 lockCanvas() 时，您传递了您想要的矩形，并且允许系统在调用返回之前对其进行修改。 (实际上，这样做的唯一原因是如果没有前一帧或调整 Surface 的大小，在这种情况下它会扩展它以覆盖整个屏幕。我认为使用更直接的方法会更好地处理“我拒绝您的矩形”信号。)您需要更新您返回的矩形内的每个像素。你不能改变矩形，你似乎试图在你的样本中做 - 无论在 lockCanvas() 之后的脏矩形中是什么|成功是你需要借鉴的。

我怀疑肮脏的 rect 处理不当是您闪烁的根源。可悲的是，这是一个很容易犯的错误，因为 lockCanvas() 的行为dirtyRect arg 仅记录在 the Surface class 中本身。

表面和缓冲

所有表面都是双缓冲或三缓冲。没有办法解决这个问题——你不能同时读和写也不会流泪。如果您想要一个可以在需要时修改和推送的单个缓冲区，则需要锁定、复制和解锁该缓冲区，这会在组合管道中造成停顿。为了获得最佳吞吐量和延迟，翻转缓冲区更好。

如果您想要锁定-复制-解锁行为，您可以自己编写(或找到一个执行此操作的库)，并且它的效率将与系统为您完成时一样有效(假设您擅长blit 循环)。绘制到屏幕外的 Canvas 并 blit 位图，或绘制到 OpenGL ES FBO 并 blit 缓冲区。您可以在 Grafika 的“record GL app” Activity 中找到后者的示例，该 Activity 具有在屏幕外渲染一次，然后 blit 两次(一次用于显示，一次用于录制视频)的模式。

更多速度等

在 Android 上绘制像素有两种基本方法:使用 Canvas 或使用 OpenGL。 Canvas 渲染到 Surface 或 Bitmap 总是在软件中完成，而 OpenGL 渲染是用 GPU 完成的。唯一的异常(exception)是，当渲染到 custom View 时，您可以选择使用硬件加速，但这在渲染到 SurfaceView 或 TextureView 的 Surface 时不适用。

绘图或绘画应用程序可以记住绘图命令，或者只是将像素扔到缓冲区并将其用作其内存。前者允许更深层次的“撤消”，后者更简单，并且随着要渲染的内容数量的增加，性能也越来越好。听起来您想做后者，因此从屏幕外进行 blitting 是有道理的。

大多数移动设备对 GLES 纹理的硬件限制为 4096x4096 或更小，因此您将无法将单个纹理用于​​更大的纹理。您可以查询大小限制值 (GL_MAX_TEXTURE_SIZE)，但最好使用尽可能大的内部缓冲区，并且只渲染适合屏幕的部分。我不知道 Skia (Canvas) 的限制是什么，但我相信您可以创建更大的位图。

根据您的需要，SurfaceView 可能比 TextureView 更可取，因为它避免了中间的 GLES 纹理步骤。您在 Surface 上绘制的任何内容都会直接进入系统合成器 (SurfaceFlinger)。这种方式的缺点是，由于 Surface 的消费者不在进程内，View 系统没有机会处理输出，所以 Surface 是一个独立的层。 (对于绘图程序来说，这可能是有益的——正在绘制的图像在一层上，您的 UI 在顶部的单独层上。)

FWIW，我没看过代码，但 Dan Sandler 的 Markers应用程序可能值得一看(源代码 here)。

更新:腐败是identified as a bug和 fixed in 'L' .