Optimisation de l'application Android avant sa sortie [fermé]

Je suis dans une situation « particulière » quant à l' efficacité de mon programme. Je suis maintenant à une phase où je dois améliorer les performances de l'application et réduire la consommation de la batterie .

Avant la question:

• Tout d'abord, mon application fonctionne. Il fonctionne très bien - pas d' erreurs que ce soit .
• Deuxièmement , j'ai lu Optimiser la durée de vie de la batterie sur le site Web des développeurs Android et j'ai optimisé les petites choses qu'ils ont demandées. Pas de problème que ce soit .

Maintenant, je suis curieux de connaître les correctifs spéciaux d' autres développeurs qu'ils ont utilisés pour optimiser leurs propres applications. Des choses que les utilisateurs peuvent ne jamais reconnaître ou auxquelles ils ne font pas attention. Cependant, les correctifs augmenteront la durée de vie de la batterie ou aideront à améliorer la maintenance de l'application.

Alors, quelle (s) astuce (s) d'optimisation unique (s)?

Je suis dans une situation particulière où je recherche vraiment des connaissances et je pense que ce sera une excellente occasion de partager les connaissances des développeurs sur une situation dans laquelle ils ont tous été.

Veuillez voter pour les bonnes réponses car cela encouragera les grands développeurs à partager leurs connaissances.

À un moment donné, vous arriverez au point où l'utilisation d'astuces connues atteindra leurs limites. La meilleure chose à faire à ce stade est de profiler votre code et de voir quelles zones sont les goulots d'étranglement en fonction de vos besoins spécifiques.

Enquête sur l'utilisation de la RAM à l'aide de MAT et à l' aide de Traceview : un article sur la façon d'utiliser les outils pour profiler votre application.

Suivez et écrasez les allocations. Plus vous allouez, plus le ramasse-miettes devra souvent s'exécuter, empêchant votre processus de faire quoi que ce soit d'autre pendant des périodes de temps relativement longues, par exemple 100 ms environ.

Le meilleur outil que je connaisse pour cela est le suivi des allocations inclus dans DDMS .

Non seulement GC peut avoir un impact sur l'expérience utilisateur, mais les allocations superflues et GC consomment certaines ressources informatiques.

Voici un exemple et une petite astuce. Dans mon application, j'ai une horloge qui indique l'heure (audio) actuelle, y compris le dixième de seconde. Ceci est mis à jour souvent. Et TextView effectue des allocations en interne chaque fois que vous appelez setText () avec un CharSequence. Mais il n'alloue rien avec la variante setText (char [] text, int start, int len). Ce n'est pas documenté, et personne n'a répondu lorsque j'ai posé la question.

Il y en a beaucoup comme ça. Et c'est l'une des raisons pour lesquelles mon application contient 50% de code natif (mais il y a d'autres raisons).

En dehors de cela, je peux vous recommander d'expérimenter avec ProGuard . Il effectue plusieurs passes d'optimisation et enregistre ces informations en tant que méthodes inutilisées dans le projet, ce qui peut vous aider à supprimer les restes de votre code.

Si votre application dispose de beaucoup de temps d'écran, utilisez le noir partout où vous le pouvez . Cela réduira la consommation de la batterie de la pire partie de l'appareil: l'écran, en particulier dans les téléphones et tablettes AMOLED.

Pour les applications avec plusieurs activités, vérifiez que vous ne redémarrez pas des activités qui doivent simplement être mises au premier plan à l'aide des indicateurs d'intention appropriés. Vérifiez que votre tas est sous contrôle et que des vues, des liaisons et des contextes inutiles ne sont pas créés.

Je trouve que le meilleur outil pour vous montrer tout cela pendant l'exécution de l'application est:

adb shell dumpsys meminfo 'your apps package name'

Lorsque vous utilisez SQLlite, accordez une attention particulière aux index. Ne présumez rien. J'ai eu d'énormes accélérations dans Zwitscher, lorsque j'ai mis des index sur des colonnes couramment utilisées pour la recherche.

Quelques conseils qui peuvent vous aider à optimiser votre application en termes d' interface utilisateur :

• utiliser convertViewpour les adaptateurs de liste - ce serait très coûteux si vous créez une nouvelle vue à l'intérieur Adapter.getView()car cette routine est appelée pour chaque position dans la liste. L'utilisation convertViewvous permet de réutiliser la vue déjà créée. Un bon exemple (avec l'utilisation de ViewHolder) peut être trouvé dans ApiDemos .

• Il se peut que vos mises en page ne soient pas entièrement optimisées et puissent être améliorées (par exemple en utilisant la fusion ou la suppression de parents). L'outil layoutopt d' Android trouvera une telle situation pour vous. Il peut être utilisé avec HierarchyViewer pour inspecter des vues individuelles. Plus d'infos ici .

• supprimer l'arrière-plan dessinable - Le framework Android avait (a-t-il encore?) un problème pour détecter les vues à dessiner. Il est possible que votre arrière-plan (par défaut) dessiné ne soit dessiné que pour être ensuite masqué par votre interface utilisateur opaque. Pour se débarrasser de ce dessin inutile, supprimez simplement l'arrière-plan dessinable.

Cela peut être fait en utilisant un style personnalisé

<resources>
    <style name="Theme.NoBackground" parent="android:Theme">
        <item name="android:windowBackground">@null</item>
    </style>
</resources>

Quelques conseils qui peuvent vous aider à optimiser votre application en termes de utilisation batterie :

• vérifiez le type de réseau et attendez que l'utilisateur arrive dans la zone avec wifi ou 3G (et non en itinérance) et permettez-lui seulement d'utiliser la connexion

• utilisez gzip pour les données textuelles autant que possible pour accélérer le téléchargement et l'analyse

• recycler des objets Java complexes tels que XmlPullParserFactory/ BitmapFactory/ StringBuilder/ Matcheretc.

Pour plus d' astuces pile Voir codage pour la vie - vie de la batterie, qui est .

Une chose à laquelle penser: NE PAS abuser de String, par exemple dans une énorme boucle. Cela créera de nombreux objets String qui doivent être GC. L'exemple "Bad coding" produira 2 objets chaîne à chaque boucle. L'exemple suivant ne produira qu'une seule chaîne finale et un seul constructeur de chaînes. Cela fait une énorme différence lors de l'optimisation d'énormes boucles pour la vitesse. J'ai beaucoup utilisé stringbuilder lors de la création de mon application Android Wordlist Pro, et il est devenu très rapide de parcourir 270000 mots en un rien de temps.

    //Bad coding:
    String s = "";
    for(int i=0;i<999999;i++){
        s = "Number=";
        s = s + i;
        System.out.println(s);
    }

    //Better coding
    final String txt = "Number=";
    StringBuilder sb = new StringBuilder();
    for(int i=0;i < 999999;i++){
        sb.setLength(0);
        sb.append(txt);
        sb.append(i);
        System.out.println(sb);
    }

J'ai écrit un article de blog plus détaillé sur la question. lire ici

J'imagine que l'utilisation de variables «finales» partout où c'est possible pourrait également améliorer la vitesse d'exécution.

Optimisez vos images PNG avec des outils comme OptiPNG et PNGCrush pour supprimer quelques (kilo) octets de la taille de l'APK. Les conseils d'optimisation d'image pour les sites Web s'appliquent également ici: utilisez des formats d'image appropriés, jouez avec la compression JPG, envisagez d'utiliser des transparents binaires au lieu de transparents 8 bits, etc.

Si vous expédiez grand PNGs avec canal alpha, vous pouvez échanger une certaine taille APK pour la vitesse de démarrage et utiliser séparés pour JPGs canaux RVB et A .

Si vous établissez des connexions HTTP, vérifiez que votre client HTTP utilise la compression de contenu. S'il met en cache les réponses HTTP reçues, vérifiez qu'il comprend et utilise correctement les en-têtes HTTP liés à la mise en cache.

Si vous avez des opérations réseau, essayez de réutiliser la même instance httpclient. Évitez d'utiliser des expressions régulières.

Essayez d'utiliser DDMS pour suivre tous les threads en cours d'exécution dans le système. Par exemple, j'ai remarqué que j'utilisais webview pour afficher du contenu html, j'ai remarqué que cela crée peu de threads pour la gestion des sessions de gestion des cookies, etc., ce qui a augmenté mon empreinte mémoire. Donc, à moins que vous n'ayez un besoin sérieux d'afficher du code HTML complexe, essayez d'utiliser la classe d'utilitaire normale "Html" dans Android pour afficher le contenu HTML. Cela peut être utile pour les personnes qui affichent Eula car eula typicall contient du texte html.

Si vous devez effectuer des opérations réseau, essayez d'utiliser AndroidHttpClient si vous êtes débutant, il possède de bonnes capacités pour la mise en cache des sessions SSL et tout ce qu'il aide vraiment à améliorer vos performances. Définissez toujours les délais d'expiration de votre connexion socket à environ 60 secondes ou à des valeurs finies, car des délais infinis peuvent provoquer des blocages, en particulier si vous interrompez votre connexion pendant la prise de contact SSL.

Utilisez Android Resource Tracker pour rechercher les ressources inutilisées de votre projet qui peuvent être supprimées.

Évitez d'utiliser XPath si vous pouvez analyser votre entrée XML en utilisant des routines de manipulation de chaînes pour obtenir le texte entre les balises. J'ai testé et je peux confirmer une amélioration 10x dans ce cas, sur un ensemble de données de 50000 éléments, sur un HTC Desire.

Je sais que je rejoins un peu plus tard cette conversation, mais ce serait parfait d'avoir beaucoup de bons conseils en un seul endroit, alors j'espère que ce fil sera vivant et mis à jour assez souvent. Mes conseils:

• Ne bloquez pas le thread d'interface utilisateur avec des travaux coûteux, l'utilisateur partira s'il n'y a pas de réponse de l'application (utilisez AsyncThreads).
• Utilisez le nouvel outil LINT qui scanne les sources de projets Android à la recherche de bogues potentiels.

..sera mis à jour..