Discussion :

[mazertys17]

Bonjour,

savez vous s'il est possible d'alouer plus de mémoires a son programme ?
Lors du lancement de mon programme, si je dépasse les 63.71 MB il plante en disant : "java.lang.OutOfMemoryError".

J'utilise un smartphone basic, mais il y a-t-il des limites à ce niveau là ?£

Merci si vous pouvez m'aider.

[Hizin]

Change ton architecture/implémentation.
Android n'a qu'une mémoire limitée allouée par application. Selon les specs officielles, tu as 16 Mo de ram de garanti. Le reste, c'est du surplus. Tu utilises plus de 60 Mo au démarrage de ton application, donc tu as un souci d'utilisation de mémoire. Revois ta manière de charger tes ressources/informations
Je ne peux pas plus t'aider que ça sans code ni information d'architecture. Je peux te conseiller de regarder le lazy loading, par exemple, mais sans plus.

[mazertys17]

OK, merci je vais revoir tout ça.

Peut on savoir dans l'application combien de mémoire le téléphone a ( pour adapter la gestion des images par exemple ) ?

[Turvy]

pour avoir la mémoire du téléphone, il suffit d'aller dans Paramètres --> A propos du téléphone

Après, si le problème de mémoire vient de la gestion des images, je ne peux que te conseiller de réduire leur taille avant de les intégrer dans l'appli ou de suivre ce tuto : https://developer.android.com/traini...ad-bitmap.html. Il permet de mesurer les dimensions de l'image avant de l'afficher, et de la réduire si besoin est. Ca ne sert à rien d'afficher une image qui fait 5000x5000 dans un téléphone.

[grunk]

Selon les specs officielles, tu as 16 Mo de ram de garanti.

C'était vrai quand les téléphone avait 256 Mo de ram , aujourd’hui la norme est plus de 64Mo voir bien plus sur les appareil haut de gamme. Mais effectivement on est pas à l'abris de tomber sur un vieux machin

Il est possible de demander au système d'utiliser plus de mémoire via : android:largeHeap="true" dans le manifest
https://developer.android.com/refere...tion_largeHeap
Mais ce n'est qu'une demande , qui peut être refusée , et ce n'est à utiliser que en dernier recours quand tout à été optimisé.

[hotcryx]

Bonjour,

savez vous s'il est possible d'alouer plus de mémoires a son programme ?
Lors du lancement de mon programme, si je dépasse les 63.71 MB il plante en disant : "java.lang.OutOfMemoryError".

J'utilise un smartphone basic, mais il y a-t-il des limites à ce niveau là ?£

Merci si vous pouvez m'aider.

Réutilise tes variables, ne les crée pas dans des boucles, libère les array, listes, tableaux en quittant les procédures et évite de tout mettre en static.

[smartties]

android:largeHeap="true" ralentie énormément le fonctionnement de l'application.
Pour te simplifier la vie avec la gestion de la mémoire utilisée par tes images tu peux utiliser la librairie Picasso (Glide est pas mal aussi) qui s'occupe de la mise en cache/recyclage de tes ressources graphiques afin d'éviter des OOM comme tu as.

savez vous s'il est possible d'alouer plus de mémoires a son programme ?

Si tu passe par le JNI il n'y a pas de limite : tu peux allouer autant de mémoire que ton téléphone en a à offrir.

[mazertys17]

Merci pour toutes vos réponses.

Mon problème au delà de la gestion de la mémoire semble venir de l'écriture des fichier :

En effet, lorsque j'alloue dynamiquement tout un tas de donné pour mon programme, il fonctionne tout a fait correctement, utilisant environ 30 MO.

Mais quand j'essaye de charger ces données, il me parle d'un problème de mémoire alors qu'il ne dépasse là non plus pas les 30 MO :

Code :

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

1
2
 Process: com.mazertysinc.mynapli, PID: 10735
    java.lang.OutOfMemoryError

Il semblerait que cela vienne du scanner :

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
 
    @TargetApi(Build.VERSION_CODES.KITKAT)
    void loadMap(String file){
        try( Scanner scanner = new Scanner( new InputStreamReader( openFileInput(file) ) )){
            String word = scanner.next() ;
 
            //
 
            word = new String(scanner.next()) ;
            while ( scanner.hasNext()){
                switch (word ){
                    case "OBJECT" :
 
                        String name = new String(scanner.next());
                        int x= new Integer(scanner.nextInt()) ;
                        int x= new Integer(scanner.nextInt()) ;
                        //etc...
 
                            //je charche les données sans problème, même les objets, les graphismes etc...
                            //mais si j'essaye de les ajouter dans un container, il me bloque et m'affiche l'erreur de mémoire.
 
                            ex : objects.add(objectCharge);
 
 
                            }
 
                        }
                        break ;
                }
                word = new String(scanner.next()) ;
            }
        }catch (IOException e) {
        }
    }

Avez vous une idée de ce qui a pu se passer ?
Cela peut-il venir du scanner ou de la façon dont je l'utilise ?

Merci si vous pouvez m'aider.

[mazertys17]

J'ai le sentiment, que l'utilisation du scanner génère ce problème de mémoire.
Est-ce possible ?

[hotcryx]

J'ai le sentiment, que l'utilisation du scanner génère ce problème de mémoire.
Est-ce possible ?

Comme je le dis plus haut, ceci dans une boucle => pas bon !!!

Code :

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

1
2
3
String name = new String(scanner.next());
int x= new Integer(scanner.nextInt()) ;
int x= ..

[mazertys17]

Ok, merci.

Et avez vous une idée pour contourner le problème ?
Utiliser une boucle d'un autre type par exemple ?

[tchize_]

Alors je suis pas expert android, je suis plutot desktop, mais même sur un desktop ce code c'est n'importe nawak

Code :

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

String name = new String(scanner.next());

Tu crée un String à partir d'une String, qui est fonctionellement la même, sauf qu'elle occupe un espace mémoire supplémentaire.

Code :

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

String name = scanner.next();

Fait le même boulot avec une allocation de moins

Code :

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

int x= new Integer(scanner.nextInt()) ;

tu transforme un int en Integer puis de nouveau tu le debox en int. Quel est l'intérêt par rapport à ça?

Code :

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

int x= scanner.nextInt() ;

A part que ça fait travailler plus le GC et que ça fait chaufferette en hiver?

objetcharge est contruit comment, il a quelle structure et il occupe combien de mémoire?

Tu peux aussi reprendre ce bout de code dans une application desktop vite fait pour voir à combien de consommation mémoire elle monte quand t'as tout chargé.
Le fichier occupe quelle taille?

[mazertys17]

Merci, tchize_

J'ai fais tout cela, en raison du fait qu'il buggait avant et je me demandais s'il ne gardait pas tout simplement la valeur du scanner donc qui était susceptible de changer...

Mais apparement c'est une vue de l'esprit, cependant il semblerait qu'a certains moment cela m'ai enlevé un bugg...bref je vais essayer de revenir a la version direct c'est plus logique en effet.

( d'autre part j'ai un problème avec le nexfloat(), qui plante ).

[hotcryx]

Utilise un profiler, tu verras très vite où le code est mauvais.
Essaye d'optimiser le code si tu peux, il devrait utiliser moins de mémoire.
Faire un Switch juste pour un seul Case ce n'est pas utile, fais un simple If.

Ton problème vient probablement du Scanner qui prend la totalité du fichier, ça va occuper beaucoup de mémoire.

Faire des new de new ce n'est pas bon, utilise un nom de variable.
Cela te permettra de releaser les objets avant de quitter la procédure et d'être meilleur au niveau de la mémoire lors de la prochaine exécution.