1

android.com によると、Java で作業している場合、使用できる最大メモリは 16 MB です。少なくとも、それはデバイスがサポートするはずのものです。古い電話を使用している場合は、それ以上取得できないことに気付くでしょう。代わりに OutOfMemoryError が返されます。NDK を使用して同じことをしている場合は違います。私のアプリケーションでは、50MB以上を取得しようとしていますが、これまでのところAndroidはそれで問題ありませんでした.

私はandroid.comでそれに関連するものを見つけていません。

Javaのように制限はありますか？

はいの場合: 制限は何ですか?

「いいえ」の場合: そのための適切な値は何ですか?

問題は、そのサイズに応じてコードをビルドする必要があることです。

[編集:] Seva Alekseyev が提案していたことを試してみました。

     root@android:/ # ulimit -a
     ulimit -a
     time(cpu-seconds)    unlimited
     file(blocks)         unlimited
     coredump(blocks)     0
     data(KiB)            unlimited
     stack(KiB)           8192
     lockedmem(KiB)       64
     nofiles(descriptors) 1024
     processes            7806
     flocks               unlimited
     sigpending           7806
     msgqueue(bytes)      819200
     maxnice              40
     maxrtprio            0
     resident-set(KiB)    unlimited
     address-space(KiB)   unlimited
     root@android:/ # ulimit -v
     ulimit -v
     unlimited
     root@android:/ #

(「alloc」または「new」を使用して) 要求しているメモリは、仮想メモリ (ulimit -v) です。それで、私がどれだけ得できるかを把握する機会はありませんか?!

4

1 に答える 1

2

次の 3 種類のメモリ制限が適用されます。

1) マルチタスク時にシステムの応答性を維持するために設定された人為的な制限 -- VM ヒープ制限は、この主な例です。ulimit は、OS がさらに制限を加えるための潜在的なメカニズムですが、Android デバイスで制限的に使用されているのは見たことがありません。

2) 利用可能な実メモリに基づく物理的な制限。開発/テストしているベースライン デバイスが必要であり、他のプロセス (バックグラウンド サービス、他のアプリ) にもメモリが必要であると想定してかなり積極的にする必要があります。また、OS が使用するメモリは OS のバージョンによって異なります (時間の経過とともに増加する傾向があります)。Stock Android はスワップしないので、やりすぎると死にます。考えられるシナリオの 1 つは、オーディオ プレーヤーと電話アプリがバックグラウンドで動作する Nexus One (512MB RAM) と、余裕を持たせるために別の 100MB の物理メモリを消費する「バルーン」サービスです。この構成では、まだ 100MB を超える容量が利用可能です。

3) アドレス空間に基づく仮想メモリの制限。ストック android ではメモリのオーバーコミットが許可されているため、512MB の RAM を搭載したデバイスで (mmap などを介して) 1GB の仮想割り当てを要求しても点滅しません。これは多くの場合、非常に便利です。ただし、メモリに触れると、物理メモリに持ち込む必要があります。物理メモリに読み取り専用ページがある場合は、それらを排出できますが、すぐに使い果たしてしまい、スワップがなければ死んでしまいます。(組み合わせとオーバーコミットとスワップなしは、malloc が null を返すような回復可能なエラーではなく、メモリ不足の状況でプロセスの死に直接つながります)。

最後に、calloc/malloc/new が物理的な割り当てを必要とするかどうかはアロケータに依存することに注意してください。したがって、100 MB 未満の標準的な適切に割り当てられた割り当てを扱っている場合、おそらく問題はありませんが、テストしてください! メモリをマップしたい大量のデータを扱っている場合、mmap は慎重に使用すればあなたの味方になり、PROT_READ のみと一緒に使用すれば最高の味方になります。また、100 MB を超える物理メモリ割り当てを扱っている場合は、最新のデバイスで非常にうまく動作すると予想されますが、ベースラインを慎重に定義し、テスト、テスト、テストする必要があります。ハエは一般的に不可能です。

もう 1 つ注意: APP_CMD_LOW_MEMORY が存在し、キャッシュをパージするのに最適な場所ですが、命を救うために間に合うように呼び出されるという保証はありません。全体像は全く変わりません。

于 2012-12-05T17:38:38.040 に答える