Discussion :

[grunk]

Bonjour,

Je rencontre actuellement un problème avec le Garbage Collector. Mon application va lire des images sur une socket pour les afficher dans une imageView.
La lecture peux se faire à plusieurs images par seconde.

Je tombe malheuresement souvent dans une boucle infinie du GC avec des truc du genre :

06-15 11:24:59.176: DEBUG/dalvikvm(521): GC_FOR_MALLOC freed 9340 objects / 524152 bytes in 645ms

J'en déduit donc que je ne libère pas correctement la mémoire et que le GC doit le faire à ma place.
En lancant l'Allocation Tracker je me suis rendu compte qu'effectivement mon buffer servant à recevoir les données de la socket était alloué moulte fois :

.

Comment puis je faire en sorte d'améliorer ma gestion de mémoire sachant que mon code est géré comme suis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
private Bitmap readJPG()
{
	byte[] header 	= new byte[30];
	byte[] datas	= new byte[0];
	Bitmap image	= null;
	int byteLu		= 0;
	int dataLu		= 0;
	int tailleJPG	= 0;
	int nbPaquet	= 1;
	int numPaquet	= 0;
	int tailleData	= 0;
	int bufferOffset= 0;
	int dataRead	= 0;
 
	//Lecture des entêtes
	try {
		while(nbPaquet > numPaquet)
		{
			dataLu = 0;
			header = this.readImageHeader();
			if(header != null)
			{
				if(numPaquet == 0)
					datas		= new byte[tailleJPG]; //Allocation qui pose à mon avis problème
 
				while(dataLu < tailleData)
				{
					dataRead = this.client.getReader().read(datas, bufferOffset, (tailleData - dataLu));
					dataLu += dataRead;
					bufferOffset += dataRead;
				}
				byteLu += dataLu;
			}
		}
		image = BitmapFactory.decodeByteArray(datas, 0, tailleJPG);
		datas = null;
	} catch (IOException e) {
		datas = null;
	}
	return image;
}

N'est il pas possible de détruire simplement le tableau datas une fois qu'ila été passé à la BitmapFactory

[MrDuChnok]

Un des principes du développements mobiles : Réutiliser ce qui est réutilisable.

En gros, si tu alloues de la mémoire, essaye de réutiliser cet emplacement si possible au maximum, celà évitera au GC de passer régulièrement vider cette mémoire inutilisée.

Pourquoi avoir mis un test sur "numPaquet == 0" dans ta boucle ? alors que tu pourrais le faire juste avant la boucle ?

[grunk]

Pourquoi avoir mis un test sur "numPaquet == 0" dans ta boucle ? alors que tu pourrais le faire juste avant la boucle ?

Parce que avant ma boucle je ne connais pas la taille de mon image à allouer (j'ai simplifier la code de la boucle pour aller à l'essentiel).

J'ai remonter le tableau datas dans les attributs de la classe plutôt que de le garder localement.
J'ai l'impression que ça va mieux niveau allocation , mais le problème persiste.

[Feanorin]

Bonjour,

Pourquoi ne pas faire comme le reallocate sous C++.

tu réalloues ta variable que si la nouvelle taille est supérieure à l'ancienne, comme cela tu laisses la mémoire tranquille dans un premier temps. Si elle est supérieure ,tu l'alloues à nouveau.

[grunk]

Bonjour,

Pourquoi ne pas faire comme le reallocate sous C++.

tu réalloues ta variable que si la nouvelle taille est supérieure à l'ancienne, comme cela tu laisses la mémoire tranquille dans un premier temps. Si elle est supérieure ,tu l'alloues à nouveau.

L'idée est intéressante !


J'ai réglé le problème de GC_FOR_MALLOC qui était en fait du à des erreurs de lecture sur ma socket dans le thread. En revanche l'optimisation des allocations reste intéressant