Share
Peu importe l’innovation et l’utilité de votre application Android, si elle est lente, sujette au gel ou si elle a la mémoire de porcs, personne ne voudra l’utiliser..
Les performances sont très importantes, mais vous pouvez aussi facilement les oublier lorsque vous êtes occupé à mettre la dernière main à votre magnifique interface utilisateur ou à proposer de nouvelles fonctionnalités intéressantes pour votre application..
Jusqu'à ce que les critiques négatives sur Google Play commencent à être diffusées.
Dans cet article, vous découvrirez les problèmes de performances courants que chaque développeur Android doit connaître. Vous apprendrez à vérifier si ces problèmes se produisent dans vos propres projets, à l'aide des outils fournis par Android SDK-plus, un outil déjà installé sur votre appareil Android..
Si vous découvrez un problème de performances dans votre application, vous voudrez évidemment le résoudre. En cours de route, nous verrons également comment utiliser les outils du SDK Android pour collecter plus d'informations sur les problèmes de performances que vous avez découverts. Une fois que vous avez ces informations, vous comprendrez mieux comment perfectionner les performances de votre application et créer au final une application que les utilisateurs pourront utiliser. amour en utilisant.
L'interface utilisateur de votre application est votre connexion à l'utilisateur, mais créer quelque chose qui a l'air bien n'est que la moitié de la bataille. Vous devez également vous assurer que votre interface utilisateur affiche rapidement et fonctionne correctement..
L’une des causes les plus courantes d’une interface utilisateur lente et insensible est la overdraw. La superposition est l’endroit où vous perdez du temps de traitement du GPU en coloriant en pixels qui ne sont colorés que par quelque chose d’autre..
Par exemple, imaginez un arrière-plan bleu avec du texte. Android ne se contente pas de peindre les zones de bleu visibles par l’utilisateur, il peint tout le fond bleu puis dessine le texte par-dessus. Cela signifie que certains pixels sont colorés deux fois, ce qui est en surimpression.
Il est inévitable qu’un peu d’arrière-plan, comme dans l’exemple ci-dessus, soit utilisé. Toutefois, un surdosage trop important peut avoir un impact notable sur les performances de votre application. Par conséquent, vous souhaiterez le réduire autant que possible..
Il est relativement facile de vérifier si votre application est à découvert. De grandes quantités de surdimensionnement peuvent indiquer un problème sous-jacent avec l'interface utilisateur de votre application, telles que des vues redondantes - nous en parlerons plus tard. Pour ces raisons, lorsque vous testez votre application pour détecter des problèmes de performances, le surmenage est un bon début..
La bonne nouvelle est que votre appareil Android possède déjà une fonctionnalité intégrée qui vous permet de vérifier le montant du tout application installée sur votre appareil.
Étant donné que cette fonctionnalité existe sur votre appareil, la première étape consiste à installer l'application que vous souhaitez tester sur votre appareil Android. Ensuite, pour vérifier le montant du découvert, ouvrez simplement le périphérique de votre appareil. Réglages, sélectionner Options de développeur, et appuyez sur Déboguer le dépassement de GPU suivi par Afficher les zones de dégagement.
Cet outil utilise des blocs de couleur pour mettre en évidence les différentes quantités de sur-dessin. La seule chose à faire est de lancer l'application que vous voulez tester et de voir quelle est la situation de surimpression..
Une fois que vous avez identifié une zone de surimpression importante, le moyen le plus simple de la réduire consiste à ouvrir les fichiers XML de votre application et à rechercher les zones de chevauchement, en particulier les dessinables invisibles pour l'utilisateur et les arrière-plans en regard. être dessiné l'un sur l'autre.
Vous devez également rechercher les zones dans lesquelles l'attribut background est défini sur blanc, même si un parent a déjà peint un arrière-plan blanc. Toutes ces choses peuvent causer un surmenage important.
Le système Android peut automatiquement réduire les cas simples de surimpression, mais il convient de noter que cela ne s'étend pas aux vues personnalisées complexes où Android n'a pas une idée de la façon dont vous dessinez votre contenu..
Si vous utilisez des vues personnalisées complexes dans votre application, vous pouvez définir les limites que vous pouvez dessiner pour vos vues à l'aide de la commande clipRect méthode. Pour plus d'informations, je vous recommande de consulter la documentation Android officielle..
Une autre cause fréquente de problèmes de performances est la hiérarchie de vues de votre application. Pour rendre chaque vue, Android passe par trois étapes:
Le temps nécessaire à Android pour effectuer ces étapes est proportionnel au nombre de vues dans votre hiérarchie. Cela signifie que l'un des moyens les plus simples de réduire la vitesse de rendu de votre application consiste à identifier et à supprimer les vues qui ne contribuent pas à l'image finale que l'utilisateur voit sur son appareil..
Même si toutes les vues de votre hiérarchie sont nécessaires, leur agencement peut avoir un impact significatif sur la phase de mesure du processus de rendu. En règle générale, plus votre hiérarchie de vues est profonde, plus la phase de mesure est longue à terminer..
Au cours du processus de rendu, chaque vue fournit ses dimensions à la vue parent. Si la vue parent découvre un problème avec l’une de ces dimensions, elle peut obliger chaque enfant à effectuer une nouvelle mesure..
Des réévaluations peuvent même se produire lorsque n'est pas une erreur. Par exemple, les dispositions relatives doivent souvent mesurer leurs enfants deux fois pour que tout soit en ordre. Layouts linéaires avec des enfants utilisant le layout_weight paramètre mesure régulièrement chaque enfant deux fois.
En fonction de la disposition de vos vues, les mesures et les réévaluations peuvent être un processus long et coûteux qui a un impact notable sur la vitesse de rendu de votre application..
La clé pour garantir un rendu rapide et fluide de votre interface utilisateur est de supprimer toutes les vues inutiles et de rechercher des opportunités pour aplatir votre mise en page..
Le SDK Android comprend un outil, Visualiseur de hiérarchie, qui vous permet de visualiser toute votre hiérarchie de vues. Cet outil vous aide à repérer les deux vues redondantes. et dispositions imbriquées.
Avant de regarder de plus près le Visualiseur de hiérarchie outil, il y a quelques bizarreries dont vous devez être conscient. Tout d'abord, Hierarchy Viewer ne peut communiquer qu'avec une application en cours d'exécution., ne pas le code source de votre application. Cela signifie que vous devez installer l'application que vous souhaitez tester sur votre appareil Android ou utiliser un émulateur..
Il y a une autre, plus grande prise cependant. Par défaut, Hierarchy Viewer ne peut communiquer qu'avec un périphérique exécutant une version de développement du système d'exploitation Android. Si vous ne possédez pas de périphérique de développement, vous pouvez contourner cette restriction en ajoutant le paramètre ViewServer classe à votre application.
Une fois que vous êtes prêt à utiliser Hierarchy Viewer, lancez Android Studio et sélectionnez Outils dans la barre d’outils, suivi de Android et Moniteur de périphérique Android.
Clique le Vue hiérarchique bouton à droite, comme indiqué dans la capture d'écran ci-dessous.
Sur le côté gauche de l'écran se trouve un les fenêtres onglet qui répertorie tous les appareils et émulateurs Android détectés. Sélectionnez votre appareil et vous verrez une liste des processus en cours d'exécution sur cet appareil. Sélectionnez le processus que vous souhaitez examiner de plus près et trois zones de Hierarchy Viewer seront mises à jour automatiquement..
Ces trois fenêtres fournissent trois représentations visuelles différentes de la hiérarchie des vues:
Ces trois fenêtres sont liées. Si vous sélectionnez une vue dans une fenêtre, elle apparaîtra en surbrillance dans les deux autres. Vous pouvez utiliser les trois fenêtres simultanément pour traquer les vues redondantes cachées dans la hiérarchie des vues..
Si vous ne savez pas si une vue contribue réellement à l'image finale, rendez-vous simplement à Vue d'arbre et cliquez sur le noeud en question. Vous verrez un aperçu de la manière dont cette vue apparaîtra à l'écran pour vous permettre de voir exactement en quoi cette vue contribue à votre application..
Mais ce n’est pas parce qu’une vue contribue à l’image finale rendue qu’elle ne contribue pas non plus à un gros problème de performances. Vous avez déjà vu comment vous pouvez utiliser Hierarchy Viewer pour repérer des mises en page évidentes imbriquées, mais que se passe-t-il si cette imbrication qui nuit à la performance n'est pas si évidente? Ou que se passe-t-il si quelque chose d'autre provoque un affichage lent du rendu??
La bonne nouvelle est que vous pouvez également utiliser le visualiseur de hiérarchie pour déterminer le temps qu'il faut à chaque vue pour parcourir les différentes phases du processus de rendu. Cela vous permet de vous concentrer sur les problèmes de rendu qui peuvent ne pas être évidents au premier abord.
La section suivante explique comment utiliser la visionneuse hiérarchique pour profiler les différentes vues de votre mise en page afin de repérer tout problème de rendu susceptible de se dissimuler sous la surface..
Le moyen le plus simple d'identifier les goulots d'étranglement dans votre interface utilisateur consiste à collecter des données sur le temps nécessaire à chacune de vos vues pour terminer la phase de mesure, de mise en page et de dessin du processus de rendu..
Vous pouvez non seulement utiliser Hierarchy Viewer pour rassembler ces informations, mais Hierarchy Viewer les affiche également de manière visuelle et facile à comprendre, ce qui vous permet de voir rapidement quelles vues ne fonctionnent pas bien..
Hierarchy Viewer n'affiche pas les temps de rendu par défaut. Vous pouvez ajouter cette information en allant à Vue d'arbre et en sélectionnant le nœud racine de la partie de l’arbre que vous voulez tester. Ensuite, appelez la fonction de profilage du visualiseur de hiérarchie en cliquant sur l'icône représentant un diagramme de Venn vert, rouge et violet, comme indiqué dans la capture d'écran ci-dessous..
Trois points de couleur apparaîtront sur chaque nœud de cette partie de la hiérarchie. De gauche à droite, ces points représentent:
Chaque point a aussi une couleur assignée:
Après avoir collecté ces données, vous saurez non seulement les vues à optimiser, mais vous saurez exactement quelle partie du processus de rendu ralentit le rendu de cette vue..
Sachez simplement que, même si les vues avec des points jaunes et rouges peuvent être le lieu logique pour commencer vos efforts d'optimisation, ces indicateurs de performance sont relatifs.aux autres noeuds profilés dans la hiérarchie de vues. En d'autres termes, vous aurez toujours des vues qui s'affichent plus lentement que d'autres.
Avant de commencer à parcourir votre code pour trouver des moyens d'optimiser une vue particulière, demandez-vous si cette vue a une bonne raison de générer un rendu plus lent que les autres noeuds profilés ou s'il s'agit vraiment d'une occasion de réduire le temps de rendu de votre application..
Bien qu'Android soit un environnement géré par la mémoire, ne vous laissez pas envahir par une fausse impression de sécurité: des fuites de mémoire peuvent toujours se produire. C’est parce que le ramasse-miettes (GC) peut seulement supprimer les objets qu'il reconnaît comme inaccessibles. S'il ne repère pas un objet inaccessible, cet objet ne sera pas récupéré..
Ces objets inaccessibles traînent, polluent votre tas et occupent un espace précieux. Au fur et à mesure que votre application continue de fuir des objets, la quantité d'espace utilisable devient de plus en plus petite, ce qui déclenche à son tour des événements GC plus fréquents et plus longs..
C'est une mauvaise nouvelle pour deux raisons. Premièrement, bien que les événements GC n'aient normalement pas d'impact significatif sur les performances de votre application, de nombreux événements GC survenus dans un court laps de temps peuvent entraîner une interface utilisateur lente et insensible. Le deuxième problème est que les périphériques mobiles ont d’abord tendance à manquer de mémoire. Ainsi, une fuite de mémoire peut dégénérer en erreur OutOfMemoryError et bloquer votre application..
Les fuites de mémoire peuvent être difficiles à détecter. Vous réaliserez peut-être que la mémoire pose un problème pour votre application lorsque vos utilisateurs commencent à se plaindre. Heureusement, le SDK Android propose des outils utiles que vous pouvez utiliser pour explorer votre application à la recherche de ces signes parfois subtils de fuites de mémoire..
Moniteur de mémoire est un moyen facile d'obtenir une vue d'ensemble de l'utilisation de la mémoire de votre application au fil du temps. Notez que cet outil ne peut se connecter qu'à une application en cours d'exécution. Assurez-vous donc que l'application que vous souhaitez tester est installée sur votre appareil Android et que celui-ci est connecté à votre ordinateur..
Cet outil est intégré à Android Studio. Vous y accédez donc en cliquant sur le bouton Mémoire vers le bas de votre IDE. Dès que Memory Monitor détecte votre application en cours d'exécution, il commence à enregistrer l'utilisation de la mémoire de votre application..
Si Memory Monitor ne démarre pas l'enregistrement, vérifiez que votre appareil est sélectionné dans le menu déroulant des appareils..
Si Memory Monitor renvoie un Aucune application débogable message, ouvrez Android Studio's Outils menu, sélectionnez Android, et assurez-vous Activer l'intégration adb est sélectionné. Cette fonctionnalité peut être capricieuse, vous devrez donc peut-être basculer Activer l'intégration adb par intermittence. Il peut également être utile de retirer votre appareil Android, puis de le reconnecter..
Une fois que Memory Monitor a détecté votre application en cours d'exécution, il affiche la quantité de mémoire utilisée par votre application en bleu foncé et la mémoire non allouée en bleu clair..
Passez du temps à interagir avec votre appareil tout en surveillant l'évolution de l'utilisation de la mémoire de votre application dans Memory Monitor. Finalement, la mémoire allouée augmentera jusqu'à ce qu'il ne reste plus de mémoire libre. À ce stade, le système libèrera de la mémoire en déclenchant un événement GC. Chaque fois que vous constatez une baisse importante de la mémoire allouée, cela indique qu'un événement GC s'est produit..
Les événements GC sont tout à fait normaux, mais ne vous inquiétez pas si votre application alloue beaucoup de mémoire en peu de temps ou si les événements GC deviennent plus fréquents. Ce sont les deux signes avant-coureurs d'une fuite de mémoire dans votre application..
Si vous utilisez Memory Monitor pour suivre une fuite de mémoire présumée sur une période de temps importante, le système Android peut compenser les demandes de mémoire croissantes de votre application en accordant à celle-ci un plafond de mémoire supérieur, point auquel le cycle recommence..
Il se peut même que votre application consomme tellement de mémoire que le système ne peut plus la rendre disponible. Si cela se produit, il y a quelque chose de grave dans la façon dont votre application utilise la mémoire..
Un autre outil qui peut vous aider à recueillir plus d'informations sur les fuites de mémoire et d'autres problèmes liés à la mémoire est le moniteur de périphérique Android. Tas languette.
le Tas Onglet peut vous aider à diagnostiquer les fuites de mémoire en affichant la quantité de mémoire allouée par votre système à votre application. Comme déjà mentionné, si la mémoire allouée continue d'augmenter, il s'agit d'un signe fort que votre application présente une fuite de mémoire..
Mais cet outil fournit également de nombreuses données sur l'utilisation du segment de mémoire de votre application, notamment le type d'objets alloués par votre application, le nombre d'objets alloués et la quantité d'espace occupée par ces objets. Ces informations supplémentaires peuvent s'avérer inestimables lorsque vous recherchez la source des fuites de mémoire et d'autres problèmes liés à la mémoire dans votre application..
Pour accéder à cet outil, lancez Android Device Monitor et sélectionnez le DDMS languette. dans le Dispositifs panneau, sélectionnez votre appareil et le processus que vous souhaitez examiner. Ensuite, sélectionnez le Tas comme illustré dans la capture d'écran ci-dessous et passez du temps à interagir avec votre application.
La sortie de segment de mémoire n'est affichée qu'après un événement GC. Par conséquent, pour renseigner cet onglet avec des données, vous devez soit attendre qu'un événement GC se produise naturellement, soit vous pouvez forcer un GC en cliquant sur l'icône correspondante. Cause GC bouton.
Une fois qu'un événement GC s'est produit, le Tas L'onglet sera mis à jour avec de nombreuses informations sur l'utilisation du tas de votre application. Ces données seront actualisées après chaque événement du GC..
Dans ce didacticiel, nous avons abordé certains des problèmes de performances les plus courants que vous devez connaître lors du développement d'applications Android, de surcharges, de fuites de mémoire et d'un rendu lent de l'interface utilisateur..
Vous avez également maîtrisé certains des outils que vous pouvez utiliser pour vérifier si ces problèmes se produisent dans vos propres projets Android et vous avez appris à rassembler plus d'informations sur les problèmes de performances rencontrés dans vos propres applications. Plus vous avez d'informations, plus vous avez de chances de trouver la cause du problème et de le résoudre..
Le SDK Android propose de nombreux autres outils pouvant vous aider à diagnostiquer et à résoudre les problèmes de performances. Si vous souhaitez en savoir plus, les pages de documentation Android officielles sur Traceview, dmtracedump et Allocation Tracker contiennent plus d’informations..
Accentsconagua