Version imprimable
Bonjour,
J'ai commencé une application android et j'ai un gros soucis de performances. Actuellement j'affiche par l'intermédiaire d'une sufaceView un background et une image (une bulle) qui se déplace. Le déplacement est saccadé et je ne comprends pas pourquoi.
Voici mon code actuel : https://github.com/SebGonzalez/Sumble
La surfaceView est créé dans la classe SurfaceViewBulle et la classe DrawingThread affiche cette surfaceView dans un thread.
Merci d'avance
Dans un premier temps, tu pourrais déjà convertir tes images au format webp, notamment le backgroung...
http://tools.android.com/tech-docs/webp
ici il pourrait boucler indéfiniment si le join ne se fait pas, sans pouvoir sortir:
A partir d'ici, je pense que c'est le code à vérifier car l'Update est dans une boucle While, l'update ayant aussi une boucle For et OnDraw également.Code:
2
3
4
5
6
7
8
9
10
11public void surfaceDestroyed(SurfaceHolder holder) { mThread.keepDrawing = false; boolean joined = false; while (!joined) { try { mThread.join(); joined = true; } catch (InterruptedException e) { //? on ne sort pas } } }
Ca fait beaucoup de travail pour le processeur.
N'y a t'il pas une sorte de DoEvents() comme en VB????
Tu ne laisses pas le processeur gérer ses propres messages.
Je ne parle pas de mettre des sleep!!!! (horreur) mais de laisser le processeur "s'auto gérer".
Pense à réutiliser les variables:Code:
2
3
4
5
6
Ex: For(Bulle bulle : ...) => changer la boucle (en for..to par exemple) afin de réutiliser bulle et à le définir en dehors de la boucle.
Ok j'ai donc converti mon background en webp et ajouté un " e.printStackTrace();" dans mon catch.
Pour le for du update et du onDraw j'ai essayé de l'enlever et d'affecter le déplacement et l'affichage seulement au premier élément de la liste mais j'ai toujours ce soucis de latence lors du déplacement.
Pour les sleep j'ai vu ça sur un tuto d'openClasseroom, apparemment c'était pour "afficher l'écran à 50fps".
Tu utilises beaucoup de mémoire (comme la variable bulle) avec des images.
As-tu bien fait les déréférences? bulle = null; avant de lui réaffecter un objet?
Si ces objets sont visibles à l'écran, n'est ce pas plus simple de changer leurs coordonnées plutôt que de les effacer et redessiner?
Si l'image ne change pas, ce serait une perte de temps d'essayer de le redessiner...
As-tu pensé à l'accélération graphique? (dans le manisfeste).
Quel est ton moteur de rendu?
Les moteurs de rendu ont déjà été confrontés à ce genre de problème...
Je ne récréé pas les objet bulle à chaque fois normalement. J'utilise juste la méthode update qui modifie leurs coordonnées et je les ré affiche avec la méthode onDraw.
Je n'ai rien trouvé sur le web pour activer l'accélération graphique.
Pour le moteur de rendu je crois que je n'en utilise pas
Tu as dû mal chercher ^^'
Voici la documentation : https://developer.android.com/guide/...are-accel.html
Quand tu fais:
while(...)
{
Bulle bulle = new Bulle(..);
//Bulle bulle => tu utilises à chaque fois une autre zone mémoire pour stocker la référence de l'objet.
//Ce qui veut dire qu'au final tu auras plein de références partout :mouarf:
}
Merci pour vos réponses.
J'ai donc ajouter android:hardwareAccelerated="true" dans le manifest et j'ai remplacé les boucles for(Bulle bulle ... liste) par des for classique.
Malheureusement le lag est toujours présent cependant j'ai remarqué que cela ne se produisait pas sur un émulateur avec un plus petit écran comme le nexus s. Actuellement j'utilise le nexus 6 (émulateur aussi).
Si tu tiens compte de ce que j'ai dit plus haut ce serait encore plus rapide, à ne pas négliger car tu ne sais pas quel est l'appareil des utilisateurs et la version d'Android installée + surcouche opérateur.
C'est normal que ça rame avec un écran de tablette :mouarf:
D'abord tu devrais vérifier la Ram qu'il te reste au niveau système sur ton pc (une fois Studio, Emulateur... prêts).
Regarde aussi combien il y a de mémoire utisée en cache (si la cache est vide c'est mieux).
Essaye de générer l'APK signé en Release comme pour le store, sans les infos debug... et publie le sur l'émulateur avec cette commande:Code:free -m sous linux
(tu dois être en terminal dans le répertoire app de ton application)Code:adb install -r app-release.apk
Normalement si tu fais ce test sur un émulateur pas trop volumineux en taille et que tu as de la Ram sur le pc et que le pc répond rapidement et que l'émulateur est optimisé (1Gb de ram et 512Mb de VM, offline) ça devrait être rapide.
Si ce n'est pas rapide après tout cela c'est qu'il y a un gros problème.
Perso: j'ai eu un problème d'install de mon applic Android à l'instant, l'applic ramait et c'était un upgrade Ubuntu qui faisait tout ralentir! :mouarf:
Ce que tu as dis plus ? Tu parle de la création d'objet "Bulle bulle" ? Comment dois-je faire pour ne pas faire ça ? Il faut bien que je fasse un new pour créer l'objet non ?
Le seul endroit où je fais new Bulle c'est dans ma méthode genererBulle :
Pour ce qui est de publier l'apk sur l'émulateur je n'y suis pas arriver. J'ai générer l'apk mais je pense pas de la bonne manière. Voici ce que j'obtiens lorsque j'essaye de l'installer sur l'émulateur :Code:
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
Pièce jointe 254825
Edit : je viens de générer un "signed apk" mais j'ai l'erreur suivante :
Pièce jointe 254838
c'est: adb install -r tonapk.apk
(-r permet de faire des update sinon il réécrase tout, mais le prob n'est pas là ^^)
Tu dois faire: Generate Apk alors il te demande des clés, ce sont celles pour créer le certificat en Release (PROD).
Fais gaffe de ne pas les perdre :D
Tu dois avoir une config Release dans Gradle.
Regarde aussi combien tu crées de Bulles (Edit: Maximum 5000 d'après ton code => Waw c'est beaucoup. Essaye avec 3 pour commencer, ensuite 10, 100...).Code:
2
3
4
5
6
7
Pour ton "update incompatible" c'est parce que tu étais en Debug et ensuite tu crées une version Release.
Forcement il n'aime pas => désinstalle ton app de l'émulateur et relance l'install Release.
Pareil pour repasser en Debug => vire l'app de l'émulateur.
Ok donc j'ai réussi à installer la version release sur l'émulateur mais toujours pareil ça avance au ralentit.
Pour la génération la valeur 5000 que tu as vu c'est une valeur random et si cette valeur est inférieur à 300 la bulle est généré (du coup une seule instance de bulle est créé dans la fonction). J'ai essayé en mettant un objet Bulle en attribut et de faire laBulleAttribut = new Bulle() mais ça ne change rien. Le problème c'est que même lorsqu'il n'y a qu'une seule bulle ça rame.
Et quand il n'y a pas de bulle, ça rame aussi?
Ca se trouve c'est un autre problème :mouarf:
Pour débugger hardcode la valeur à quelques bulles et fait le monitoring de l'application (voir onglet Monitoring).
Certaines tâches doivent être lourdes.
Vérifie la Ram employée et le CPU.
J'ai essayé avec sans la génération et voici le résultat :
Pièce jointe 255684
Et avec la génération :
Pièce jointe 255687
Est-ce normal que au niveau de la ram j'ai en free 1-2 mo en moyenne alors que je n'en utilise 74 ?
Mon émulateur est configurer de la façon suivante :
Pièce jointe 255692
Je ne comprends pas car lorsqu'il n'y a pas la génération rien de particulier est effectué. Est-ce simplement l'affichage qui est lourd comme ça ? Mes images ne font que quelques ko.
Edit : Ce message apparait au démarrage : I/Choreographer: Skipped 32 frames! The application may be doing too much work on its main thread. Est normal ?
Ta config RAM, VM est bonne ne change rien à cela.
Retire le multicore expérimental.
T'as essayé sans la génération => impec, il faut d'avoir optimiser ce code pour être à l'aise pour la suite.
As-tu une image optimisée x86 de l'émulateur? (comme celles recommandées par Google)
Non, ce n'est pas normal ne n'avoir que 2 Mb de Ram => optimise le code, les images.
L'image de fond doit "bouffer" combien fait-elle de Kb?
Est-ce que le Chrographer tourne avec un Runnable?
Le problème pourrait venir de là, investigue (CPU un peu trop haut, regarde que les boucles ne tournent pas sans fin) ;)
Installe l'APK sur ton téléphone et regarde si ça rame.
A mon avis 74Mb de Ram c'est trop, ton programme devrait avoisiner 40-50Mb.
J'ai retiré le "multicore experimental" mais aucun changement :(
Pour l'image de l'émulateur j'étais en x86_64 j'ai essayé de recréé un émulateur cependant j'ai un nouveau soucis de permission : "Unable to start activity ComponentInfo{fr.unice.iutnice.sumble/fr.unice.iutnice.sumble.View.MainActivity}: java.lang.SecurityException: getDeviceId: Neither user 10088 nor current process has android.permission.READ_PHONE_STATE."
J'ai essayé de faire la demande de permission :
Et d'override la méthode onRequestPermissionsResult de la façon suivante :Code:
2
3
Mais le toast s'affiche à chaque fois et la popup pour accepter ou non la permission n’apparaît pas.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
L'image de fond ne fait que 14ko pourtant, je l'avais convertit au format webp comme tu me l'avais conseillé.Citation:
Non, ce n'est pas normal ne n'avoir que 2 Mb de Ram => optimise le code, les images.
L'image de fond doit "bouffer" combien fait-elle de Kb?
Je suis allé voir un peu sur internet ce qu'était le Chographer et je ne crois pas l'utiliser.Citation:
Est-ce que le Chrographer tourne avec un Runnable?
14kb c'est ok, je pensais beaucoup plus :aie:
Normalement x86_64 c'est Ok, si tu as un 64 bits :)
Le chroregrapher permet de faire des animations, tu es certain que tu ne l'utilises pas?
Pourtant tu animes des images :oops:
Quelque-chose te prend toutes les ressources (ram, cpu).
Profile ton code (tests de performance), il te montrera les gros blocs qui surchargent.
Les animations se font dans un thread (class drawingThread dans mon code) qui est appelé dans la surfaceView et ce thread execute une fonction "update" qui déplace de x dp l'image. Est-ce la bonne façon de procéder ?Citation:
Envoyé par hotcryx
Le test de performance se fait depuis le AndroidMonitor ?
Edit: J'ai réussis à obtenir le résultat suivant :
Pièce jointe 255948
A mon avis c'est plus:
https://developer.android.com/studio...-walkthru.html
et HPROF (plus haut à gauche dans le menu)
Je n'ai pas encore essayé sous Studio mais c'est pareil pour tous les langages: il faut réduire les temps d'exécution et l'usage de la mémoire.
En regardant tes données:
- Tu as plusieurs threads ! (pourquoi?! Ils pourraient se bloquer et avoir des problèmes pour échanger des infos)
- L'un des Thread est à 62% (et pas le reste)
- Size +90% ! (par rapport aux autres)
- GenererBulle: 35 et 36% ! (par rapport aux autres)
- Surface: 13% (par rapport aux autres)
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). :aie:
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.
Pièce jointe 256070
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 :
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 prendreCode:
2
3
4
5
6
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.
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).
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 :
Pièce jointe 256160
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
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.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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 ?
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.
En regardant tes thread (transact qui consomment: 32% 28% => faudrait plus s'inquiéter de ceux là) :ptdr:
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. "
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 ?
IBinder est dans le Core de l'OS.
Peut-être la version de l'OS? ou Android Monitor qui les génère :aie:
Content que ça marche mieux :mouarf:
Oui merci pour ton aide, c'est bizarre que le bug n’apparaît que sur l'émulateur
oui c'est bizarre :aie:
