Dernièrement, j’ai été amené à tester une nouvelle application Android. Je me suis rapidement rendu-compte que quelque chose clochait. L’interface utilisateur n’était pas fluide :

  • saccades
  • bouton n’affichant pas leur status pressés
  • figeages

Les personnes qui ont l’habitude de développer des IHMs comprennent tout de suite d’où vient le problème : des traitements, dits longs, sont réalisés dans le thread qui est chargé d’afficher l’interface. Ceci implique que le thread a moins de temps pour mettre à jour l’écran d’où les impressions de non-fluidité. Ce problème n’est pas propre à Android mais il est encore plus flagrant sur les plate-formes mobiles. En effet, même si nos smartphones sont de plus en plus puissants, ce ne sont pas encore des machines de guerre. De plus, ces applications nécessitent souvent d’accéder à un espace stockage (souvent lent) ou à des ressources réseaux (qui peuvent se révéler très très lents également).

Il faut donc toujours avoir à l’esprit de ne pas mettre de traitement lourd dans le thread principal de son application Android. Même en étant attentif, personne n’est à l’abri d’une erreur, voir d’une mauvaise surprise (via l’utilisation de composants externes). C’est pourquoi le SDK Android propose une API qui jouera le rôle de garde-fou lors de vos développements. Elle se nomme StrictMode.

Elle permet de détecter les accès disque ou réseaux dans le thread principal ainsi que les fuites de mémoire (notamment sur les Cursor, Closeable, Activity, etc…). Les notifications de ces détections peuvent avoir plusieurs formes (à définir selon vos préférences) :

  • traces applicatives
  • boite de dialogue
  • plantage de l’application

Cette API ne doit être activée qu’en phase de développement. Certains utilisent donc une constante DEVELOPER_MODE, d’autres la constante BuildConfig.DEBUG. Personnellement, j’ai opté pour une variable dans un fichier de ressource (plus facile à modifier automatiquement à la génération de l’APK à distribuer.

Voici donc un exemple de code pour activer le StrictMode :

if (context.getResources().getBoolean(R.bool.developer_mode)) {
	StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
		.detectAll()
		.penaltyLog()
		.penaltyDeath()
		.build());
	StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
		.detectAll()
		.penaltyLog()
		.penaltyDeath()
		.build());
	}

Et aussi l’exemple pour la désactiver :

StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.LAX);
StrictMode.setVmPolicy(StrictMode.VmPolicy.LAX);

Maintenant, vous n’aurez plus d’excuse pour avoir une IHM qui rame ! 😛

SeBAndroidDéveloppementandroid,optimisationDernièrement, j'ai été amené à tester une nouvelle application Android. Je me suis rapidement rendu-compte que quelque chose clochait. L'interface utilisateur n'était pas fluide : saccades bouton n'affichant pas leur status pressés figeages ... Les personnes qui ont l'habitude de développer des IHMs comprennent tout de suite d'où vient le problème : des traitements,...Un blog, c'est un blog !