dequeueBuffer: can't dequeue multiple buffers without setting the buffer count

我在一个 Rhomobile 5.0.2 WebView 应用程序的 Android 4.4.2 Moto X 2013上得到了下面的错误。该应用程序是用 SDK 19和 minAPI 17编译的。

经过一些研究，这似乎是 Snapdragon 800 / Adreno GPU devices的一个问题:

这里 和 给你是这个问题的链接在 < strong > google 问题跟踪器上

禁用硬件加速并不是一个真正的选择，因为它使得 WebView 非常缓慢。

因为错误是:

dequeueBuffer: can't dequeue multiple buffers without setting the buffer count

How can I set the buffer count in the com.rhomobile.rhodes.RhodesActivity ?

11-08 18:28:31.227: I/SFPerfTracer(238):      triggers: (rate: 0:0) (423387 sw vsyncs) (0 skipped) (0:361861 vsyncs) (2:863582)
11-08 18:28:31.328: W/Adreno-EGLSUB(4749): <DequeueBuffer:593>: dequeue native buffer fail: Unknown error 2147483646, buffer=0x61213afc, handle=0x0
11-08 18:28:31.331: W/Adreno-EGLSUB(4749): <SwapBuffers:1343>: Invalid native buffer. Failed to queueBuffer
11-08 18:28:31.331: W/Adreno-EGLSUB(4749): <updater_thread:456>: native buffer is NULL
11-08 18:28:31.346: E/BufferQueue(238): [com.myapp.myapp/com.rhomobile.rhodes.RhodesActivity] dequeueBuffer: can't dequeue multiple buffers without setting the buffer count
11-08 18:28:31.346: W/Adreno-EGLSUB(4749): <DequeueBuffer:593>: dequeue native buffer fail: Invalid argument, buffer=0x61213afc, handle=0x0
11-08 18:28:31.347: W/Adreno-ES20(4749): <gl2_surface_swap:43>: GL_OUT_OF_MEMORY
11-08 18:28:31.347: W/Adreno-EGL(4749): <qeglDrvAPI_eglSwapBuffers:3596>: EGL_BAD_SURFACE
11-08 18:28:31.347: W/HardwareRenderer(4749): EGL error: EGL_BAD_SURFACE
11-08 18:28:31.352: W/HardwareRenderer(4749): Mountain View, we've had a problem here. Switching back to software rendering.
11-08 18:28:31.478: D/qdgralloc(4749): Invalid gralloc handle (at 0x0): ver(-1/12) ints(-1/12) fds(-1/2) magic(????/gmsm)
11-08 18:28:31.478: W/GraphicBufferMapper(4749): lock(...) failed -22 (Invalid argument)
11-08 18:28:31.478: W/Surface(4749): failed locking buffer (handle = 0x0)
11-08 18:28:31.531: E/ViewRootImpl(4749): Could not lock surface
11-08 18:28:31.531: E/ViewRootImpl(4749): java.lang.IllegalArgumentException
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Surface.nativeLockCanvas(Native Method)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Surface.lockCanvas(Surface.java:243)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.drawSoftware(ViewRootImpl.java:2466)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.draw(ViewRootImpl.java:2440)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2284)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1914)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1024)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5796)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer$CallbackRecord.run(Choreographer.java:761)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer.doCallbacks(Choreographer.java:574)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer.doFrame(Choreographer.java:544)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:747)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Handler.handleCallback(Handler.java:733)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Handler.dispatchMessage(Handler.java:95)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Looper.loop(Looper.java:136)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.app.ActivityThread.main(ActivityThread.java:5102)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at java.lang.reflect.Method.invokeNative(Native Method)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at java.lang.reflect.Method.invoke(Method.java:515)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at dalvik.system.NativeStart.main(Native Method)
13244 次浏览
小开

这是一个内存不足的问题，如下所示:

11-0818:28:31.347: W/Adreno-ES20(4749) : 记忆

android.view.Surface is making more updates then the GPU can handle. I am not sure that you can even try-catch this one.
我还相信，在许多没有崩溃的设备上，用户会偶尔体验到 UI 延迟。

几年前我也遇到过类似的问题。在我的案例中，主要是滞后，但我相信问题是一样的。

为了解决这个问题，我添加了一个计数器来测量帧速率。我看到帧速率很高，但是突然之间它严重下降，所以我应用了一个平衡逻辑来搜索不会延迟的最高 FPS。

  • 从60 FPS 开始
  • 如果它的滞后，除以2的 FPS
  • If it's not, then set it to average between the last value and the current.
  • 不断重复，直到你开心为止;)

基本上就是二进制搜索完美的 FPS。

在您的情况下，这有点棘手，因为您经历了崩溃，所以您将不得不持久化 FPS 计数器，并在搜索时更加小心。

将 FPS 日志发送到服务器。一旦你有了足够的数据，你就可以更聪明地使用每个设备模块的 FPS 起点。

至于把你的手放在 WebView SurfaceView 上，我想这也不是小事，但是我们讨论的是 Android 4.4.2，所以没有什么是你不能用反射来做的:)


提交答案