Joh*_*son 26 html5 android segmentation-fault webview galaxy
我在Android WebView中有一个复杂的,交互式的HTML5 - 它基本上可以在除Galaxy S3之外的所有平台上正常工作.在Galaxy S3(Android 4.0.4)上,每5次左右,在加载完成后,/ system/lib/libwebcore.so尝试在[各地址]访问无效内存和致命信号11(SIGSEGV) ](code = 1)被抛出.
HTML5是一场微小的战斗,敌人出现,用户斜线进行.在战斗之间是正常的html页面:正常页面 - > HTML5战斗 - >正常页面 - > HTML5战斗 - >正常页面 - > HTML5战斗.HTML5没有做任何特别开箱即用的事情 - 有很多-webkit-animation调用......
.enemy {
position:absolute;
opacity:0;
-webkit-animation:enemyAnim 0.6s linear 0.2s;
}
Run Code Online (Sandbox Code Playgroud)
...引用了很多-webkit-keyframes ......
@-webkit-keyframes enemyAnim {
from {
-webkit-transform: matrix(1, 0, 0, 1, 144.25, 150.25) scale(1, 1);
opacity:1;
}
8.33% {
-webkit-transform: matrix(1, 0, 0, 1, 189.406, 102.206) scale(1.3066, 1.3066);
opacity:1;
}
16.66% {
-webkit-transform: matrix(1, 0, 0, 1, 200.424, 82.649) scale(1.414, 1.414);
opacity:1;
}
/*…*/
Run Code Online (Sandbox Code Playgroud)
还有一个相当复杂的div树,但没有特别的实验.有一定程度的Javascript,但即使关闭所有Javascript,也会出现挂起.
有没有人遇到过与Galaxy S3不同的问题?没有Android 2.x设备有这个问题,甚至运行4.1.1的Galaxy Nexus似乎没有任何特殊问题.我之前从未想过要写Stack Overflow,但这真让我感到烦恼......
搜索"Android WebView sigsegv crash"和"4.0.4 WebView sigsegv crash"会出现几个问题,但是:
webview.clearCache()/ webView.destroyDrawingCache()似乎没有效果(虽然这个挂起显然是一个内存问题,在各个地方添加/删除System.gc()s没有很好的结果) SIGNAL 11 SIGSEGV崩溃Android的
在Android 4.0.3上的画布上的Strange崩溃绘图中没有使用画布 .A/libc:致命信号11(SIGSEGV) (是的我知道 - 调用此页面HTML5有点拉伸)
在Webview.clearView()multitimes将导致崩溃之后执行WebView.loadurl()时没有使用clearView()
在http://code.google.com/p/android/issues/detail?id=16563中没有使用preserve-3d
我查看了android webkit的更改列表,寻找4.0.4之后的可疑修复,并认为我有以下内容,但生根S3并将其带到4.1.1并没有解决问题: https:// github. COM/teamgummy/android_external_webkit /提交/ 61e0d189f2b74650bf72a6a2820f66a8b17c3d06
由于在内存free()s期间发生了一些崩溃,我知道事情在崩溃的时候是免费的,我的直觉是有些东西在渲染中被释放,而不应该.令人沮丧的是因为纯HTML,JS和CSS =/SIGSEGV在物理上是不可能的
以下是崩溃报告示例.请注意,碰撞位置不限于以下内容; 崩溃报告似乎没有太大的不同,但位置似乎有一些变化.
10-08 17:34:06.605: I/DEBUG(524): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-08 17:34:06.605: I/DEBUG(524): Build fingerprint: 'samsung/m0xx/m0:4.0.4/IMM76D/I9300XXBLH1:user/release-keys'
10-08 17:34:06.605: I/DEBUG(524): pid: 7443, tid: 7443 >>> cool.tiny.rpg.battle <<<
10-08 17:34:06.605: I/DEBUG(524): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
10-08 17:34:06.605: I/DEBUG(524): r0 deadbaad r1 00000001 r2 40000000 r3 00000000
10-08 17:34:06.605: I/DEBUG(524): r4 00000000 r5 00000027 r6 400d8540 r7 400e74f4
10-08 17:34:06.605: I/DEBUG(524): r8 01fa7160 r9 00000000 10 bed6a584 fp 41d79970
10-08 17:34:06.605: I/DEBUG(524): ip ffffffff sp bed6a2b0 lr 400b9639 pc 400b59c8 cpsr 68000030
10-08 17:34:06.605: I/DEBUG(524): d0 0000000000000000 d1 4343000000000000
10-08 17:34:06.605: I/DEBUG(524): d2 43b6800041a00000 d3 41a8000043020000
10-08 17:34:06.610: I/DEBUG(524): d4 8000000000000000 d5 43aa00003f800000
10-08 17:34:06.610: I/DEBUG(524): d6 43a4000043430000 d7 43cb000041a00000
10-08 17:34:06.610: I/DEBUG(524): d8 4082f00000000000 d9 4082f4000000025e
10-08 17:34:06.610: I/DEBUG(524): d10 4460400000000500 d11 0000000000000000
10-08 17:34:06.610: I/DEBUG(524): d12 0000000000000000 d13 0000000000000000
10-08 17:34:06.610: I/DEBUG(524): d14 0000000000000000 d15 0000000000000000
10-08 17:34:06.610: I/DEBUG(524): d16 4076800000000000 d17 7e37e43c8800759c
10-08 17:34:06.610: I/DEBUG(524): d18 0000000000000000 d19 0000000000000000
10-08 17:34:06.610: I/DEBUG(524): d20 3ff0000000000000 d21 8000000000000000
10-08 17:34:06.610: I/DEBUG(524): d22 0000000000000000 d23 0000000000000000
10-08 17:34:06.610: I/DEBUG(524): d24 0000000000000000 d25 3ff0000000000000
10-08 17:34:06.610: I/DEBUG(524): d26 4034000000000000 d27 3ff0000000000000
10-08 17:34:06.610: I/DEBUG(524): d28 0000000000000000 d29 3ff0000000000000
10-08 17:34:06.610: I/DEBUG(524): d30 0000000000000000 d31 3ff0000000000000
10-08 17:34:06.610: I/DEBUG(524): scr 60000010
10-08 17:34:06.750: I/DEBUG(524): #00 pc 000179c8 /system/lib/libc.so
10-08 17:34:06.750: I/DEBUG(524): #01 pc 00013852 /system/lib/libc.so
10-08 17:34:06.750: I/DEBUG(524): #02 pc 00015b90 /system/lib/libc.so (dlfree)
10-08 17:34:06.750: I/DEBUG(524): #03 pc 00016208 /system/lib/libc.so (free)
10-08 17:34:06.750: I/DEBUG(524): #04 pc 0010f79c /system/lib/libwebcore.so (_Z6yyfreePvS_)
10-08 17:34:06.750: I/DEBUG(524): #05 pc 0010ef70 /system/lib/libwebcore.so
10-08 17:34:06.750: I/DEBUG(524): #06 pc 003ee8ec /system/lib/libwebcore.so
10-08 17:34:06.755: I/DEBUG(524): #07 pc 003eef44 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev)
10-08 17:34:06.755: I/DEBUG(524): #08 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev)
10-08 17:34:06.755: I/DEBUG(524): #09 pc 0019b2ca /system/lib/libwebcore.so
10-08 17:34:06.755: I/DEBUG(524): #10 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv)
10-08 17:34:06.755: I/DEBUG(524): #11 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev)
10-08 17:34:06.760: I/DEBUG(524): #12 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev)
10-08 17:34:06.760: I/DEBUG(524): #13 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev)
10-08 17:34:06.760: I/DEBUG(524): #14 pc 0019b2ca /system/lib/libwebcore.so
10-08 17:34:06.760: I/DEBUG(524): #15 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv)
10-08 17:34:06.760: I/DEBUG(524): #16 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev)
10-08 17:34:06.760: I/DEBUG(524): #17 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev)
10-08 17:34:06.760: I/DEBUG(524): #18 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev)
10-08 17:34:06.760: I/DEBUG(524): #19 pc 0019b2ca /system/lib/libwebcore.so
10-08 17:34:06.760: I/DEBUG(524): #20 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv)
10-08 17:34:06.765: I/DEBUG(524): #21 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev)
10-08 17:34:06.765: I/DEBUG(524): #22 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev)
10-08 17:34:06.765: I/DEBUG(524): #23 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev)
10-08 17:34:06.765: I/DEBUG(524): #24 pc 0019b2ca /system/lib/libwebcore.so
10-08 17:34:06.765: I/DEBUG(524): #25 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv)
10-08 17:34:06.765: I/DEBUG(524): #26 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev)
10-08 17:34:06.765: I/DEBUG(524): #27 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev)
10-08 17:34:06.765: I/DEBUG(524): #28 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev)
10-08 17:34:06.770: I/DEBUG(524): #29 pc 0019b2ca /system/lib/libwebcore.so
10-08 17:34:06.770: I/DEBUG(524): #30 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv)
10-08 17:34:06.770: I/DEBUG(524): #31 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev)
10-08 17:34:06.770: I/DEBUG(524): memory map around addr deadbaad:
10-08 17:34:06.770: I/DEBUG(524): bed4a000-bed6b000 [stack]
10-08 17:34:06.770: I/DEBUG(524): (no map for address)
10-08 17:34:06.770: I/DEBUG(524): ffff0000-ffff1000 [vectors]
10-08 17:34:06.770: I/DEBUG(524): stack:
10-08 17:34:06.770: I/DEBUG(524): bed6a270 00000001
10-08 17:34:06.770: I/DEBUG(524): bed6a274 bed6a2b0 [stack]
10-08 17:34:06.770: I/DEBUG(524): bed6a278 400e2800 /system/lib/libc.so
10-08 17:34:06.770: I/DEBUG(524): bed6a27c 0000000c
10-08 17:34:06.770: I/DEBUG(524): bed6a280 400e2794 /system/lib/libc.so
10-08 17:34:06.770: I/DEBUG(524): bed6a284 400e7888
10-08 17:34:06.770: I/DEBUG(524): bed6a288 00000000
10-08 17:34:06.770: I/DEBUG(524): bed6a28c 400b9639 /system/lib/libc.so
10-08 17:34:06.770: I/DEBUG(524): bed6a290 00000000
10-08 17:34:06.770: I/DEBUG(524): bed6a294 bed6a2c4 [stack]
10-08 17:34:06.770: I/DEBUG(524): bed6a298 400d8540 /system/lib/libc.so
10-08 17:34:06.770: I/DEBUG(524): bed6a29c 400e74f4
10-08 17:34:06.775: I/DEBUG(524): bed6a2a0 01fa7160 [heap]
10-08 17:34:06.775: I/DEBUG(524): bed6a2a4 400b87a5 /system/lib/libc.so
10-08 17:34:06.775: I/DEBUG(524): bed6a2a8 df0027ad
10-08 17:34:06.775: I/DEBUG(524): bed6a2ac 00000000
10-08 17:34:06.775: I/DEBUG(524): #00 bed6a2b0 bed6a2ac [stack]
10-08 17:34:06.775: I/DEBUG(524): bed6a2b4 00000001
10-08 17:34:06.775: I/DEBUG(524): bed6a2b8 400d8524 /system/lib/libc.so
10-08 17:34:06.775: I/DEBUG(524): bed6a2bc 00000005
10-08 17:34:06.775: I/DEBUG(524): bed6a2c0 bed6a2dc [stack]
10-08 17:34:06.775: I/DEBUG(524): bed6a2c4 fffffbdf
10-08 17:34:06.775: I/DEBUG(524): bed6a2c8 bed6a2dc [stack]
10-08 17:34:06.775: I/DEBUG(524): bed6a2cc bed6a2dc [stack]
10-08 17:34:06.775: I/DEBUG(524): bed6a2d0 400dbaac /system/lib/libc.so
10-08 17:34:06.775: I/DEBUG(524): bed6a2d4 400b1857 /system/lib/libc.so
10-08 17:34:06.775: I/DEBUG(524): #01 bed6a2d8 00000130
10-08 17:34:06.775: I/DEBUG(524): bed6a2dc 20404040
10-08 17:34:06.775: I/DEBUG(524): bed6a2e0 524f4241 /dev/ashmem/dalvik-mark-stack (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2e4 474e4954 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2e8 4e49203a /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2ec 494c4156 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2f0 45482044 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2f4 41205041 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2f8 45524444 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a2fc 49205353 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.775: I/DEBUG(524): bed6a300 6c64204e
10-08 17:34:06.775: I/DEBUG(524): bed6a304 65657266
10-08 17:34:06.775: I/DEBUG(524): bed6a308 01f86700 [heap]
10-08 17:34:06.775: I/DEBUG(524): bed6a30c 406f6a2c /system/lib/libskia.so
10-08 17:34:06.775: I/DEBUG(524): bed6a310 406c4ecc /system/lib/libskia.so
10-08 17:34:06.775: I/DEBUG(524): bed6a314 3ff00000
10-08 17:34:06.775: I/DEBUG(524): bed6a318 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a31c 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a320 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a324 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a328 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a32c 01c9aa08 [heap]
10-08 17:34:06.775: I/DEBUG(524): bed6a330 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a334 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a338 00000000
10-08 17:34:06.775: I/DEBUG(524): bed6a33c 3ff00000
10-08 17:34:06.775: I/DEBUG(524): bed6a340 60d00000
10-08 17:34:06.775: I/DEBUG(524): bed6a344 60e42ff0
10-08 17:34:06.775: I/DEBUG(524): bed6a348 014bb000
10-08 17:34:06.775: I/DEBUG(524): bed6a34c 400e74f4
10-08 17:34:06.775: I/DEBUG(524): bed6a350 01bc24b0 [heap]
10-08 17:34:06.775: I/DEBUG(524): bed6a354 400e7550
10-08 17:34:06.775: I/DEBUG(524): bed6a358 01f74458 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a35c 400e7528
10-08 17:34:06.780: I/DEBUG(524): bed6a360 00000010
10-08 17:34:06.780: I/DEBUG(524): bed6a364 400e74f4
10-08 17:34:06.780: I/DEBUG(524): bed6a368 01f74460 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a36c 00000000
10-08 17:34:06.780: I/DEBUG(524): bed6a370 bed6a584 [stack]
10-08 17:34:06.780: I/DEBUG(524): bed6a374 400b3ba9 /system/lib/libc.so
10-08 17:34:06.780: I/DEBUG(524): bed6a378 0211c9a0 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a37c 020d499c [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a380 000097a0 /system/bin/app_process
10-08 17:34:06.780: I/DEBUG(524): bed6a384 00004000
10-08 17:34:06.780: I/DEBUG(524): bed6a388 01d087b8 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a38c 400e7560
10-08 17:34:06.780: I/DEBUG(524): bed6a390 01dc6ef8 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a394 400e7528
10-08 17:34:06.780: I/DEBUG(524): bed6a398 01fd5378 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a39c 400e7580
10-08 17:34:06.780: I/DEBUG(524): bed6a3a0 01ddafa8 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3a4 01ddb008 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3a8 01ed4568 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3ac 400e7580
10-08 17:34:06.780: I/DEBUG(524): bed6a3b0 00000068
10-08 17:34:06.780: I/DEBUG(524): bed6a3b4 400e74f4
10-08 17:34:06.780: I/DEBUG(524): bed6a3b8 01ed4570 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3bc 00000014
10-08 17:34:06.780: I/DEBUG(524): bed6a3c0 00000000
10-08 17:34:06.780: I/DEBUG(524): bed6a3c4 400b3ba9 /system/lib/libc.so
10-08 17:34:06.780: I/DEBUG(524): bed6a3c8 00000000
10-08 17:34:06.780: I/DEBUG(524): bed6a3cc 01ae77d8 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3d0 01fa7160 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3d4 01fd7d2c [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3d8 00000009
10-08 17:34:06.780: I/DEBUG(524): bed6a3dc 4dfa26b2 /dev/ashmem/dalvik-heap (deleted)
10-08 17:34:06.780: I/DEBUG(524): bed6a3e0 01fa7158 [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3e4 01fd7d2c [heap]
10-08 17:34:06.780: I/DEBUG(524): bed6a3e8 00000009
10-08 17:34:06.780: I/DEBUG(524): bed6a3ec 400b3b95 /system/lib/libc.so
Run Code Online (Sandbox Code Playgroud)
11月30日更新:
我还有很长的路要把它缩小到一个简单的测试用例,但我已经将上面的SIGSEGV复制到从简单的webview应用程序加载的2个HTML页面.webview只是启动并加载:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html
这些页面相互链接,并不一定会在第一个视图上崩溃,但最终它们会在Android 4.1.1模拟器和我的Galaxy Nexus(4.1.1)上100%崩溃.请注意,帖子标题是错误的 - 这肯定不是S3.
有趣的是,
- 在我的真实应用程序中使用webview,重复加载1页(crash.html或任何沉重的HTML5页面)足以导致SIGSEGV.
- 使用这个简单的webview应用程序进行测试,这两个页面需要相互崩溃 - 只需重复加载1页就不会死亡.
- 在Android 4.1.1网页浏览器中加载页面,即使是2页也不够 - 它会死掉但需要很多页面.
在错误位置方面,崩溃时有不同的堆栈跟踪,一些与样式表有关,另一些与HTMLImageElement的析构函数有关.Android 2.x,iOS,任何其他浏览器都坚如磐石.
Javascript更改了DOM,这似乎足以导致崩溃......但为什么呢?
乍一看,这让我觉得垃圾收集问题 - 我的应用程序会比普通的webview应用程序更早地收集垃圾,因为它在其他地方使用了更多的内存.但是,我没有收到内存错误消息.我将继续努力缩小范围,但任何有任何想法如何继续或可能是什么问题的人都真正拥有我永恒的永恒感情.
测试应用代码:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip
测试应用APK:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk
所有HTML资源:?
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip
Test App的启动代码:
public class MainActivity extends Activity {
private WebView webView;
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
webView = (WebView) findViewById(R.id.webView1);
webView.getSettings().setJavaScriptEnabled(true);
webView.setWebViewClient(new WebViewClient());
webView.setWebChromeClient(new WebChromeClient());
webView.loadUrl("http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html");
}
}
Run Code Online (Sandbox Code Playgroud)
2月3日更新:
问题似乎是由于webkit动画在页面关闭时仍然是动画的.我将一次崩溃缩小到一个"myblink"标签:
.myblink{-webkit-animation-name:"anime-blink";-webkit-animation-duration:1.2s;-webkit-animation-timing-function:ease-in-out;-webkit-animation-iteration-count:infinite}
@-webkit-keyframes "anime-blink"{0%{opacity:0}
20%{opacity:1}
60%{opacity:1}
100%{opacity:0}
}
Run Code Online (Sandbox Code Playgroud)
当且仅当文本页面使用"myblink"标记时,在文本页面和(无CSS)画布页面之间循环的测试才会崩溃.
我谦虚的假设是:
[主动webkit-animation的解构器] + [同时加载下一页重载] + [计时运气不好] = [内存损坏]
我说这是因为,我可能会遗漏一些东西,动画的内容似乎几乎无关紧要.我试过了:
…but it would always crash. The only thing that would stop the crashing was to turn off animation looping and also shorten the animation-duration - i.e. crashing would stop if the animation was finished before the page was closed.
For now I've worked around the crash in-game by converting in-game animations to a completely canvas-based solution ;^^ Drastic, I know. So I won't be investigating further for a while, but still I would so love to narrow this down to a specific piece of webkit source code.
Side note: I'd like to give a shoutout to:
https://www.codeaurora.org/forums/viewtopic.php?t=450
...which is either the same issue or something very similar.
Update Nov 19th:
The original server was taken offline, so have placed the above test code in Dropbox:
https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip
(Note that url in CrashApp application has to be changed to wherever you put the HTML pages)
我正在玩你的crashApp.
使用设备; ■夏普ISW16SH■LG optimus Vu L-06D(3~10页后甚至无法存活)
这些是我经常犯的错误.dlmalloc中的致命信号11(SIGSEGV)堆积记忆腐蚀
显然,存在内存分配或双重释放问题.而且这不是可以解决的问题.(除非,NDK)我找到的唯一解决方案是即时热交换webview.始终在新创建的webview中加载下一页将阻止这种情况发生.但是,我似乎无法阻止记忆力下降.最终,一旦你的应用变成了一个吃怪物的记忆,Android就会罢工.
然后我开始玩两个相同的空活动类.没有xml.所以,
onCreate() {
??WebView wv = new WebView(context);
??setContentView( wv );
}
void onDestroy() {
??ViewGroup vg = (ViewGroup)game_wv.getParent();
??vg.removeView(game_wv);
??destroyWebView( game_wv );
??game_wv = null;
??super.onDestroy();
??System.gc();??//clean up what's freed in webViewLoadComplete (hopefully)
}
Run Code Online (Sandbox Code Playgroud)
我还在onPageFinished中调用了另一个gc,以确保其他活动不复存在.
public final class WvClient extends WebViewClient {
??public void onPageFinished(WebView wv, String url) {
????webViewLoadComplete(game_wv);
????System.gc();??//clean up the other activity
??}
}
Run Code Online (Sandbox Code Playgroud)
这是destroyWebView和webViewLoadComplete.我不太确定某些功能(如clearAnimation或clearDisappearingChildren)或者正确的调用顺序.我只是......扔掉那里的一切.哈
void destroyWebView( WebView wv ){
??wv.stopLoading();
//?wv.pauseTimers();
??wv.clearFormData();
??wv.clearAnimation();
??wv.clearDisappearingChildren();
??wv.clearView();
//?wv.clearCache( true );
??wv.clearHistory();
//?wv.clearMatches();
//?wv.clearSslPreferences();
??wv.destroyDrawingCache();
??wv.freeMemory();
??wv.destroy();
}
void webViewLoadComplete( WebView wv ){
//?wv.stopLoading();
//?wv.pauseTimers();
//?wv.clearFormData();
??wv.clearAnimation();
??wv.clearDisappearingChildren();
//?wv.clearView();
////wv.clearCache( true );
//?wv.clearHistory();
////wv.clearMatches();
////wv.clearSslPreferences();
??wv.destroyDrawingCache();
??wv.freeMemory();
//?wv.destroy();
}
Run Code Online (Sandbox Code Playgroud)
不知怎的,它起作用了......
认为最终的方法可能是使用NDK?
我通过禁用 html 页面 HEAD 中的格式检测解决了许多低级崩溃,包括 4.0.4 上的崩溃(这是 Google 的一位朋友建议的):
<meta name="format-detection" content="telephone=no" />
<meta name="format-detection" content="email=no" />
<meta name="format-detection" content="address=no"/>
Run Code Online (Sandbox Code Playgroud)
然而,4.1.1 更新使这些崩溃再次出现在 S3 上,这次我还没有找到解决方法。
| 归档时间: |
|
| 查看次数: |
15421 次 |
| 最近记录: |