The Android BUG (V)- WebView plug surfaceView caused disorder
2013-06-18 19:01
651 查看
The screen Android BUG (V)- WebView plug the use surfaceView caused Mansian
Before in debug flash 11 effect of ICS use (this version surfaceView, up and down the market, basically with nativeWindow)found a bug, bug phenomenon is shown in Figure 1 (visit http:/the/www.qiaqiafood.com,
the body of the page is a flash):
Figure 1:Error pictures
Figure 2:Normal Image
Webpage loaded, no problem, but when the page drag up and down on the black area as shown in Figure 1, and the image display of cascading relationship is not normal.
The tracking process does not elaborate, and also spent a long time. On this issue:
Dump framebuffer data:
$Adb shell cat/dev/graphics/fb0>framebuffer.bin view the results, the framebuffer does flower, and consistent performance on the screen, which is not unexpected
2. Connected hierarchyviewer, analysis of the framebuffer, only to find that this is a good
3 the screencap-p/sdcard/screenshot.png found is also good
Phenomenon and reproducible method, next analyze the reasons.
The face of it, this problem with the drawing, is surfaceFlinger related. View state surfaceFlinger:
# Dumpsys SurfaceFlinger
Focus under BrowserActivity:
+ Layer 0x95cc0 (com.android.browser/com.android.browser.BrowserActivity)
z = 21025, pos = (0,0), size = (1024, 600), isOpaque = 0, needsDithering = 0, invalidate = 0, alpha = 0xff, flags = 0x00000000, tr = [1.00, 0.00][0.00, 1.00]
client = 0x918a8, identity = 40
format = 1, activeBuffer = [1024x 600:1024, 1], transform-hint = 0x00, queued-frames = 0
mBufferCount = 2, mSynchronousMode = 1, default-size = [1024x600], mPixelFormat = 1, mTexName = 3
current:{crop = [0,0, -1, -1], transform = 0x00, current = 1}
next:{crop = [0,0, -1, -1], transform = 0x00, FIFO (0)= {}}
[00]state = FREE, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16875976105982, 0x919b0 [1024x600:1024, 1]
>[01]state = QUEUED, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16877388086666, 0x8b6a0 [1024x600:1024, 1]
Region transparentRegion (this = 0x95e60, count = 1)
[0, 211, 1014, 715]
Region transparentRegionScreen (this = 0x95cf4, count = 1)
[0, 211, 1014, 715]
RegionvisibleRegionScreen (this = 0x95cd0, count = 2)
[0, 0, 1024, 211]
1014, 211, 1024, 552]
Careful analysis of the output can be a problem:the area of
the browser is a transparent area:
0,211, 1014, 715]
This area the whole activity (corresponding Surface), is divided into two visible region:
[0, 0, 1024, 211]
1014, 211, 1024, 552]
Scroll the browser page, and then view state of BrowserActivity, twice as change with position coordinates of the transparent area is not even with the scroll!
Create and render the process down surfaceView found:
The Android the surfaceView (General Game the video and browserplugin use one kind of view)in its layout area will be set to transparent (that is, burrowing), but its setting is done only at the time of
the attachWindow. Such problems caused:transparent area are not updated when a page scroll when this transparent region of the boundary after the final synthesis hwComposer boundary, and scroll the contents of the surface on, causing hwcomposer together wrong.
Know the problem, the solution can also know.
Routine practice:the every time layout traversal viewHierarchy of transparent reset have done too much, but the impact was more complex (yet to find a feasible method of modifying)
workaround practice:composer to hwComposer the area, can not be considered transparent area (the current test, have not seen will cause the system to have a bad impact), let it take all of the surface
area calculated (theoretically efficiency may influential, but no observations impact)
Modify the method to comment out setGeometry@LayerBase.cpp in visibleRegionScreen the assignment:
hwcl->visibleRegionScreen.rects =
reinterpret_cast<hwc_rect_t const *>(
visibleRegionScreen.getArray (
&Hwcl->visibleRegionScreen.numRects));
As for hierarchyviewer and the screencap get screenshot Why is a good strategy?Here you can take a look at the screenshot realization (medium in surfaceFlinger), this screenshot and framebuffer synthesis
is not the same thing, screenshot is not used hwcomposer just openGL each layer directly draw to FBO here burrow area actual calculation of the area and the workaround is not too bad.
In addition there are two problems:
1. The scroll window and the initial load flash (slower than pages), flash cover the navigation bar problem, as shown in Fig.
Figure 3:surfaceView overlap BrowserActivity
Web Scroll when flash content scroll and browser content synchronization problem, not synchronized region would have a black box.
Covered surfaceView default is placed on the surface in front of the browser, no solution, the solution can only be surfaceView on borwser behind (as I said before, because of the surface achieve burrow
(transparent)function, in fact, on the back can be resolved)
Not synchronized, see the introduction of this year google IO webview on this surfaceView should......
Before in debug flash 11 effect of ICS use (this version surfaceView, up and down the market, basically with nativeWindow)found a bug, bug phenomenon is shown in Figure 1 (visit http:/the/www.qiaqiafood.com,
the body of the page is a flash):
Figure 1:Error pictures
Figure 2:Normal Image
Webpage loaded, no problem, but when the page drag up and down on the black area as shown in Figure 1, and the image display of cascading relationship is not normal.
The tracking process does not elaborate, and also spent a long time. On this issue:
Dump framebuffer data:
$Adb shell cat/dev/graphics/fb0>framebuffer.bin view the results, the framebuffer does flower, and consistent performance on the screen, which is not unexpected
2. Connected hierarchyviewer, analysis of the framebuffer, only to find that this is a good
3 the screencap-p/sdcard/screenshot.png found is also good
Phenomenon and reproducible method, next analyze the reasons.
The face of it, this problem with the drawing, is surfaceFlinger related. View state surfaceFlinger:
# Dumpsys SurfaceFlinger
Focus under BrowserActivity:
+ Layer 0x95cc0 (com.android.browser/com.android.browser.BrowserActivity)
z = 21025, pos = (0,0), size = (1024, 600), isOpaque = 0, needsDithering = 0, invalidate = 0, alpha = 0xff, flags = 0x00000000, tr = [1.00, 0.00][0.00, 1.00]
client = 0x918a8, identity = 40
format = 1, activeBuffer = [1024x 600:1024, 1], transform-hint = 0x00, queued-frames = 0
mBufferCount = 2, mSynchronousMode = 1, default-size = [1024x600], mPixelFormat = 1, mTexName = 3
current:{crop = [0,0, -1, -1], transform = 0x00, current = 1}
next:{crop = [0,0, -1, -1], transform = 0x00, FIFO (0)= {}}
[00]state = FREE, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16875976105982, 0x919b0 [1024x600:1024, 1]
>[01]state = QUEUED, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16877388086666, 0x8b6a0 [1024x600:1024, 1]
Region transparentRegion (this = 0x95e60, count = 1)
[0, 211, 1014, 715]
Region transparentRegionScreen (this = 0x95cf4, count = 1)
[0, 211, 1014, 715]
RegionvisibleRegionScreen (this = 0x95cd0, count = 2)
[0, 0, 1024, 211]
1014, 211, 1024, 552]
Careful analysis of the output can be a problem:the area of
the browser is a transparent area:
0,211, 1014, 715]
This area the whole activity (corresponding Surface), is divided into two visible region:
[0, 0, 1024, 211]
1014, 211, 1024, 552]
Scroll the browser page, and then view state of BrowserActivity, twice as change with position coordinates of the transparent area is not even with the scroll!
Create and render the process down surfaceView found:
The Android the surfaceView (General Game the video and browserplugin use one kind of view)in its layout area will be set to transparent (that is, burrowing), but its setting is done only at the time of
the attachWindow. Such problems caused:transparent area are not updated when a page scroll when this transparent region of the boundary after the final synthesis hwComposer boundary, and scroll the contents of the surface on, causing hwcomposer together wrong.
Know the problem, the solution can also know.
Routine practice:the every time layout traversal viewHierarchy of transparent reset have done too much, but the impact was more complex (yet to find a feasible method of modifying)
workaround practice:composer to hwComposer the area, can not be considered transparent area (the current test, have not seen will cause the system to have a bad impact), let it take all of the surface
area calculated (theoretically efficiency may influential, but no observations impact)
Modify the method to comment out setGeometry@LayerBase.cpp in visibleRegionScreen the assignment:
hwcl->visibleRegionScreen.rects =
reinterpret_cast<hwc_rect_t const *>(
visibleRegionScreen.getArray (
&Hwcl->visibleRegionScreen.numRects));
As for hierarchyviewer and the screencap get screenshot Why is a good strategy?Here you can take a look at the screenshot realization (medium in surfaceFlinger), this screenshot and framebuffer synthesis
is not the same thing, screenshot is not used hwcomposer just openGL each layer directly draw to FBO here burrow area actual calculation of the area and the workaround is not too bad.
In addition there are two problems:
1. The scroll window and the initial load flash (slower than pages), flash cover the navigation bar problem, as shown in Fig.
Figure 3:surfaceView overlap BrowserActivity
Web Scroll when flash content scroll and browser content synchronization problem, not synchronized region would have a black box.
Covered surfaceView default is placed on the surface in front of the browser, no solution, the solution can only be surfaceView on borwser behind (as I said before, because of the surface achieve burrow
(transparent)function, in fact, on the back can be resolved)
Not synchronized, see the introduction of this year google IO webview on this surfaceView should......
相关文章推荐
- saving-the-android-webview-cache-on-the-sd-card
- Android WebView In NestedScrollView 加载腾讯新闻页面 点击弹出层 bug 小记
- 魅族和三星Galaxy 5.0webView 问题Android Crash Report - Native crash at /system/lib/libc.so caused by webvi
- android ScrollView嵌套WebView高度为0的BUG
- Android WebView findAll API Bug
- 一个work around方法:解决Android 3.0~4.0下WebView 对锚点链接不支持的bug
- 魅族和三星Galaxy 5.0webView 问题Android Crash Report - Native crash at /system/lib/libc.so caused by webvi
- Saving the Android WebView cache on the SD card
- Android Crash Report - Native crash at /system/lib/libc.so caused by webview
- android WebView加载不出网页内容This request has been blocked; the content must be served over HTTPS.
- Android WebView中的Bug ----FaceBook like 按钮 的bug解决
- 【Android】自定义带进度条的WebView,修复不弹出软键盘的BUG
- 如何解决Android不同系统版本WebView上传图片的bug
- android应用因为加入js而导致webview一直在加载中的bug解决方案
- Android 6.0以上系统webview的bug
- Android 4.4 KitKat, the browser and the Chrome WebView
- 记一次使用 android 自带 WebView 做富文本编辑器之API、机型的兼容及各种奇葩bug的解决
- [原][Android]All WebView methods must be called on the same thread.
- 解决Android(7.0-7.1.2)在Work Mode中所有Webview崩溃的bug
- android 2.3 webView select控件 无法及时显示optionLabel的BUG