1. #21
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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).
    Si la réponse vous a aidé, pensez à cliquer sur +1

  2. #22
    Membre du Club
    Homme Profil pro
    Etudiant
    Inscrit en
    septembre 2016
    Messages
    43
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : septembre 2016
    Messages : 43
    Points : 42
    Points
    42

    Par défaut

    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.

    Nom : Capture.PNG
Affichages : 23
Taille : 45,5 Ko

    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

  3. #23
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  4. #24
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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).
    Si la réponse vous a aidé, pensez à cliquer sur +1

  5. #25
    Membre du Club
    Homme Profil pro
    Etudiant
    Inscrit en
    septembre 2016
    Messages
    43
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : septembre 2016
    Messages : 43
    Points : 42
    Points
    42

    Par défaut

    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 :

    Nom : Capture.PNG
Affichages : 19
Taille : 25,4 Ko

    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 ?

  6. #26
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  7. #27
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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. "
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #28
    Membre du Club
    Homme Profil pro
    Etudiant
    Inscrit en
    septembre 2016
    Messages
    43
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : septembre 2016
    Messages : 43
    Points : 42
    Points
    42

    Par défaut

    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 ?

  9. #29
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    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
    Si la réponse vous a aidé, pensez à cliquer sur +1

  10. #30
    Membre du Club
    Homme Profil pro
    Etudiant
    Inscrit en
    septembre 2016
    Messages
    43
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : septembre 2016
    Messages : 43
    Points : 42
    Points
    42

    Par défaut

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

  11. #31
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 004
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 004
    Points : 1 543
    Points
    1 543

    Par défaut

    oui c'est bizarre
    Si la réponse vous a aidé, pensez à cliquer sur +1

Discussions similaires

  1. Problème de structure application Android
    Par chucknorrisop dans le forum Android
    Réponses: 4
    Dernier message: 04/11/2014, 12h00
  2. Problème application Android sur Galaxy S2
    Par frimeman dans le forum Android
    Réponses: 2
    Dernier message: 01/08/2011, 01h45
  3. Divers problèmes de performance sur une application Swing
    Par Julien Bodin dans le forum AWT/SWING
    Réponses: 4
    Dernier message: 06/09/2010, 15h28
  4. Problème de performance sur application WPF 4 (rendertransform ? cast ?)
    Par tom741 dans le forum Windows Presentation Foundation
    Réponses: 3
    Dernier message: 20/05/2010, 14h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo