Discussion :

[Sebenf0rce]

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

[hotcryx]

Dans un premier temps, tu pourrais déjà convertir tes images au format webp, notamment le backgroung...

http://tools.android.com/tech-docs/webp

[hotcryx]

ici il pourrait boucler indéfiniment si le join ne se fait pas, sans pouvoir sortir:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public void surfaceDestroyed(SurfaceHolder holder) {
        mThread.keepDrawing = false;

        boolean joined = false;
        while (!joined) {
            try {
                mThread.join();
                joined = true;
            } catch (InterruptedException e) { //? on ne sort pas }
        }
}

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.
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".

Code :

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

1
2
3
4
5
6
synchronized (mSurfaceHolder) {
                        //on déplace la bulle
                        update();
                        // Et on dessine
                        onDraw(canvas);
}

Pense à réutiliser les variables:
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.

[Sebenf0rce]

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".

[hotcryx]

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...

[Sebenf0rce]

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

[Hizin]

Tu as dû mal chercher ^^'

Voici la documentation : https://developer.android.com/guide/...are-accel.html

[hotcryx]

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
}

[Sebenf0rce]

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).

[hotcryx]

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
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).

Code :

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

free -m sous linux

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 :

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

adb install -r app-release.apk

(tu dois être en terminal dans le répertoire app de ton application)
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!

[Sebenf0rce]

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 :

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
public void genererBulle() {
 
        Bulle bulle = new Bulle(this.getContext(), metrics, definirValeurBulle());
 
        Random random = new Random();
        int y = random.nextInt(5000);
        if (y < 300) {
            Random rand = new Random();
 
            int x = rand.nextInt(metrics.widthPixels - bulle.getLargeur());
            bulle.setX(x);
 
            if (bulleFactory.getListeBulle().size() > 0) {
                if (x > (bulleFactory.getListeBulle().get(bulleFactory.getListeBulle().size() - 1).getX() + bulleFactory.getListeBulle().get(bulleFactory.getListeBulle().size() - 1).getLargeur()) || x < (bulleFactory.getListeBulle().get(bulleFactory.getListeBulle().size() - 1).getX() - bulleFactory.getListeBulle().get(bulleFactory.getListeBulle().size() - 1).getLargeur()))
                    bulleFactory.getListeBulle().add(bulle);
                else {
                    return;
                }
            } else {
                bulleFactory.getListeBulle().add(bulle);
            }
        }
        else {
            return;
        }
 
    }

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 :



Edit : je viens de générer un "signed apk" mais j'ai l'erreur suivante :

[hotcryx]

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

Tu dois avoir une config Release dans Gradle.

Code :

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

1
2
3
4
5
6
7
 
Bulle bulle; 
for(i=0; i < 10; i++)
{
   bulle = new Bulle(...);
   ...
}

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...).

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.

[Sebenf0rce]

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.

[hotcryx]

Et quand il n'y a pas de bulle, ça rame aussi?
Ca se trouve c'est un autre problème

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.

[Sebenf0rce]

J'ai essayé avec sans la génération et voici le résultat :



Et avec la génération :



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 :



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 ?

[hotcryx]

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.

[Sebenf0rce]

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 :

Code :

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

1
2
3
if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_PHONE_STATE) != PackageManager.PERMISSION_GRANTED) {
            ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.READ_CONTACTS}, MY_PERMISSIONS_REQUEST_READ_PHONE_STATE);
        }

Et d'override la méthode onRequestPermissionsResult de la façon suivante :

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
    @Override
    public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
        switch (requestCode) {
            case MY_PERMISSIONS_REQUEST_READ_PHONE_STATE: {
                if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
 
 
                } else {
 
                    Toast.makeText(this, "Besoin de l'accord", Toast.LENGTH_SHORT).show();
                }
                return;
            }
 
        }
    }

Mais le toast s'affiche à chaque fois et la popup pour accepter ou non la permission n’apparaît pas.

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?

L'image de fond ne fait que 14ko pourtant, je l'avais convertit au format webp comme tu me l'avais conseillé.

Est-ce que le Chrographer tourne avec un Runnable?

Je suis allé voir un peu sur internet ce qu'était le Chographer et je ne crois pas l'utiliser.

[hotcryx]

14kb c'est ok, je pensais beaucoup plus

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

Quelque-chose te prend toutes les ressources (ram, cpu).
Profile ton code (tests de performance), il te montrera les gros blocs qui surchargent.

[Sebenf0rce]

14kb c'est ok, je pensais beaucoup plus

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

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 ?

Le test de performance se fait depuis le AndroidMonitor ?

Edit: J'ai réussis à obtenir le résultat suivant :

[hotcryx]

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)