Discussion :

[Michael Guilloux]

Android Studio : découvrez en vidéo quelques astuces de productivité
Présentées lors de l’évènement Android Dev Summit 2015

Le 23 et le 24 novembre 2015 à Mountain View s’est tenu l’évènement Android Dev Summit. C’est la première conférence du genre que Google a organisée pour les développeurs Android depuis la sortie de la première version majeure d’Android Studio en décembre dernier. Pour la société, ce fut l’occasion pour dévoiler les nouveautés dans la préversion d'Android Studio 2.0, son EDI pour le développement d’applications Android. Pour les développeurs, il s’agissait également d’une circonstance favorable pour découvrir et apprendre, en direct, quelques-unes des manières les plus récentes et les plus intéressantes de faire usage des API, fonctionnalités et services.

Au cours de ces deux journées, l’équipe de développement d’Android Studio a animé une vingtaine de sessions techniques et keynotes, toutes disponibles en vidéos sur YouTube pour ceux qui ont manqué l’évènement en direct. Dans l’une de ces sessions, Google a présenté une gamme de fonctionnalités d’Android Studio qui ciblent particulièrement les développeurs expérimentés. Ces fonctionnalités avancées d’Android Studio sont explorées dans la vidéo suivante, où Google présente de nouvelles astuces de productivité pour aider dans le développement d’applications Android.

La vidéo (en anglais) dure un peu plus d’une heure. N’hésitez donc pas à revenir plusieurs fois pour continuer ou finir de la visualiser si vous n’arrivez pas à le faire dès la première lecture. N’hésitez pas non plus à partager avec les autres membres vos notes après lecture de la vidéo, et en discuter.

Vous trouverez également sur YouTube, les vidéos relatives aux autres sessions techniques qui ont été animées pendant l’évènement Android Dev Summit 2015.

Retrouvez en vidéo toutes les sessions techniques de l’évènement Android Dev Summit 2015

Voir aussi

Forum Android

[Hizin]

Alors...

DISCLAIMER : ce n'est pas un transcript, il y a donc certaines tournures ou phrases que j'ai remanié en conservant le sens

• Premier orateur : Tor Norbye -> raccourcis pratiques (0:30) :
  • différence entre complétion via entée (insert la complétion) et tabulation (remplace "un appel")
  • propositions basiques via ctrl + space et propositions complexes via ctrl + shift + space (et complexe ET contextuel en pressant une seconde fois)
  • sélection de mots/parties de ligne via le raccourci de la "extended search" (mac : cmd + ↑ / cmd + ↓ ; windows : ctrl + w ; linux : ?)
  • les intentions : faire un alt + entrée avec le chariot à un endroit pour que celui-ci propose des trucs (remplacer "a" par 'a' ; flip equals ; "invert if branches" ...)
  • lors d'un warning : l'intention proposant de supprimer le warning propose diverses portées en les mettant en surbrillance
  • les live templates : iter, fori, sout... Pour Android, je vous suggère fortement de créer un live template pour votre classe de Log (à voir dans editor -> live templates)
  • live template postfixe : maList.for + "tab" => crée une boucle for sur maList
  • la recherche filtrée disponible à peu près dans n'importe quelle tool window (et partout, en fait)
  • gros morceau : le remplacement structurel : permet de faire une recherche (et des remplacements) avec des variables en évitant les regex + c'est un moyen de créer des warning customisé (vers 8:30' de la vidéo) et de créer son quickfix en même temps
  • XML : l'utilisation de tools:showIn permet de d'inclure un fragment dans un autre sur la prévisualisation, ce qui permet de directement se rendre compte
  • XML : l'utilisation de "tools:XXX" en général qui permet d'influer uniquement sur la prévisualisation et qui est ignoré au runtime (permet d'éviter les données de test en runtime)
  • L'utilisation de "View#isInEditMode" dans le code pour modifier les prévisualisations pour éviter les "images grises" en cas de vue custom (ce code est utilisée uniquement pour la prévisualisation)
  • XML : l'utilisation de "tools:listItem" pour faire une prévisualisation "réelle" des items d'une liste
  • warning de ressources : "nom incorrect" engendré par le build.gradle par l'instruction "resourcePrefix" dans "Android"
  • pour les bibliothèques : gestion des visibilités des ressources "<resources><public></public></resources>" (vers 15:20') ; permet d'éviter que les ressources soient suggérées dans l'auto-complétion (ou tout simplement exposées)
  • resource shrinking (17:00) : dans le build.gradle, dans le buildType : "shrinkResources true" (ne prend pas les ressources inutilisées en étant le plus prudent possible) ; on influence dessus via "tools:strictMode" dans les fichiers de ressources. M'a l'air complexe, faudra un peu plus qu'un passage de 2 minutes dans une vidéopour pouvoir l'utiliser
  
  
• Deuxième orateur : Siva Velusamy -> Débuggueur (19:55)
  • "Analyze stacktrace" : permet de C/C une stacktrace et de la rendre interactive (+coloration) + possibilité de la rendre intelligible si proguard est utilisé + option pour "marquer" les fichiers ayant été changé avec couplage au système de versionning
  • application arrêtée sur un breakpoint : double clic sur un objet bitmap permet de le voir ; clic droit sur un int représentant une ressource et choisir "view as -> ..." permet d'avoir la valeur réelle
  • utilisation des annotations (exemple : @DrawableRes) pour aider le debuggueur
  • il est possible de ne pas utiliser le toString par défaut pour les valeurs affichées dans le debugueur via "clic droit -> customize data view" (n'a pas fonctionné durant la démo)
  • sélectionner du texte et évaluer l'expression (Rajout personnel : faisable aussi via les "watch")
  • utilisation des breakpoints conditionnel : faire un clic droit sur un breakpoint et remplir l'expression (obligatoirement booléenne) ; il peut aussi ne rien arrêter et réaliser un log (via le menu "more")
  
  
• Troisième orateur : Alex Ruiz -> Gradle integration (29:37)
  • fonctionnalité "importer un jar/aar" dans "menu -> nouveau module" + rajout dans le build.gradle d'une dépendance "compile project(XXXX)"
  • Gradle task view (volet "Gradle" sur la droite de l'IDE par défaut) pour lancer une tâche Gradle seule (possibilité de devoir réparer certaines configurations en rajoutant le préfixe ":app:" )
  • volet "build variants" (par défaut sur la gauche) permet de voir les diverses "variantes" d'un projet et de sélectionner celui qu'on lance (debug, relase, test...)
  • Problème de refactor sur les TU car un seul artefact pour être sélectionné à la fois (Android Test OU TU) ; pour palier à ça, une fonctionnalité expérimentale dans "prefs -> build, execution, deployment -> build tools -> gradle -> experimental" qui se nomme "Enable all test artifacts (Unit Test and Instrumentation Test) in Android Projects"
  
  
• Quatrième speaker : Michal Bendowski Tests (37:25)
  • intention "create test" lorsque le chariot est sur le nom de la classe (dans son prototype)
  • intention "move initializer to setUp method"
  • raccourci pour sauter de la classe de test à l'implémentation (mac : shift + cmd + t)
  • le refactor de la classe testée change aussi les tests
  
  
• Cinquième oratrice : Kathryn Shih -> Support C++ (disclaimer : j'y connais rien) (41:45)
  • support des fichiers C++
  • support de la documentation doxygen (permet d'avoir les mêmes "infobulles" de doc qu'avec la Javadoc)
  • dans la configuration de debug, le type de debug "Hybrid" (onglet "debugger") permet de débugguer Java et C++
  • (souci de pour attacher le debugger)
  • linking de fichiers C++ (vers 44:40), feature expérimental
  • dans le build.gradle, propriétés ndk pour le plugin android (android.ndk)
  • (un débboggueur sauvage apparaît)
  • déboguer du C++ prend plus de temps à cause des liaisons à réaliser
  • parle d'un "split flag" pour du C++ (pas très bien compris cette partie) et demande des feedback dessus
  • le déboggueur en pas à pas permet de passer du Java au C++ (et vice-versa) et les variables commencent à être visibles (et lisibles)
  • semble y avoir un début de support de profiling du GPU avec capture des rendus et frame (48:40) avec possibilité d'avoir divers aperçu (wireframe, depth buffer...) ainsi que les étapes de rendu, l'état du GPU (contexte, shaders...)
  
  
• Sixième speaker : Esteban de la Canal -> Profiling (51:25)
  • showcase du profiling
  • Android Monitor
  • Le cache mis en place ne fonctionne pas : requête au retour arrière sur image déjà téléchargée
  • Souci sur le filtre sépia : le CPU n'arrête pas son boulot
  • le filtre "sharpen" crée un souci de mémoire : mémoire en scie; ce pattern est typiquement beaucoup d'allocations en très peu de temps et le GC est invoqué plusieurs fois
  • Utilisation de "l'allocation tracker" : un thread fait plus de 60 000 allocations -> permet de pointer la méthode faisant les allocations et découvrir une allocation monstrueuse de long
  • Sur l'allocation tracker, il y a la vue "group by allocator", qui permet d'agréger les allouants, en utilisant la recherche filtrée, cela permet de ne pas prendre en compte les bibliothèques tierces, ce qui est pratique si les appels à celles-ci sont coûteuses
  • études sur les fuites d'activités ensuite ; la mémoire augmente encore et encore et encore au fur et à mesure que les activités sont redémarrées
  • en ce cas, l'utilisation du heap dump est utile, surtout son volet "analyzer task" qui permet de détecter certains patterns automatiquement (peu fourni pour le moment, ne contient que la détection des fuites d'activités ainsi que les duplications de string)
  • cette vue permet de voir quelles sont les références vers l'objet fuité et c'est ordonné par "profondeur de référence"
  • outil GPU monitor (expérimental) : désactivé par défaut car peut créer des interférences sur les autres sondes ; sensiblement identique à l'option développeur "Enable GPU profiling" mais dans l'IDE ; possède une ligne indiquant les 60 FPS
  
  
• Questions ((1:09:23))
  • est-ce que les outils de profiling peuvent être utilisés sans Android Studio ?
    • Réponse : On est en train de tout intégrer dans Android Studio
  • Avez-vous des news sur le profiling mémoire pour le NDK, au sujet de valgrind ?
    • Réponse : Pas de MaJ, mais on est au courant du grand besoin d'avoir des outils d'analyse pour le NDK
  • Pour réduire les ressources, il y a des annotations, comment faites-vous pour les autres ressources, comme celles dans raw ?
    • Réponse : Il devrait y avoir les mêmes possibilités, utilisez raw plutôt que values (disclaimer : pas très bien compris la question ni la réponse)
  • Comment bien organiser ses ressources lorsque que l'on a énormément de layout ou autre ?
    • Réponse : on est au courant de ce problème, mais je ne crois pas qu'il y ai de solution. Il y a le fait d'utiliser des dossiers imbriqués et le dire à Gradle, mais ce n'est pas idéal. La meilleure solution à l'heure actuelle serait d'utiliser des préfixes.
  • Vous nous avez montré comment créer des warning en local (avec la recherche structurelle), mais comment les partager à toute l'équipe ?
    • Réponse : Nous encourageons à commit le dossier .idea, car il contient le style de code par exemple, et je crois qu'au moins la recherche structurelle est sauvée dedans.
  • Avez-vous des plans pour ajouter la commande strace (ou quelque chose du genre) dans IntelliJ ?
    • Réponse : Oui.
  • Question sur "find usages", y-a-t-il un moyen facile d'éviter de chercher dans les dossiers de build ?
    • Réponse : Je crois que c'est actuellement un bug (vous n'avez plus qu'à le corriger ). On doit encore bosser pour faire en sorte que intermediates et build ne soient pas dans le refactor ni dans le find usage
  • Dans certains de mes projets, le débuggueur n'arrive pas à résoudre mes variables ou à les évaluer, êtes-vous au courant ? Avez-vous un remède ?
    • Réponse : C'est un peu trop spécifique sans contexte. Si vous pensez que c'est un bug, créez un ticket. Normalement, tant que les variables sont dans le scope, elles devraient être résolues.
  • (pas très bien compris la question) Planifiez-vous d'intégrer des outils comme le Viewtree pour aider le déboggage ?
    • Réponse : C'est correct, ça arrivera bientôt, sans doute l'année prochaine. Je pense que tout les outils qui sont et étaient dans le DDMS feront à terme parti d'Android Studio
  • De nouveau concernant les outils de profiling : planifiez-vous de les créer headless et appelable depuis des scripts pour réaliser des tests de performances automatisés ?
    • Réponse : Oui. Les outils sont/seront appelables par ligne de commande

[spidetra]

Pour les raccourcis, une autre présentation complémentaire plutôt bien faîtes :