26

私はAndroidWebViewに複雑でインタラクティブなHTML5を持っていますが、GalaxyS3を除く基本的にすべてのプラットフォームで正常に動作します。Galaxy S3（Android 4.0.4）では、5回程度に1回、ロードが完了した直後に、/ 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;
}

…多くの-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;
}
/*…*/

そして、かなり複雑なdivツリーですが、特に実験的なものはありません。ある程度のJavascriptがありますが、すべてのJavascriptをオフにしてもハングが発生するようです。

Galaxy S3が…違うという問題を抱えた人はいますか？Android 2.xデバイスでこの問題が発生することはなく、4.1.1を実行しているGalaxyNexusでも特に問題はないようです。私はこれまでStackOverflowに書き込みたくありませんでしたが、これは本当に私を悩ませています...

「AndroidWebViewsigsegvcrash」と「4.0.4WebViewsigsegvcrash」で検索すると、いくつかの問題が発生しますが、次のようになります。

クラッシュのいくつかはmemoryfree（）の間に発生しているので、クラッシュの前後に物事が解放されていることを知っています。私の直感では、レンダリングの途中で解放されるべきではないものもあります。純粋な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

11月30日更新：

これを単純なテストケースに絞り込むにはまだ長い道のりがありますが、上記のSIGSEGVをプレーンなWebビューアプリからロードされた2つのHTMLページに複製することができました。Webビューが起動して読み込まれるだけです。

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html

ページは相互にリンクしており、最初のビューで必ずしもクラッシュするわけではありませんが、最終的にはAndroid4.1.1エミュレーターとGalaxyNexus（4.1.1）で100％クラッシュします。投稿のタイトルが間違っていることに注意してください。これは間違いなくS3だけではありません。

興味深いのは、
-実際のアプリ内でWebビューを使用して、1ページ（crash.htmlまたは重いHTML5ページ）を繰り返しロードするだけで、SIGSEGVが発生することです。
-このプレーンなWebビューアプリをテストに使用すると、2つのページが互いにクラッシュする必要があります-1つのページを繰り返しロードするだけでは死にません。
-Android 4.1.1 Webブラウザーにページをロードしますが、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

アプリのスタートアップコードをテストします。

 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");
}

 }

2月3日更新：

この問題は、ページを閉じたときにまだアニメーション化されているwebkitアニメーションが原因で発生しているようです。1つのクラッシュを1つの「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}
}

テキストページと（CSSなしの）キャンバスページの間を循環するテストは、テキストページが「myblink」タグを使用した場合にのみクラッシュします。

私の謙虚な仮説は次のとおりです。

[アクティブなWebkitアニメーションのデコンストラクター]+[同時に読み込まれる重い次のページ]+[タイミングの不運]=[メモリの破損]

これは、何かが足りない可能性があるため、アニメーションの内容がほとんど無関係に見えるためです。私は試した：

  • 不透明度を常に1に等しくする
  • 不透明度を位置変換に置き換える
  • アニメーションのループをオフにする
  • テキストの代わりに点滅タグを画像に配置する
  • キーフレームで遊んで

…しかし、それは常にクラッシュします。クラッシュを停止する唯一の方法は、アニメーションのループをオフにし、アニメーションの期間を短縮することでした。つまり、ページを閉じる前にアニメーションが終了すると、クラッシュが停止します。

今のところ、ゲーム内のアニメーションを完全にキャンバスベースのソリューションに変換することで、ゲーム内のクラッシュを回避しました;^^抜本的です。そのため、しばらくはこれ以上調査しませんが、それでも、これを特定のWebkitソースコードに絞り込みたいと思います。

補足：私は以下に叫びたいです：

https://www.codeaurora.org/forums/viewtopic.php?t=450

...これは同じ問題か非常によく似た問題のいずれかです。

11月19日更新：

元のサーバーはオフラインにされたため、上記のテストコードをDropboxに配置しました。

https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip

（CrashAppアプリケーションのURLは、HTMLページを配置する場所に変更する必要があることに注意してください）

4

7 に答える 7

6

私はあなたのcrashAppで遊んでいました。

デバイスの使用; ■SHARP ISW16SH ■LG optimus Vu L-06D (3～10ページで生き残れない)

これらは私がよく経験するエラーです。致命的なシグナル 11 (SIGSEGV) dlfree でのヒープ メモリの破損 dlmalloc でのヒープ メモリの破損

明らかに、メモリ割り当てまたは二重解放の問題があります。そして、それは修正できるものではありません。（NDKを除く）私が見つけた唯一の解決策は、その場でWebビューをホットスワップすることです。新しく作成された webview で常に次のページを読み込むと、これが発生しなくなります。ただし、メモリの低下を止めることはできないようです。アプリがメモリを食い尽くす怪物に成長すると、最終的には Android がストライキを起こします。

次に、2 つの同一の空のアクティビティ クラスで遊んでみます。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)
}

また、他のアクティビティが完全になくなったことを確認するために、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
　　}
}

これが 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();
}

どういうわけか、それは働いた...

究極の方法は NDK を使用することだと思いますか?

于 2012-12-27T02:22:07.077 に答える
1

この問題を抱えているのはあなただけではありません。私はグーグルをしていて、この他の人のようにhttp://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy- s3-only / 77/181155S3のストックナビゲーターにhtml5のバグがあり（さまざまな国のさまざまなROMで試してみました）、試したすべてのS3がクラッシュしました。クロームで試してみましたが、美しく動作します。ストックナビゲーターにバグがあると思います。

于 2013-02-25T19:07:14.673 に答える
1

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"/>

ただし、4.1.1 の更新により、これらのクラッシュが S3 に戻ってきました。今回は回避策がわかりませんでした。

于 2012-11-27T18:15:19.907 に答える
0

http://fgnass.github.io/spin.js/を使用して、この問題 (または少なくとも非常に似た問題) を抱えています。

それをページから取り出すと、問題はありません。また、Android 4.0 および 4.1 でも発生するようですが、4.3 では発生しません。

それを回避し、使用する spin.js スピナー以外のものを見つける以外に解決策を見つけることができませんでした。間違いなくAndroidの問題のようです。私をいらいらさせているのは、それがより広まっているようには見えないということです.

于 2013-10-17T15:57:31.583 に答える
0

少し違うが同じ症状があったので、私のケースと一緒にチャイムを鳴らしてください。静的変数*を介してデバイスのローテーション全体で WebView インスタンスを維持していますが、私の間違いは、WebView.restoreState必要のないときにそのインスタンスを呼び出していました。

エラーコード:

private static FrameLayout _rootView;
@InjectView(R.id.main_webview)
WebView _webView;

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    boolean inflatingNow = _rootView == null;
    if (inflatingNow) {
        Container.Log.d(TAG, "onCreateView: rootView null. Recreating views");
        _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false);
    }
    else {
        Container.Log.d(TAG, "onCreateView: reusing previousely created views");
        ViewHelper.detachFromParent(_rootView); // Detaching from old container 
    }
    ButterKnife.inject(this, _rootView); // Will assign the _webView variable

    if (inflatingNow) {
        configureWebView(_webView);
    }
    if (savedInstanceState != null) {
        _webView.restoreState(savedInstanceState);
    }
    return _rootView;
}

固定コード:

private static FrameLayout _rootView;
@InjectView(R.id.main_webview)
WebView _webView;

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)  {
    boolean inflatingNow = _rootView == null;
    if (inflatingNow) {
        Container.Log.d(TAG, "onCreateView: rootView null. Recreating views");
        _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false);
    }
    else {
        Container.Log.d(TAG, "onCreateView: reusing previousely created views");
        ViewHelper.detachFromParent(_rootView); // Detaching from old container 
    }
    ButterKnife.inject(this, _rootView);

    if (inflatingNow) {
        configureWebView(_webView);
        if (savedInstanceState != null) {
            _webView.restoreState(savedInstanceState);
        }
    }
    return _rootView;
}

*) 補足として、これはデバイス ローテーションのフットプリントを削減するための良いアプローチだと思います。追加のボーナスは、ユーザーがいた位置で webview がスクロールされたままになることです。ページのリロードは必要ありません。このアプローチは、特定のアクティビティ (シングルトン) で一度に 1 つの場所でのみフラグメントを使用していることを意味することに注意してください。

于 2014-12-11T09:36:14.007 に答える