Apparemment incompatibles se bloque OutOfMemory sur différents appareils Android

Question

Je fais un jeu qui doit charger tous les bitmaps au début parce que dans l'éditeur de jeu construit l'utilisateur peut mettre l'un des sprites dans le niveau. niveaux aussi utiliser divers sprites sans aucun système qui permettrait de charger des groupes de sprites dynamiquement pour chaque niveau.

Après un certain temps le sont maintenant déjà plus de 250 images .png dans le jeu avec la taille totale de 3.5MB.

Les charges de jeux les plus sprites (environ 200) à l'aide BitmapFactory.decodeStream sans aucune option définies, et aussi il y a environ 50 autres qui sont référencés dans des modèles XML d'activités.

Quand je test sur différents appareils, le jeu tourne parfois hors de la mémoire, mais je ne peux pas trouver un modèle et même décider combien je dois, par exemple réduire la taille des images ou leur nombre.

Le téléphone sur lequel j'ai développé, le désir de HTC avec Android 2.2 Taille du tas 24MB VM ne fonctionne jamais OOM.

Dell Streak avec Android 2.2 et la taille de tas VM 40Mo ne fonctionne jamais OOM aussi.

Motorola Milestone avec Android 2.1 et la taille tas 24MB VM charge avec succès tous les sprites mais selfs sur les quelques dernières images utilisées lors du démarrage dans l'une des activités de ImageView (menu Démarrer). Si je commente quelques-unes de ces ImageViews dehors, il charge ok, mais peut étouffer l'un des autres activités plus tard. Il est également pas stable, probablement parce que la fragmentation se produit différemment dans différents lancements.

HTC Hero avec 2.2 de mon copain (je sais pas la taille du tas, est-il 16MB?) Plante aussi bien.

Ce qui est le plus déroutant est que Motorola a 24MB, le même que le désir de HTC. Est 2.1 utilisant la gestion de la mémoire moins efficacement? (par exemple, conduit à une plus grande fragmentation?) Ou est pire gestion de la mémoire par tous les téléphones Motorola? Alors pourquoi HTC Hero avec 2.2 accident? Ce qui est plus important dans le désir de HTC que HTC Hero?

On dirait OOM arrive sur les téléphones plus anciens, mais c'est la seule chose que j'ai pensé à ce jour.

Si OOM ne se produit que sur les téléphones plus anciens qui sont, disons, 5% du marché, je peux exclure 2.1 ou une liste plus précise des périphériques pris en charge par simplement recueillir rapports d'erreur et en excluant tout ce qui se sont écrasés dans la liste des pris en charge . Sinon, je vais maintenant besoin de réduire toutes mes images par un facteur constant (par exemple 1,6), ce qui signifierait le redimensionnement de tous les 45 niveaux qui ont des jours et des jours de la conception et de test, le repositionnement des éléments de l'interface graphique, etc. Même après cela, je » d toujours pas être sûr, sur lequel les appareils de la réduction de la taille totale de bitmaps par un facteur, par exemple 2 est suffisant pour éviter MOO.

Un conseil à ce sujet? Dois-je mettre des options spécifiques pour BitmapFactory? BTW, la plupart des images ont pixels bg transparent qui, autant que je sache, ne permet pas de les obtenir au format 565.

J'ai passé 2 jours ici et naviguent dans d'autres endroits, mais je suis toujours à perte.

Merci.

Answer 1

J'ai dû faire face à une version simplifiée de votre problème -. Nous avions 3 couches 2Mpix au-dessus de l'autre, qui, sans surprise, parfois causé OOM

Dans mon cas, au lieu d'utiliser 3 ImageViews au-dessus de l'autre, en gardant tous les 6 MPix dans la mémoire à tout moment, je manuellement mélangé les couches, maintenant ainsi au plus 4 Mpix en mémoire à un moment donné (et seulement 2 MPix au « repos » - les couches modifiées dans notre application).

Ceci est un compromis espace-temps classique - efficacité sacrifice (temps) à la mémoire de gain (espace). Il était un peu lent parce que vous deviez recycle() chaque Bitmap après avoir été fait avec elle pour assurer la mémoire a été libéré. ??

En ce qui concerne les MOO incompatibles, il a probablement à voir avec la collecte des ordures. Vous pouvez supposer que le garbage collector est non déterministe et donc une pression de mémoire est non-déterministe ainsi (selon le moment où le dernier coup de pied dans GC).

Le court résumé, vous devez être très, très prudent avec votre utilisation de la mémoire et il n'y a aucun moyen de contourner cela. *

* En théorie, vous pouvez allouer de la mémoire en dehors du tas Dalvik en utilisant le NDK et d'allouer directement à partir du système d'exploitation. Il est un énorme bidouille et le pont entre Dalvik et votre allocateur seront plutôt laid.

Answer 2

Tout d'abord vous devez trouver ce qui est exactement en utilisant toute votre mémoire. Check this out. Peut-être que vous pourriez recyclez bitmaps, par exemple.