dequeueBuffer : 버퍼 수를 설정하지 않고 여러 버퍼를 대기열에서 빼낼 수 없습니다.


123

WebView 앱 Android 4.4.2 Moto X 2013에서 아래 오류가 발생합니다 Rhomobile 5.0.2. 앱은 SDK 19minAPI 17.

몇 가지 조사 결과 다음과 같은 문제가있는 것 같습니다 Snapdragon 800 / Adreno GPU devices.

여기여기Google 문제 추적기 에서이 문제에 대한 링크가 있습니다.

하드웨어 가속을 비활성화하는 것은 WebView를 매우 느리게 만들기 때문에 실제로 옵션이 아닙니다.

오류는 다음과 같습니다.

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

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)

1
이 문제에 대한 해결책을 찾았습니까?
Massimo

6
아니요,하지만 고맙게도 Android 5 이상에서는 WebView가 이제 GooglePlay를 통해 업데이트되며이 문제는 천천히 사라집니다.
fnllc 2016 년

답변:


1

이것은 다음과 같이 메모리 부족 문제입니다.

11-08 18 : 28 : 31.347 : W / Adreno-ES20 (4749) : : GL_OUT_OF_MEMORY

android.view.SurfaceGPU가 처리 할 수있는 것보다 더 많은 업데이트를하고 있습니다. 나는 당신이 이것을 시도해 볼 수 있는지 확신하지 못합니다.
또한 충돌이없는 많은 장치에서 사용자가 가끔 UI 다리를 경험할 것이라고 믿습니다.

몇 년 전에 비슷한 문제에 직면했습니다. 제 경우에는 주로 다리 였지만 문제는 동일하다고 생각합니다.

이를 해결하기 위해 프레임 속도를 측정하는 카운터를 추가했습니다. 프레임 속도가 빠르다가 갑자기 심하게 떨어지는 것을 보았 기 때문에 균형 논리를 적용하여 다리를 놓지 않는 가장 높은 FPS를 검색했습니다.

  • 60FPS로 시작
  • 다리면 FPS를 2로 나눕니다.
  • 그렇지 않은 경우 마지막 값과 현재 값 사이의 평균으로 설정하십시오.
  • 행복 할 때까지 반복하십시오;)

기본적으로 완벽한 FPS를위한 이진 검색입니다.

귀하의 경우에는 충돌이 발생하기 때문에 조금 더 까다롭기 때문에 FPS 카운터를 유지하고 검색에 더주의해야합니다.

FPS 로그를 서버로 보냅니다. 충분한 데이터가 있으면 장치 모듈 당 FPS 시작 지점으로 더 똑똑해질 수 있습니다.

WebView SurfaceView에 손을 대는 한 이것은 사소한 일이 아니라고 생각하지만 Android 4.4.2에 대해 이야기하고 있으므로 리플렉션으로 할 수없는 것은 없습니다 :)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.