Quels sont les avantages de définir largeHeap sur true?

J'ai une application avec près de 50 classes que je suis en train de définir android:largeHeap="true", comme on peut le voir ci-dessous. Est-ce une bonne pratique?

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

Veuillez suggérer les avantages et les inconvénients de son utilisation.

J'ai des problèmes de mémoire, c'est pourquoi je pose cette question.

Bien trop tard pour la fête ici, mais je vais quand même offrir mon 0,02 $.
Ce n'est pas une bonne idée d'utiliser android:largeHeap="true" voici l'extrait de google qui l'explique,

Cependant, la possibilité de demander un gros tas n'est destinée qu'à un petit ensemble d'applications qui peuvent justifier la nécessité de consommer plus de RAM (comme une grande application de retouche photo). Ne demandez jamais un gros tas simplement parce que vous n'avez plus de mémoire et que vous avez besoin d'une solution rapide. Vous ne devriez l'utiliser que lorsque vous savez exactement où toute votre mémoire est allouée et pourquoi elle doit être conservée. Pourtant, même si vous êtes convaincu que votre application peut justifier le gros tas, vous devez éviter de la demander dans la mesure du possible. L'utilisation de la mémoire supplémentaire se fera de plus en plus au détriment de l'expérience utilisateur globale, car le garbage collection prendra plus de temps et les performances du système peuvent être plus lentes lors du changement de tâche ou lors de l'exécution d'autres opérations courantes.

voici le lien complet de la documentation https://developer.android.com/training/articles/memory.html

METTRE À JOUR

Après avoir travaillé atrocement avec, out of memory errorsje dirais que l'ajout de ceci au manifeste pour éviter le problème oom n'est pas un péché, comme @Milad le souligne ci-dessous, cela n'affecte pas le fonctionnement normal de l'application

MISE À JOUR 2

Voici quelques conseils pour faire face àout of memory errors

1) Utilisez ces rappels fournis par Android onLowMemory, onTrimMemory(int) et effacez le cache d'image comme (picasso, glide, fresco ....) vous pouvez en savoir plus à leur sujet ici et ici
2) compresser vos fichiers (images, pdf)
3) lire à propos comment gérer le bitmap plus efficacement ici
4) Utilisez régulièrement des peluches avant les poussées de production pour vous assurer que le code est élégant et peu encombrant

Je pense que c'est une question très efficace, et permettez-moi d'ajouter quelques détails sur les avantages et les inconvénients de l'utilisation de cette option.

Ce que vous obtenez :

• De toute évidence, vous obtenez un tas plus grand, ce qui signifie une diminution du risque de OutOfMemoryError.

Ce que vous perdez:

• Vous risquez de perdre certains cadres, ce qui peut provoquer un accrochage visible . Un tas plus grand rend les garbage collection plus longs. Parce que le garbage collector doit essentiellement parcourir l'ensemble de votre ensemble d'objets en direct. Habituellement, le temps de pause du ramasse-miettes est d'environ 5 ms, et vous pouvez penser que quelques millisecondes ne sont pas un gros problème. Mais chaque milliseconde compte. L'appareil Android doit mettre à jour son écran toutes les 16 ms et un temps GC plus long pourrait pousser votre temps de traitement d'image au-dessus de la barrière de 16 millisecondes, ce qui peut provoquer un accrochage visible.

• Le changement d'application deviendra également plus lent . Le système Android peut tuer les processus dans le cache LRU en commençant par le processus le moins récemment utilisé, mais en tenant également compte des processus les plus gourmands en mémoire. Donc, si vous utilisez un tas plus grand, votre processus sera plus susceptible d'être tué lorsqu'il est en arrière-plan, ce qui signifie que cela peut prendre plus de temps lorsque les utilisateurs souhaitent passer d'autres applications à la vôtre. De plus, d'autres processus en arrière-plan seront plus susceptibles d'être expulsés lorsque votre processus est au premier plan, car votre application nécessite une plus grande mémoire. Cela signifie que le passage de votre application à d'autres applications prend également plus de temps.

Conclusion :

Évitez largeHeapautant que possible d' utiliser l' option. Cela peut vous faire perdre des performances difficiles à remarquer et une mauvaise expérience utilisateur.

J'ai une appli avec près de 50 cours

Je ne pense pas que cela pose beaucoup de problème. La raison pour laquelle vous avez l'erreur outOfMemory est généralement de charger trop d'images dans votre application ou quelque chose du genre. Si vous n'êtes pas satisfait d'utiliser un gros tas, vous devez trouver un moyen d'optimiser l'utilisation de la mémoire.

Vous pouvez également utiliser des bibliothèques de chargement d'images telles que Picasso , UIL ou Glide . Tous ont la fonction de mise en cache d'image en mémoire et / ou sur disque.

En fait Android: largeHeap est l'instrument pour augmenter la mémoire allouée à l'application.

Il n'y a pas de définition claire de la nécessité d'utiliser cet indicateur. Si vous avez besoin de plus de mémoire, Android vous fournit un outil pour l'augmenter. Mais nécessité d'utiliser, vous vous définissez.

Si vous devez utiliser (et conserver) une grande quantité de mémoire, alors oui, vous pouvez et devez utiliserandroid:largeHeap="true" . Mais si vous l'utilisez, vous devez être prêt à vider votre application de la mémoire chaque fois que d'autres applications sont au premier plan.

Par «soyez prêt», je veux dire que vous devez concevoir pour cette probabilité, de sorte que vos méthodes onStop()et onResume()soient écrites aussi efficacement que possible, tout en garantissant que tout état pertinent est enregistré et restauré d'une manière qui présente une apparence transparente à l'utilisateur.

Il existe trois méthodes qui se rapportent à ce paramètre: maxMemory(), getMemoryClass()etgetLargeMemoryClass() .

Pour la plupart des appareils, maxMemory()représentera une valeur similaire àgetMemoryClass() par défaut, bien que la dernière soit exprimée en mégaoctets, tandis que la première est exprimée en octets.

Lorsque vous utilisez le largeHeapparamètre, maxMemory()sera augmenté à un niveau supérieur spécifique à l'appareil, tandis quegetMemoryClass() restera le même.

getMemoryClass()ne limite pas votre taille tas, mais il vous indique la quantité de vous tas devriez utiliser si vous voulez que votre application à la fonction confortablement et compatiblement dans les limites du dispositif particulier sur lequel vous utilisez.

maxMemory(), En revanche, ne contraignez votre taille du tas, et ainsi vous accès à un gain tas supplémentaire en augmentant sa valeur, et largeHeapfait augmenter cette valeur. Cependant, l'augmentation de la quantité de tas est toujours limitée et cette limite sera spécifique à l'appareil, ce qui signifie que la quantité de tas disponible pour votre application variera en fonction des ressources de l'appareil sur lequel votre application s'exécute. Ainsi, l'utilisation largeHeapn'est pas une invitation pour votre application à abandonner toute prudence et à se frayer un chemin à travers le buffet à volonté.

Votre application peut découvrir exactement la quantité de mémoire rendue disponible sur un appareil particulier en utilisant le largeHeapparamètre en appelant la méthode getLargeMemoryClass(). La valeur renvoyée est en mégaoctets.

Cet article précédent comprend une discussion sur la largeHeap paramètre, ainsi qu'un certain nombre d'exemples des quantités de tas disponibles avec et sans son utilisation, sur plusieurs appareils Android spécifiques:

Détecter la taille du tas d'application dans Android

Je n'ai déployé aucune de mes propres applications avec ce paramètre défini sur true. Cependant, j'ai du code gourmand en mémoire dans l'une de mes applications pour compiler un ensemble de paramètres liés à l'optimisation, qui ne s'exécute que pendant le développement. J'ajoute le largeHeapparamètre uniquement pendant le développement, afin d'éviter les erreurs de manque de mémoire lors de l'exécution de ce code. Mais je supprime le paramètre (et le code) avant de déployer l'application.

Si les processus de votre application doivent être créés avec un grand tas Dalvik. Cela s'applique à tous les processus créés pour l'application. Il s'applique uniquement à la première application chargée dans un processus; si vous utilisez un ID utilisateur partagé pour permettre à plusieurs applications d'utiliser un processus, elles doivent toutes utiliser cette option de manière cohérente ou elles auront des résultats imprévisibles.

La plupart des applications ne devraient pas en avoir besoin et devraient plutôt se concentrer sur la réduction de leur utilisation globale de la mémoire pour améliorer les performances. L'activation de cette option ne garantit pas non plus une augmentation fixe de la mémoire disponible, car certains périphériques sont limités par leur mémoire totale disponible.