2010-12-04 5 views
22

Je constate que la taille du tas augmente automatiquement lorsque l'application en a besoin, quelle que soit la taille maximale du tas du téléphone. Je vois aussi que la taille maximale du tas est différente en fonction de l'appareil.Deux questions sur les tailles de tas maximum et la mémoire disponible en android

Donc, ma première question est, quelles sont les tailles de tas maximales typiques sur les appareils Android? J'ai testé l'allocation de mémoire sur un téléphone qui était capable d'utiliser un tas de plus de 40 Mo alors qu'un autre a donné des erreurs OutOfMemory dans les 20 mbs. Quels sont les plus bas qui sont d'usage courant et quels sont les plus hauts sur les appareils communs? Y a-t-il une norme ou une moyenne?

La deuxième question, et la plus importante, est de savoir comment vous assurer que vous pouvez utiliser les ressources disponibles par appareil tout en évitant d'en utiliser trop. Je sais qu'il existe des méthodes telles que onLowMemory() mais celles-ci semblent ne concerner que la mémoire système entière, pas seulement le tas pour votre application spécifique.

Existe-t-il un moyen de détecter la taille maximale du tas pour le périphérique et de détecter également si la mémoire disponible du tas atteint un point bas pour votre application? Par exemple, si l'appareil n'autorise qu'un maximum de 24 Mo et que l'application est proche de cette limite d'allocation, il peut détecter et réduire l'erreur. Cependant, si l'appareil pouvait gérer confortablement plus, il serait en mesure de tirer parti de ce qui est disponible.

Merci

+3

Il implique le traitement des images et 20 Mo de mémoire est facile à utiliser avec des images. Il est tout à fait correct d'utiliser moins de mémoire et de traiter moins en même temps, mais je voudrais pouvoir laisser l'application les traiter plus rapidement si le périphérique peut le gérer. – cottonBallPaws

+4

En outre, même avec l'idée d'utiliser moins de mémoire, quel est un chapeau idéal pour essayer de rester sous? – cottonBallPaws

Répondre

8

Les premiers dispositifs ont une base par application plafond de 16MB. Les appareils ultérieurs ont augmenté cela à 24 Mo. Les appareils futurs seront probablement encore plus disponibles.

La valeur reflète la mémoire physique disponible sur le périphérique et les propriétés du périphérique d'affichage (car un écran plus grand capable d'afficher plus de couleurs nécessitera généralement des bitmaps plus grandes).

Edit: songeries supplémentaires ...

J'ai lu un article pas trop il y a longtemps que souligné que la collecte des ordures-allocataires sont la modélisation essentiellement une machine à mémoire infinie. Vous pouvez allouer autant que vous voulez et il va prendre soin des détails. Android fonctionne principalement de cette façon; vous conservez des références précises aux choses dont vous avez besoin, des références faibles/faibles à des choses que vous ne pourriez pas faire, et éliminez les références aux choses dont vous n'aurez plus jamais besoin. Le GC trie tout.

Dans votre cas particulier, vous utiliseriez des références logicielles pour garder les choses que vous n'avez pas besoin d'avoir en mémoire, mais que vous voudriez conserver s'il y a assez de place.

Cela commence à s'effondrer avec les bitmaps, en grande partie à cause de certaines décisions de conception précoce qui ont abouti au mécanisme d '"allocation externe". En outre, le mécanisme de référence souple nécessite un certain réglage - la version initiale avait tendance à tout conserver ou à tout jeter. Le tas de Dalvik est en développement actif (voir par exemple les notes sur Android 2.3 "Gingerbread", qui introduit un GC concurrent), donc j'espère que ces problèmes seront abordés dans une future version.

Edit: Mise à jour ...

Le mécanisme "d'allocation externe" est parti à 4.0 (Ice Cream Sandwich). Les données de pixel pour Bitmaps sont maintenant stockées sur le tas de Dalvik, évitant les ennuis précédents.

Des dispositifs récents (par exemple le Nexus 4) plafonnent la taille du tas à 96 Mo ou plus.

Un sens général des limites de mémoire de l'application peut être obtenu en tant que "classe de mémoire", à partir de ActivityManager.getMemoryClass(). Une valeur plus spécifique peut être obtenue à partir de la fonction java.lang.RuntimemaxMemory().

5

Voici les "normaux" (voir ci-dessous) les tailles de tas pour certains appareils spécifiques:

  • G1: 16MB
  • Moto Droid: 24MB
  • Nexus One: 32Mo
  • Viewsonic GTAB: 32MB
  • Novo7 Paladin: 60Mo

Je dis "normal" parce que certains Les versions d'Android (par exemple, CyanogenMod) permettront à un utilisateur d'ajuster manuellement la limite de tas. Le résultat peut être plus grand ou plus petit que les valeurs "normales". Consultez cette réponse pour obtenir des informations supplémentaires, notamment sur la manière de déterminer la taille de la pile par programme et sur la manière de distinguer la limite de taille de segment absolue d'une part et la limite de tas que vous devriez idéalement respecter, d'autre part l'autre:

Detect application heap size in Android

Pour détecter ce que votre utilisation actuelle du tas est, vous pouvez essayer d'utiliser la méthode de classe d'exécution totalMemory(). Cependant, j'ai lu des rapports que différentes versions/implémentations du système d'exploitation Android peuvent avoir différentes politiques concernant si la mémoire native (à partir de laquelle la mémoire de sauvegarde pour les bitmaps est allouée) est comptée par rapport au maximum du tas ou non. Et, depuis la version 3.0, la mémoire native est directement extraite du tas de l'application. La difficulté de ce calcul me fait penser que c'est une erreur de surveiller l'utilisation de la mémoire par votre application à l'exécution, en la comparant constamment à la quantité disponible. En outre, si vous êtes au milieu d'un calcul impliqué et constatez que vous manquez de mémoire, il n'est pas toujours pratique ou raisonnable d'annuler ce calcul, et cela peut créer une mauvaise expérience pour vos utilisateurs si vous le faites. Au lieu de cela, vous pouvez essayer de définir de façon préventive certains modes ou contraintes sur le comportement fonctionnel de votre application pour qu'elle soit conforme aux limites de tas pertinentes de votre appareil (détectées lors de l'initialisation de votre application). Par exemple, si vous avez une application qui utilise une grande liste de mots qui doivent être chargés en mémoire en une seule fois, vous pouvez contraindre votre application de sorte que pour les plus petites limites de tas seulement une plus petite liste des mots les plus courants peut être chargé, tandis que pour les limites de tas plus grandes, une liste complète contenant beaucoup plus de mots peut être chargée.

Il existe également des techniques de programmation Java qui vous permettent de déclarer que la mémoire peut être récupérée par le garbage collector à la demande, même si elle possède des références «soft» (plutôt que difficiles). Si vous avez des données que vous souhaitez conserver en mémoire, mais qui peuvent être rechargées à partir d'un stockage non volatile si nécessaire (par exemple, un cache), vous pouvez envisager d'utiliser des références logicielles pour libérer automatiquement cette mémoire lorsque votre application commence à se cogner contre les limites supérieures de votre tas.Voir cette page pour plus d'informations sur les références douces dans Android:

http://developer.android.com/reference/java/lang/ref/SoftReference.html

Questions connexes