largeHeapをtrueに設定する利点は何ですか？

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>

それを使用するための長所と短所を親切に提案します。

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

ここのパーティーには遅すぎますが、とにかく0.02ドルを提供します。
これ android:largeHeap="true"を説明するグーグルからの抜粋を使用するのは良い考えではありません、

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

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

更新

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

アップデート2

ここではいくつかある対処するためのヒントをout of memory errors

1）使用のアンドロイドが与えるこれらのコールバックonLowMemory、onTrimMemory(int) および（ピカソ、グライド、フレスコ画のような画像のキャッシュをクリア....）あなたがそれらについてもっと読むことができ、こことここ
2）あなたのファイルを圧縮（画像、PDF）
3）について読みますここでビットマップをより効率的に処理する方法
4）プロダクションプッシュの前にlintを定期的に使用して、コードが滑らかでかさばらないようにします。

これは非常に効果的な質問だと思います。このオプションを使用することの利点と欠点について詳しく説明します。

あなたが得るもの：

• 明らかに、ヒープが大きくなるため、のリスクが減少しますOutOfMemoryError。

失うもの：

• 一部のフレームが失われる可能性があり、目に見えるヒッチが発生する可能性があります。ヒープが大きいほど、ガベージコレクションに時間がかかります。ガベージコレクターは基本的に、オブジェクトのライブセット全体をトラバースする必要があるためです。通常、ガベージコレクションの一時停止時間は約5ミリ秒であり、数ミリ秒は大した問題ではないと思うかもしれません。しかし、ミリ秒ごとのカウント。Androidデバイスは16ミリ秒ごとに画面を更新する必要があり、GC時間が長いとフレーム処理時間が16ミリ秒の障壁を超えてしまい、目に見えるヒッチが発生する可能性があります。

• また、アプリの切り替えが遅くなります。Androidシステムは、最も最近使用されていないプロセスからLRUキャッシュ内のプロセスを強制終了する可能性がありますが、最もメモリを集中的に使用するプロセスについても考慮しています。したがって、より大きなヒープを使用すると、バックグラウンドで実行されているプロセスが強制終了される可能性が高くなります。つまり、ユーザーが他のアプリから自分のアプリに切り替えようとすると、より長い時間がかかる可能性があります。また、アプリがより多くのメモリを必要とするため、プロセスがフォアグラウンドの場合、他のバックグラウンドプロセスもキックアウトされる可能性が高くなります。アプリから他のアプリへの切り替えにも時間がかかります。

結論：

largeHeapオプションの使用はできるだけ避けてください。気づきにくいパフォーマンスの低下とユーザーエクスペリエンスの低下を招く可能性があります。

ほぼ50クラスのアプリがあります

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

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

実際にandroid：largeHeapは、アプリに割り当てるメモリを増やすための手段です。

このフラグを使用する必要性の明確な定義はありません。より多くのメモリが必要な場合-Androidはメモリを増やすためのツールを提供します。しかし、使用の必要性、あなた自身を定義します。

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

「準備する」とは、その可能性を考慮して設計し、onStop()とonResume()メソッドをできるだけ効率的に記述しながら、ユーザーにシームレスな外観を提供する方法で関連するすべての状態を保存および復元できるようにすることを意味します。

：そこは、このパラメータに関連する3つの方法がありmaxMemory()、getMemoryClass()とgetLargeMemoryClass()。

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

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

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

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

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

この以前の投稿には、largeHeapいくつかの特定のAndroidデバイスでパラメーターを使用した場合と使用しない場合に使用できるヒープの量の例だけでなく、パラメーターの説明も含まれています。

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

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

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

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