Android bug——Launcher 0x506导致花屏问题

现象描述：

在Android4.4中，概率极高会出现Launcher或者应用整个绘制成花屏、黑屏或者字体绘制成方块等问题，出现花屏问题的时候将会在hwui中打印0x506的错误。

分析：

通过log发现也只有hwui中出现0x506这个错误码，即hwui中当前绘图时使用的fbo是无效的。接着通过分析代码发现当前hwui中使用fbo的地方为LayerRenderer中，在LayerRenderer中使用到fbo的地方也就是当view中需要创建HardwareLayer的时候，将会调用LayerRenderer将view绘制的信息通过fbo保存在纹理中：

status_t LayerRenderer::prepareDirty(float left, float top, float right, float bottom,
        bool opaque) {
    glBindFramebuffer(GL_FRAMEBUFFER, mLayer->getFbo());
    …………
    return OpenGLRenderer::prepareDirty(dirty.left, dirty.top, dirty.right, dirty.bottom, opaque);
}

Layer* LayerRenderer::createLayer(uint32_t width, uint32_t height, bool isOpaque) {
    Caches& caches = Caches::getInstance();
    GLuint fbo = caches.fboCache.get();
    …………
    caches.activeTexture(0);
    Layer* layer = caches.layerCache.get(width, height);
    …………
    layer->setFbo(fbo);
    …………
    GLuint previousFbo;
    glGetIntegerv(GL_FRAMEBUFFER_BINDING, (GLint*) &previousFbo);

    glBindFramebuffer(GL_FRAMEBUFFER, layer->getFbo());
    layer->bindTexture();
    …………
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
            layer->getTexture(), 0);

    glBindFramebuffer(GL_FRAMEBUFFER, previousFbo);
    return layer;
}

定位：

1. 在使用fbo绘图的时候加入打印，同时dump出当前的每个纹理，发现当前绑定到纹理时，纹理就是错误的，所以用了错误的纹理去作为fbo的纹理，导致最后出现了花屏的问题
2. 接着在当前创建fbo的时候，通过调用glCheckFramebufferStatus 来查看，发现当前的fbo创建与绑定纹理都是正确的

3. 通过加入详细log发现当前出错是在LayerRenderer::prepareDirty，这时会先调用glBindFramebuffer，接着将会调用 glClear，也就是这时候去使用fbo的fb清除当前的颜色缓存的时候，当前的fb是不能访问的。接着在gpu中打印发现当前fbo绑定的纹理id对应的纹理是空的，这时候也就是产生了0x506绘图错误。

通过上述分析，得出的结论是，在创建fbo的时候是正确的，在使用fbo的时候就出错了，由于当绑定fbo出错了，还继续绘制，但是当合成的时候由于当前的fbo是无效的，但是却还继续去使用，其实也就是当前的纹理id在绑定fbo的时候这个纹理是无效的，但是在后续的绘图的时候，如果这个纹理id是被拿来绑定纹理了，那么就出现了花屏问题，如果仍然没有拿来绑定纹理，那么就是出现黑屏的问题。这也就是出现了0x506绘图错误的原因了，接着将分析为什么会出现在创建fbo的时候是正常的，在使用的时候却是无效的。

原因分析：

通过分析知道当前fbo的是用于view中作为HardwareLayer的时候使用，接着查看view.java代码发现，view中变量mHardwareLayer用于保存当前的fbo的信息，如果当前mHardwareLayer没有调用LayerRenderer的destroyLayer的时候，这个layer是不会被删除的：

  boolean destroyLayer(boolean valid) {
        if (mHardwareLayer != null) {
            AttachInfo info = mAttachInfo;
            if (info != null && info.mHardwareRenderer != null &&
                    info.mHardwareRenderer.isEnabled() &&
                    (valid || info.mHardwareRenderer.validate())) {

                info.mHardwareRenderer.cancelLayerUpdate(mHardwareLayer);
                mHardwareLayer.destroy();
                mHardwareLayer = null;

                invalidate(true);
                invalidateParentCaches();
            }
            return true;
        }
        return false;
    }

问题也就是由于当OpenGL上下文被删除的时候（这也是通过打印log发现在使用fbo之前已经将OpenGL上下文删除过，又重新创建新的上下文了），当前的mHardwareLayer没有调用destroyLayer来将当前的layer删除，这样就导致下次进入的时候直接使用了上次的mHardwareLayer，这样就出现了使用了上次的fbo的id，但是这个id却没调用glFramebufferTexture2D来绑定对应的纹理。（有个细节需要注意：如果没有生成fbo的id，直接调用glBindFramebuffer这个函数是会直接将指定的id拿来使用的，如果不存在就创建，这是标准规定的，这也是问题出现的原因）接着将分析为什么在OpenGL上下文删除的时候，没有将对应的mHardwareLayer删除的原因。

view中删除mHardwareLayer是在destroyLayer中，这边在删除的时候会去判断一些条件，重要的是当前的info.mHardwareRenderer.isEnabled() ，如果当前的硬件加速是不可用的就不删除，通过打印log，发现当前出错的时候，确实当前的硬件加速是不可用的，这也就导致了mHardwareLayer资源没删除。

接着查看代码发现当硬件加速不可用的时候，调用是在HardwareRenderer.java中的destroy的时候会将当前的surface删除的时候，通过打印堆栈发现当调用destroy的时候就是当surface无效的时候，也就是正常现象。但是这时候如果刚好遇上了内存吃紧的情况，则将会调用WindowManagerGlobal.java的startTrimMemory，这函数将会调用view的destroyHardwareResources来进行每个view的资源的释放，这时候就没法将mHardwareLayer的资源进行释放了。

public void startTrimMemory(int level) {
        if (HardwareRenderer.isAvailable()) {
            if (level >= ComponentCallbacks2.TRIM_MEMORY_COMPLETE
                    || (level >= ComponentCallbacks2.TRIM_MEMORY_MODERATE
                            && !ActivityManager.isHighEndGfx())) {
                synchronized (mLock) {
                    for (int i = mRoots.size() - 1; i >= 0; --i) {
                        mRoots.get(i).destroyHardwareResources();
                    }
                }
                mNeedsEglTerminate = true;
                HardwareRenderer.startTrimMemory(ComponentCallbacks2.TRIM_MEMORY_COMPLETE);
                return;
            }
            HardwareRenderer.startTrimMemory(level);
        }
    }

修改方案：

当在destroyLayer的时候判断如果当前的硬件加速不可用的时候就调用，mHardwareRenderer的safelyRun来删除mHardwareLayer的资源：

diff --git a/core/java/android/view/View.java b/core/java/android/view/View.java
index d212786..239c235 100644
--- a/core/java/android/view/View.java
+++ b/core/java/android/view/View.java
@@ -13152,6 +13152,23 @@ public class View implements Drawable.Callback, KeyEvent.Callback,
 
                 invalidate(true);
                 invalidateParentCaches();
+            } else if (info != null && info.mHardwareRenderer != null) {
+                // If fall into this path, means the hardware render has
+                // already been disabled. Destroy it in a safely context
+                // to avoid random UI corruption
+                info.mHardwareRenderer.safelyRun(new Runnable() {
+                    @Override
+                    public void run() {
+                        mHardwareLayer.destroy();
+                        mHardwareLayer = null;
+
+                        if (mDisplayList != null) {
+                            mDisplayList.reset();
+                        }
+                        invalidate(true);
+                        invalidateParentCaches();
+                    }
+                });
             }
             return true;
         }