2010-05-29 4 views
8

J'ai un UIWebKit avec un HTML, ce HTML a plusieurs images et texte, mais juste l'affichage me donne l'avertissement de mémoire. J'ai fait quelques tests: Le même HTML avec différentes images, taille maximale, et après les mêmes images mais réduit de 50% par rapport à sa taille d'origine, pour les images réduites de 50%, je suis allé en aperçu et réduit toutes les images à 50%Avertissement de mémoire de l'iPad avec l'utilisation de mémoire faible

La partie surprenante est le test de 50%, vous pouvez voir que même avec 16 images, le pic de mémoire est de 4,90 Mo. C'est vraiment surprenant. Notez que ces valeurs ne sont pas toujours les mêmes, elles changent mais il n'y a pas de grande différence entre les tests.

Dans le numéro 50%, dans les 8 et 16 images, bien que la mémoire est faible, parfois un avertissement de mémoire apparaît, mais la performance Améliorée est notable par rapport aux images en taille réelle

encore debout = mémoire après défilement tout article

1 image = [immobile 5MB] [de 5.6MB rotation]

2 images = [debout encore 6.99MB] [7.7MB rotation]

3 images de = [encore debout de 9.04MB ] [tournant 10.9MB]

4 images = [immobile 10.89MB] [13.20MB rotatif]

8 images = [immobile 23.14MB] [25.20MB rotatif] (se bloque parfois)

16 images = [immobile 27.14MB et accidents app]

50%

1 image = [immobile 3.2MB] [3.67MB rotatif]

2 image = [debout encore 3.2MB] [ 3.70MB rotatif]

3 Image = [immobile 3.3MB] [3.79MB de rotation]

4 Image = [debout encore 3.3MB] [3.80MB rotatif]

8 Images de = [immobile 4.29MB] [rotation 4,63MB] (se bloque parfois)

16 Images = [Immobile 4.79MB] [rotation 4,90MB] (parfois plante)

Ma question est la suivante: L'application parfois écrasé avec 16 petites images. Pourquoi? La mémoire était beaucoup plus faible.

Quelle est la limite d'utilisation de la mémoire? Le maximum semblait différent avec les images de taille 50%. 13,2 Mo fonctionne pour les grandes images et 3,8 pour les petites images. Quelque chose de plus élevé parfois se bloque. Ça n'a aucun sens.

Merci

Répondre

2

Il serait utile que vous avez publié un journal de plantage de ce qui se passe, parce qu'il est très probable que l'accident n'est pas lié autant à votre consommation de mémoire car il est à la façon dont vous manipulez que la mémoire .Oui, votre taille de l'image peut être exaccerbating le problème, car la quantité de mémoire réelle utilisée par image est dimensionnée selon cette formule:

w * h * 4 

en supposant bien sûr, que l'image est une image couleur 32 bits, où w est la largeur de l'image en pixels, et h est la hauteur de l'image en pixels. Par conséquent, une image couleur 32 bits 1024x1024 utilise environ 4,2 Mo de mémoire, alors qu'une image couleur 32 bits 512x512 utilise 1 Mo.

Votre rapport de panne sera révélateur. Exécuter également dans les instruments sous l'allocation d'objets et les fuites outil peut être d'une perspicacité énorme (exécuter avec le volet latéral visible, il montrera la pile d'appel pour les fuites que vous trouvez). Notez également, si vous trouvez des fuites qui pointent sur des choses comme CIOImage ou similaire, c'est peut-être là que la fuite se produit finalement, mais où la fuite se produit presque positivement dans votre code. De même, lors de l'exécution d'Instruments, n'oubliez pas de l'exécuter en pièce jointe à l'application en cours d'exécution sur votre appareil. ne prenez rien de ce que la simulation dit à la valeur nominale dans des cas comme celui-ci.

+0

Vous avez raison de calculer la taille non compressée de l'image (j'utiliserais la formule (w * h) B où "B" est un octet (pas un bit) par pixel). Cela pourrait bien être son problème. – Mikaveli

+0

Je calculais des octets et non des bits. 4 octets en 32 bits. – jer

+0

Désolé, je me rends compte que vous utilisiez des octets. Je voulais simplement que ce soit plus clair pour l'OP, car lorsque la plupart des gens parlent d'images, ils se réfèrent à des «bits par pixel». – Mikaveli

Questions connexes