本文共 4497 字，大约阅读时间需要 14 分钟。
现象描述：
在Android4.4中，概率极高会出现Launcher或者应用整个绘制成花屏、黑屏或者字体绘制成方块等问题，出现花屏问题的时候将会在hwui中打印0x506的错误。
分析：
通过log发现也只有hwui中出现0x506这个错误码，即hwui中当前绘图时使用的fbo是无效的。接着通过分析代码发现当前hwui中使用fbo的地方为LayerRenderer中，在LayerRenderer中使用到fbo的地方也就是当view中需要创建HardwareLayer的时候，将会调用LayerRenderer将view绘制的信息通过fbo保存在纹理中：
status_tLayerRenderer::prepareDirty(float left, float top, float right, float bottom,
bool opaque) {
glBindFramebuffer(GL_FRAMEBUFFER,mLayer->getFbo());
…………
returnOpenGLRenderer::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 --gita/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 fallinto this path, means the hardware render has
+ // alreadybeen disabled. Destroy it in a safely context
+ // toavoid 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;
}
转载地址：http://jswxi.baihongyu.com/