Discussion :

[hotcryx]

Attention avec les Synchronized, des locks peuvent se créer:
http://docs.oracle.com/javase/tutori.../locksync.html
Idem pour les Thread avec Wait...

Je remarque qu'il y a un catch avec un print du stack.
C'est mal géré: si le code juste au dessus du catch plante, il va ramer à cause du catch.
J'ai déjà eu cela dans un programme.
Perso, je préfère mettre mes catch sur toute une procédure/fonction comme cela tout est englobé et il sort en cas d'erreur.

Il y a aussi des log dans des boucles, hai hai...

This Java Tutorial (lien au dessus) can probably help you understand what using synchronized on an object does.
When object.wait() is called it will release the lock held on that object (which happens when you say synchronized(object)), and freeze the thread. The thread then waits until object.notify() or object.notifyAll() is called by a separate thread. Once one of these calls occurs, it will allow any threads that were stopped due to object.wait() to continue. This does not mean that the thread that called object.notify() or object.notifyAll() will freeze and pass control to a waiting thread, it just means these waiting threads are now able to continue, whereas before they were not.

Il ne te manque pas des Notify car tu fais un Wait quand tu appelles Synchronized(object).

[Sebenf0rce]

J'ai supprimé les Log et modifié les try catch.
J'ai également enlevé plusieur Synchronised qui ne servait à rien et mis le notify à chaque fin du synchronised.

Pour les différent Thread je ne sais pas du tout d'où ils viennent. Je suis censé en avoir deux, celui appelé dans la surfaceViewBulle et celui de base.
En regardant ce qu'il y a dans les thread je n'ai pas compris du tout ce que c'était.



Dans le 1er thread il y a mes fonctions mais les autres contiennent execTransact():565,Builder(), à quoi ça correspond ?

Edit : En testant le AndroidMonitor sur un nexus S l'appli consomme seulement 10-12 mb. Est ce normal qu'il y ai une telle différence avec le nexus 6 (75 mb) ?

Edit 2 : En regardant les fonctions qui consomme le plus :

Code :

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

1
2
3
4
5
6
 public BitmapDrawable setImage(final Context c, final int ressource)
    {
        Drawable dr = c.getResources().getDrawable(ressource);
        Bitmap bitmap = ((BitmapDrawable) dr).getBitmap();
        return new BitmapDrawable(c.getResources(), Bitmap.createScaledBitmap(bitmap, largeur,largeur, true));
    }

Cette fonction consomme 66% de la mémoire de mon programme. N'y a t'il pas moyen de l'améliorer ? Je ne vois pas trop comment m'y prendre

[hotcryx]

Je dois bientôt partir, je regarderai ton email ce soir.
Pour les Bitmap (ton dernier bout de code), il doit y a avoir moyen d'utiliser la cache.
Et de nettoyer proprement la mémoire utilisée par cette image.

Après tes 1eres modif, tu devrais déjà voir une amélioration au niveau Ram, CPU.
Compare d'un résultat à l'autre.
Regarde aussi TraceView: https://developer.android.com/studio...traceview.html
Ca c'est le top pour voir ce qui "bouffe".

Le Thread dont tu parles c'est probablement le Thread qui lance ton applic (ou un manager de Thread).
Essaye de voir son contenu.

[hotcryx]

Définit tes objets avec final (tout tes objets qui ne changent pas)
Ex: final Bitmap bitmap = new ...

Cache bitmap:
https://developer.android.com/topic/...he-bitmap.html

https://developer.android.com/topic/...ge-memory.html

J'avais lu ailleurs qu'il fallait éviter de trop changer les pixels, cela avait une incidence de reloader...

Le passage des variables en Java est par valeur => copie et non par référence.
Donc quand tu as des canvas, image => ils les dupliquent.
Essaye d'éviter d'appeler certaines méthodes (consommatrice) qui appellent d'autres méthodes, d'autres méthodes... => demandant trop de mémoire (notamment les images et canvas en paramètres), et passant une flopée d'objets au final.
Réduis la mémoire, ça permettra au CPU de tourner (final au max).

[Sebenf0rce]

J'ai essayé en mettant des final à toutes les images, enlevé les bitmap des paramètres des fonctions mais rien n'y fait toujours ce soucis de lag.

J'ai même tenté de supprimer complètement les images des objets Bulle pour n'avoir qu'une image commune pour chaque mais toujours pareil.
Je suis arrivé avec cette méthode au résultat suivant :



On peut voir que le thread qui affiche les images (celui surligné en bleu) ne consomme plus que 1.30% !

Je pensais qu'on avait réussis à trouver l'origine du problème mais il ne semble pas que cela vienne des images (même si je prends note de tout ce que tu m'as fait faire afin de réduire l'utilisation de la ram).

Edit : En utilisant le traceview j'ai remarque que le lockCanvas utilisait 70% du cpu utilisé par l'application

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
 while (keepDrawing) {
                Canvas canvas = null;
                try {
                    // On récupère le canvas pour dessiner dessus
                    canvas = mSurfaceHolder.lockCanvas();
                    // On s'assure qu'aucun autre thread n'accède au holder
                    if (canvas != null) {
                        synchronized (mSurfaceHolder) {
                            //on déplace la bulle
                            update();
                            mSurfaceHolder.notify();
                        }
                        synchronized (mSurfaceHolder) {
                            // Et on dessine
                            onDraw(canvas);
                            mSurfaceHolder.notify();
                        }
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    // Notre dessin fini, on relâche le Canvas pour que le dessin s'affiche
                    if (canvas != null)
                        mSurfaceHolder.unlockCanvasAndPost(canvas);
                }

Est-ce que le lockCanvas est utilisé de la bonne façon. J'ai regarde sur un tuto et la méthode présentait était la même que moi.

Sinon j'ai une autre question à propos des images. En gros selon les bulles je suis censé avoir au maximum 20 bulles différentes, est ce que au lieux de créé une image par bulle, il serait préférable de faire un classe ImageFactory par exemple chargé de créé les 10 images au début de l'application par exemple et lors de l'affichage des bulles on choisit une des 10 images de la classe ? Ou alors cela serait trop lourd de stocké 10 images comme ça ?

[hotcryx]

Toutes les modif (final, image...) ont un impact, même si tu ne le vois pas.
Les Final c'est conseillé par Google.
Tu allèges ton programme de plus en plus.

Sort le try/catch de ton while.
Regarde ce que fait Update().
Peut-être que tes thread attendent la fin pour rafraichir l'écran (communication synchrone) ou un buffer qui doit se remplir...
Tu dois avoir un lock quelque-part.

Pour la préparation des images, je ne sais pas, il faut y réfléchir.
C'est mieux de préparer avant à condition que ça ne prenne pas trop de temps et de ressource.
Il faut relacher les ressources quand tu n'en a plus besoin.

Peut-être qu'au niveau de la mémoire tu dois définir HEAP memory dans le manisfest comme tu as +70 Mb d'occupation mémoire (pointeurs longs), trop lents...

Une autre alternative: essaye de refaire proprement une activité simple avec juste le déplacement sans background.
Evite de tout reprendre le code, juste l'essentiel sans la gestion des touches...
Tu finiras par trouver ce qui bloque.
Minimise la taille du canvas.

[hotcryx]

En regardant tes thread (transact qui consomment: 32% 28% => faudrait plus s'inquiéter de ceux là)
j'ai trouvé ceci, c'est du IPC et semble être IBinder:
https://developer.android.com/refere...s/IBinder.html

"Base interface for a remotable object, the core part of a lightweight remote procedure call mechanism designed for high performance when performing in-process and cross-process calls. This interface describes the abstract protocol for interacting with a remotable object. Do not implement this interface directly, instead extend from Binder.

The key IBinder API is transact() matched by Binder.onTransact(). These methods allow you to send a call to an IBinder object and receive a call coming in to a Binder object, respectively. This transaction API is synchronous, such that a call to transact() does not return until the target has returned from Binder.onTransact(); this is the expected behavior when calling an object that exists in the local process, and the underlying inter-process communication (IPC) mechanism ensures that these same semantics apply when going across processes. "

[Sebenf0rce]

J'ai pu tester sur un vrai téléphone et j'ai remarque que la fluidité n'était pas du tout la même que sur l'émulateur. ça tourne même parfaitement. J'ai regardé la différence sur le Android Monitor pour essayer de comprendre et j'ai remarqué que les thread avec les IBinder n'était pas présent. Y'a t'il une raison à cela ?

[hotcryx]

IBinder est dans le Core de l'OS.
Peut-être la version de l'OS? ou Android Monitor qui les génère
Content que ça marche mieux

[Sebenf0rce]

Oui merci pour ton aide, c'est bizarre que le bug n’apparaît que sur l'émulateur

[hotcryx]

oui c'est bizarre