増やす - android:supportsrtl




largeHeapをtrueに設定する利点は何ですか? (4)

以下に示すように、 android:largeHeap="true" 設定しているほぼ50のクラスを持つアプリがあります。 これは良い習慣ですか?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

それを使用することの利点と欠点をご提案ください。

メモリの問題が発生しているので、この質問をします。


私はほぼ50のクラスを持つアプリを持っています

これが大きな問題になるとは思いません。 outOfMemoryエラーが発生する理由は、通常、アプリ内の多くの画像またはそのようなものへの読み込みです。 大きなヒープを使用することに不満がある場合は、メモリの使用を最適化する方法を見つける必要があります。

Picasso UIL Glide などの画像読み込みライブラリを使用することもでき UIL 。 それらはすべて、メモリおよび/またはディスクに画像をキャッシュする機能を備えています。


ここでのパーティーには遅すぎますが、とにかく0.02 $を提供します。
android:largeHeap="true" を使用するのは得策ではありません。これ を説明するGoogleからの抜粋、

ただし、大きなヒープを要求する機能は、より多くのRAMを消費する必要性を正当化できる小さなアプリセット(大きな写真編集アプリなど)のみを対象としています。 メモリが不足しているため、簡単な修正が必要なため、大きなヒープを要求しないでください。メモリの割り当て場所と保持する必要がある理由がわかっている場合にのみ使用してください。 ただし、アプリが大きなヒープを正当化できると確信している場合でも、可能な限りリクエストすることは避けてください。 タスクの切り替えやその他の一般的な操作を実行すると、ガベージコレクションに時間がかかり、システムパフォーマンスが低下する可能性があるため、余分なメモリを使用すると、ユーザーエクスペリエンス全体がますます損なわれます。

ここにドキュメントの完全なリンクがあります developer.android.com/training/articles/memory.html

更新

out of memory errors 極度に作業し out of memory errors 後、私はこれをマニフェストに追加してoom問題を回避することは罪ではなく、@ Miladが以下に指摘するように、アプリの通常の動作には影響しないと言います

更新2

out of memory errors に対処するためのヒントを いくつか 紹介し out of memory errors

1)アンドロイドが onLowMemory onTrimMemory(int) を与えるこれらのコールバックを使用し、(picasso、glide、fresco ....)のような画像のキャッシュをクリアし here
2)ファイルを圧縮する(画像、pdf)
3) here ビットマップをより効率的に処理する方法について読む
4)プロダクションプッシュの前に定期的にlintを使用して、コードが滑らかでかさばらないようにします


アプリケーションのプロセスを大きなDalvikヒープで作成するかどうか。 これは、アプリケーション用に作成されたすべてのプロセスに適用されます。 プロセスにロードされた最初のアプリケーションにのみ適用されます。 共有ユーザーIDを使用して複数のアプリケーションがプロセスを使用できるようにしている場合、すべてのアプリケーションが一貫してこのオプションを使用する必要があります。そうしないと、予測できない結果が生じます。

ほとんどのアプリはこれを必要とせず、代わりに全体的なメモリ使用量を減らしてパフォーマンスを向上させることに焦点を合わせます。 一部のデバイスは使用可能なメモリの合計によって制約されるため、これを有効にしても、使用可能なメモリが一定に増加することは保証されません。


大量のメモリを使用(および保持)する 必要がある 場合は、はい、 android:largeHeap="true" を使用できます。 ただし、使用する場合は、他のアプリがフォアグラウンドにあるときはいつでも、アプリをメモリからフラッシュする準備をする必要があります。

「準備する」とは、 onStop() および onResume() メソッドが可能な限り効率的に記述されるように、その可能性を onStop() して設計することを意味します。ユーザーへのシームレスな外観。

このパラメーターに関連する3つのメソッド、 maxMemory()getMemoryClass() 、および getLargeMemoryClass() ます。

ほとんどのデバイスでは、 maxMemory() はデフォルトで getMemoryClass() と同様の値を getMemoryClass() ますが、後者はメガバイトで表され、前者はバイトで表されます。

largeHeap パラメーターを使用すると、 maxMemory() はデバイス固有のより高いレベルに増加しますが、 getMemoryClass() は同じままです。

getMemoryClass() はヒープサイズを制限しませんが、実行している特定のデバイスの制限内でアプリを 快適 かつ 互換 的に機能させる場合に使用するヒープの量を示します。

対照的に、 maxMemory() はヒープサイズを制限するため、値を増やすことで追加のヒープにアクセスできます largeHeap はその値を増やします。 ただし、増加するヒープの量はまだ制限されており、その制限はデバイス固有です。つまり、アプリが実行できるデバイスのリソースに応じて、アプリで使用できるヒープの量は異なります。 したがって、 largeHeap を使用する largeHeap は、アプリがすべての注意を放棄して食べ放題のビュッフェを largeHeap はありません。

アプリは、メソッド getLargeMemoryClass() を呼び出して largeHeap パラメーターを使用することにより、特定のデバイスで使用可能になるメモリー量を正確に検出できます。 返される値はメガバイト単位です。

この以前の投稿には、 largeHeap パラメーターの説明と、いくつかの特定のAndroidデバイスで、使用量の有無にかかわらず使用可能なヒープ量の例がいくつか含まれています。

Androidでアプリケーションのヒープサイズを検出する

このパラメーターをtrueに設定して、独自のアプリをデプロイしていません。 ただし、開発中にのみ実行される一連の最適化関連パラメーターをコンパイルするために、アプリの1つにメモリを集中的に使用するコードがあります。 このコードの実行中にメモリー不足エラーを回避するために、開発時にのみ largeHeap パラメーターを追加します。 ただし、アプリをデプロイする前にパラメーター(およびコード)を削除します。





android-largeheap