0

私はちょうどこの問題に遭遇しました。Android アプリケーション内にXWalkView ( Crosswalk WebView) があります。XWalkView 内で、いくつかの AJAX リクエストを作成します。問題は、リクエストの実行中に Java ガベージ コレクターがメモリを解放していることです。そのため、リクエストを終了できません。

AJAX 部分に関しては、 promiseを使用して AJAX リクエストを実行するための単純なライブラリであるqwestを使用しています。

このための Java コードは非常に単純です。これが問題だとは思いません。

webView = (XWalkView)findViewById(R.id.walk_view);
webView.setResourceClient(new MyAppWebViewClient(webView));
webView.setWillNotCacheDrawing(true);
webView.load("file:///android_asset/www/index.html", null);

を追加して、willNotCacheDrawingより多くのメモリを解放して、リクエストを完了できるようにしましたが、これはあまり役に立ちません。

MyAppWebViewClientは のサブクラスですがXWalkResourceClient、PDF がロードされたときに別のアクションをトリガーするだけで、それほど多くのことはしていません。この問題は、自分の ResourceClient を使用しない場合にも発生します。

HTML / JavaScript の部分は非常にシンプルで、ダウンロードは 0.5MB 以下で、次のようなリクエストが必要です。

qwest.get('my.server.com/api')
 .then(function(xhr, response) {
    // do work with response
    // to bad it never reaches this
 })
 .catch(function(xhr, response, e) {
    // I just get a timeout here,
    // there is no way the server is timing out,
    // it works perfectly on iOS, Web and any other platform
 });

これはガベージ コレクターと関係があると考えました。これは、メモリ モニターを見ると、リクエストの実行中に次のように発生するためです。

仕事中のガベージコレクター？

メモリの最初の「上昇」はリクエストの開始時であり、メモリ使用量が再び安定するとすぐに、リクエストは失敗します。突然の低下は、ガベージ コレクターが AJAX 要求に割り当てたばかりのメモリを解放することだと考えました..うーん。

特にメモリ管理に関しては、私はAndroid開発にまったく慣れていません。ガベージ コレクターが 7,76 MB を超える RAM を割り当てさせないのは正常ですか? 完全なアプリとしては少し低いようです。

皆さん、何か考えはありますか？

ありがとう！

4

1 に答える 1

1

これは本当に異常ではなく、わずかに小さいですが、驚くべきことではありません。単一のプロセスで利用可能なヒープ メモリに関する詳細情報が必要な場合は、How much memory for Android processまたは Android でのメモリ管理に関する公式ドキュメント を参照してください。一般に、ヒープ サイズは非常に限られていることがわかります。

于 2015-11-24T15:14:04.013 に答える