Android createWindowSurface failed EGL_BAD_ALLOC 引起Crash的解决方案

时间：2022-04-29 15:07:51

createWindowSurface failed EGL_BAD_ALLOC

先看下Log：

W/Adreno-EGL﹕ <eglTimestampCreate:5493>: EGL_BAD_ALLOC
E/libEGL﹕ eglMakeCurrent:784 error 3003 (EGL_BAD_ALLOC)
I/Choreographer﹕ Skipped 69 frames!  The application may be doing too much work on its main thread.
connect: already connected (cur=1, req=1)
E/libEGL﹕ EGLNativeWindowType 0x6052c710 already connected to another API
E/libEGL﹕ eglCreateWindowSurface:415 error 3003 (EGL_BAD_ALLOC)
D/AndroidRuntime﹕ Shutting down VM
W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0x4165fce0)
W/Adreno-GSL﹕ <gsl_ldd_control:412>: ioctl fd 61 code 0x400c0907 (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
W/Adreno-GSL﹕ <log_gpu_snapshot:327>: panel.gpuSnapshotPath is not set.not generating user snapshot
W/Adreno-EGLSUB﹕ <updater_thread:448>: waitFunc failed
W/xxx_android﹕ createWindowSurface failed EGL_BAD_ALLOC
    java.lang.RuntimeException: createWindowSurface failed EGL_BAD_ALLOC
            at android.view.HardwareRenderer$GlRenderer.createSurface(HardwareRenderer.java:1351)
            at android.view.HardwareRenderer$GlRenderer.createEglSurface(HardwareRenderer.java:1243)
            at android.view.HardwareRenderer$GlRenderer.initialize(HardwareRenderer.java:1060)
            at android.view.HardwareRenderer.initializeIfNeeded(HardwareRenderer.java:605)
            at android.view.ViewRootImpl.draw(ViewRootImpl.java:2396)
            at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2252)
            at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1882)
            at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:996)
            at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5603)
            at android.view.Choreographer$CallbackRecord.run(Choreographer.java:761)
            at android.view.Choreographer.doCallbacks(Choreographer.java:574)
            at android.view.Choreographer.doFrame(Choreographer.java:544)
            at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:747)
            at android.os.Handler.handleCallback(Handler.java:733)
            at android.os.Handler.dispatchMessage(Handler.java:95)
            at android.os.Looper.loop(Looper.java:136)
            at android.app.ActivityThread.main(ActivityThread.java:5146)
            at java.lang.reflect.Method.invokeNative(Native Method)
            at java.lang.reflect.Method.invoke(Method.java:515)
            at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:732)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:566)
            at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
            at dalvik.system.NativeStart.main(Native Method)
3023-3023/com.xxx.xxxE/AndroidRuntime﹕ FATAL EXCEPTION: main
错误信息为：createWindowSurface failed EGL_BAD_ALLOC

解释下EGL：EGL 视窗设计是基于人们熟悉的用于 Microsoft Windows （ WGL ）和 UNIX （ GLX ）上的 OpenGL 的 Native 接口，与后者比较接近。OpenGL ES 图形管线的状态被存储于 EGL 管理的一个 Context 中。 Frame Buffers 和其他绘制 Surfaces 通过 EGL API 创建、管理和销毁。EGL 同时也控制和提供了对设备显示和可能的设备渲染配置的访问。

错误信息的大概意思就是创建窗口视图失败，错误信息是EGL_BAD_ALLOC。

EGL_BAD_ALLOC：无法创建视图（缺少资源或者之前已经创建了一个）。

如果遇到了这个错误，我想，你的应用是不是已经开启了硬件加速。开启硬件加速功能是在Android3.0以后出现的，这也就是为什么从Android3.0之后，流畅度比2.0好很多，要是说硬件加速的话，就有点多了，以后有时间的时候再说吧。

我这里提到的这个错误，是基于正常的应用，如果你的应用是基于cocox2d或者其他的引擎开发的，那么解决方法是控制一下SurfaceView的生命周期，这个网上有很多的方法。如果你的应用没有手动指定GlSurfaceView，但是出现了这个问题，那么就继续看吧。这个问题引起的原因比较多，本文不能说肯定解决问题，但是也许会给你一些提示。

出现上面的Log，说明应用在进行绘图时候出现了错误。经常遇到的情况是：Activity1进入Activity2（可能会带WebView情况居多），然后再回到Activity1，刷Activity1的列表（等类似的操作）。就会出现这个Log。

分析：

首先Activity1一般都是使用了Opengl绘图，当切换到Activity2的时候（一般带有WebView的情况居多），这个时候WebView也使用了opengl进行绘制，在关闭Activity2的时候可能出现：Activity2关闭了，但是WebView没有彻底关闭。于是回到Activity1的时候，由于WebView使用gl绘图处在正在使用EGL阶段，而现在Activity1又要使用gl绘图，这个时候就会出现crash。

W/ManagedEGLContext﹕ doTerminate failed: EGL count is 2 but managed count is 1
这个情况解决是关闭在Activity2OnDestory的时候关掉这个WebView，removeallview()，destory()，必要的时候使用反射关闭webview，代码就不上了。

还有的情况是，Activity2中使用了某些线程，导致了Activity2没有彻底关闭，来回开关Activity2的时候导致内存溢出。但是Activity2内存溢出了为什么会在切换到Activity1的时候Crash呢？因为在切换到Activity1的时候，Activity1要进行gl绘图，这个创建过程其实是非常吃内存的，大概仅仅一个创建绘图的过成就需要吃掉8M的内存，但是这个时候由于Activity2由于内存溢出，导致根本就没有8M内存给Activity1来吃，于是就出现了Activity1绘图失败，而且这个失败导致Crash的Log是不会报在应用的Log的，而是会报在SystemProcess下面的。

这个情况的解决是先看下Activity2是否有内存溢出。进DDMS，GC一下，看看反复开关Activity2内存有没有涨，如过发现内存涨了，这个时候用MemoryAnalyzer来查一下，就会知道是哪行代码出现问题了。

还有一种可能是Activity1OnPause的时候出现的问题，具体看下Log。最好是看一下onTrimMemory里的level，如果提示危险的话，在相应的生命周期里面做一下内存处理，比如判断一下bitmap的大小，清理一下bitmap等操作。尽量不要让Activity到一个危险的即将被回收的环境。例如下面的Log，还是要具体问题具体分析的。

08-29 12:47:04.376    1023-1075/system_process W/InputDispatcher﹕ channel '4272d878 com.xxx (server)' ~ Consumer closed input channel or an error occurred.  events=0xd
08-29 12:47:04.376    1023-1075/system_process E/InputDispatcher﹕ channel '4272d878 com.xxx (server)' ~ Channel is unrecoverably broken and will be disposed!
08-29 12:47:04.418      266-266/? D/Zygote﹕ Process 16898 terminated by signal (7)
08-29 12:47:04.459    1023-4505/system_process I/WindowState﹕ WIN DEATH: Window{4272d878 u0 com.xxx.MainActivity}
08-29 12:47:04.459    1023-4505/system_process W/InputDispatcher﹕ Attempted to unregister already unregistered input channel '4272d878 com.xxx (server)'
08-29 12:47:04.464   1023-17235/system_process W/ActivityManager﹕ Exception thrown during pause
    android.os.DeadObjectException
            at android.os.BinderProxy.transact(Native Method)
            at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:660)
            at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:765)
            at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2497)
            at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2374)
            at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2068)
            at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:9736)
            at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:9629)
            at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:10280)
            at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:9825)
            at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)
还有个，就是把硬件加速关掉。其实隐患还是在的，治标不治本，而且关闭硬件加速的话，应用确实会卡，帧数掉的比较多。

总结：如果你的应用是使用的全局的那种硬件加速，不要想着在Activity类中去单独控制他的GLSurfaceView，而是要找到这个类出现的问题。一般情况的话：内存问题（找到内存溢出的地方，处理掉，线程没有关闭之类的）；或者例如跳到某个弹窗或者界面在返回，应该是GL绘制冲突，处理一下生命周期；或者server，看下服务是不是重复开启了。

这个bug其实是很难解的 = = ，我研究了好几天，其实现在也是一知半解的。

暂时就想到这么多，自己写的东西很多东西不懂，欢迎指正~

文章自己原创不容易，转载请注明出处。

标签：

相关文章