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
 

解釋下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

還有的情況是，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其實是很難解的 = = ，我研究了好幾天，其實現在也是一知半解的。

暫時就想到這麼多，自己寫的東西很多東西不懂，歡迎指正~

文章自己原創不容易，轉載請註明出處。