Share
Une récente mise à jour de la plate-forme Android a ajouté une nouvelle classe appelée StrictMode (android.os.StrictMode). Cette classe peut être utilisée pour activer et appliquer diverses stratégies pouvant être vérifiées et rapportées. Ces stratégies incluent généralement des problèmes de codage de type de meilleure pratique, tels que la surveillance des actions effectuées sur le thread principal qui ne devrait pas l'être et d'autres pratiques de codage vilaines ou paresseuses..
StrictMode a différentes politiques. Chaque politique a différentes règles. Chaque stratégie a également différentes méthodes pour montrer quand une règle est violée. Nous allons d'abord les définir, puis donner un bref exemple de la façon dont ils sont utilisés..
Il existe actuellement deux catégories de stratégies disponibles. L'une est la stratégie de thread et l'autre est la stratégie de VM (machine virtuelle, à ne pas confondre avec la mémoire virtuelle). La politique de thread peut surveiller:
Les trois premiers éléments de cette liste expliquent assez clairement comment ils sont déclenchés. La quatrième est déclenchée simplement par un appel que vous pouvez faire à la classe. Vous feriez cela à partir de votre propre code, connu pour être lent. La détection des violations de stratégie se produit lorsque les appels sont effectués sur le thread principal. Par exemple, vous pouvez déclencher le? Code lent? violation à chaque fois que votre application télécharge et analyse une grande quantité de données.
La stratégie de machine virtuelle peut surveiller les problèmes suivants:
Alors que les deux premiers éléments sont explicites, le troisième l'est un peu moins. Le vérificateur d'objets fermables qui a fui surveille les objets qui doivent être fermés, via un appel à close () ou similaires, avant qu'ils ne soient finalisés..
Chaque stratégie dispose également d'une variété de moyens différents pour vous avertir lorsqu'une règle a été violée. Les violations peuvent être écrites dans LogCat (utile pour ces exemples de code lent), stockées dans le service DropBox (android.os.DropBox) ou provoquer le blocage de l'application. En outre, les violations de stratégie de thread peuvent faire clignoter l’arrière-plan de l’écran ou afficher une boîte de dialogue. Toutes ces méthodes peuvent être utilisées pour vous aider à cerner et à éradiquer ces failles d'application.
Pour activer et configurer StrictMode dans votre application, vous souhaiterez utiliser les méthodes StrictMode de setThreadPolicy () et setVmPolicy () le plus tôt possible dans le cycle de vie de votre application. En ce qui concerne la politique de thread, le thread sur lequel il a été lancé est également important (il surveille les erreurs uniquement sur ce thread, généralement le thread principal). Un bon endroit pour définir des stratégies est aux points d’entrée de votre application et de vos activités. Par exemple, dans une application simple, vous devrez peut-être simplement insérer le code dans la méthode onCreate () de la classe Activity de lancement..
Le code suivant active toutes les règles des deux stratégies actuelles. Une boîte de dialogue s'affiche chaque fois qu'une règle de stratégie de thread est violée.
StrictMode.setThreadPolicy (nouveau StrictMode.ThreadPolicy.Builder () .detectAll () .penaltyLog () .penaltyDialog () .build ()); StrictMode.setVmPolicy (nouveau StrictMode.VmPolicy.Builder (). DetectAll () .penaltyLog () .build ());
Vous ne devez pas laisser ce code activé dans une application de production. Il est conçu pour une utilisation en pré-production uniquement. Au lieu de cela, un drapeau peut être utilisé pour activer de manière conditionnelle StrictMode ou désactiver.
Une application en StrictMode ne se comporte pas différemment de la normale. Exécuter simplement votre application et tester comme vous le feriez normalement. L'exécution d'un script de test exhaustif qui teste en profondeur votre application et touche l'ensemble de la base de code avec StrictMode activé vous fournira probablement les résultats les plus utiles..
Voici un exemple de sortie LogCat lorsque nous exécutons une version de l'application TutList avec StrictMode activé (toutes les stratégies, toutes les règles):
09-04 16: 15: 34.592: DEBUG / StrictMode (15883): violation de la stratégie StrictMode; ~ duration = 319 ms: android.os.StrictMode $ StrictModeDiskWriteViolation: policy = 31 violation = 1 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.os.StrictMode $ AndroidBlockGuardPolicy.onWriteToDisk (StrictMode.Object : 1041) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.database.sqlite.SQLiteStatement.acquireAndLock (SQLiteStatement.java:219) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883). ): at android.database.sqlite.SQLiteStatement.executeUpdateDelete (SQLiteStatement.java:83) 09-04: 16: 15: 34.592: DEBUG / StrictMode (15883): at android.database.sqlite.SQLiteDatabase.SQLiteDatabase.ithSite.html. 1829) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.database.sqlite.SQLiteDatabase.update (SQLiteDatabase.java:1780) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883) : at com.mamlambo.tutorial.tutlist.data.TutListProvider.update (TutListProvider.java:188) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.content.ContentProvider $ Transport.update (ContentProvider) .java: 233) 09-04 1 6: 15: 34.592: DEBUG / StrictMode (15883): sur android.content.ContentResolver.update (ContentResolver.java:847) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur com.mamlambo.tial .tutlist.data.TutListProvider.markItemRead (TutListProvider.java:229) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): à l'adresse com.mamlambo.tutorial.tutlist.TutListFragment.List 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.support.v4.app.ListFragment $ 2.onItemClick (ListFragment.java:53) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883). ): sur android.widget.AdapterView.performItemClick (AdapterView.java:282) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.widget.AbsListView.performItemClick (AbsListView.java:1037) 09- 04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.widget.AbsListView $ PerformClick.run (AbsListView.java:2449) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): atroid. widget.AbsListView $ 1.run (AbsListView.java:3073) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): à l'adresse andro id.os.Handler.handleCallback (Handler.java:587) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.os.Handler.dispatchMessage (Handler.java:92) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.os.Looper.loop (Looper.java:132) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur android.app.ActivityActivityThread.main (ActivityThread.java:4123) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur java.lang.reflect.Method.invokeNative (Méthode native) 09-04 16: 15: 34.592: DEBUG / StrictMode ( 15883): sur java.lang.reflect.Method.invoke (Method.java:491) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run (ZygoteInit.java:841) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): sur com.android.internal.os.ZygoteInit.main (ZygoteInit.java:599) 09-04 16: 15: 34.592 : DEBUG / StrictMode (15883): à l'adresse dalvik.system.NativeStart.main (méthode native)
Vous pouvez le constater vous-même en ajoutant le code StrictMode à la version 13 de TutList. Il suffit de sélectionner un élément différent de la liste.
Que nous dit ce journal? Le simple fait de marquer un message comme lu aurait dû être fait hors du fil principal. Au lieu de cela, ça prend un tiers de seconde! Non seulement est-ce étonnamment lent, mais l’effet sur l’UI est notable.
Et voici à quoi ressemble le dialogue d'avertissement:
La plupart des avertissements générés par StrictMode doivent faire l'objet d'un suivi, mais tous les avertissements générés ne signifient pas qu'il y a un problème avec votre code. Il existe de nombreuses situations dans lesquelles, par exemple, vous savez qu'une lecture rapide à partir du disque sur le thread principal ne gênera pas sensiblement l'application. Ou peut-être avez-vous un autre code de débogage qui enfreint les règles qui ne seront pas activées dans une version de production.
Le premier moyen d'ignorer les violations de stratégie consiste à les documenter pour vous-même ou votre équipe et à les répertorier en tant que violations connues. La deuxième méthode consiste à ajouter explicitement du code pour arrêter de rechercher une violation de règle particulière juste avant l'exécution du code incriminé, puis à réactiver la détection de cette règle une fois le code incriminé terminé. Par exemple:
StrictMode.ThreadPolicy old = StrictMode.getThreadPolicy (); StrictMode.setThreadPolicy (nouveau StrictMode.ThreadPolicy.Builder (ancien) .permitDiskWrites () .build ()); doCorrectStuffThatWritesToDisk (); StrictMode.setThreadPolicy (old);
Ce code enregistre la stratégie en cours, crée une stratégie similaire qui ignore la violation d'écriture sur le disque, exécute le code qui effectue certaines écritures sur le disque, puis restaure la stratégie d'origine..
StrictMode est une classe utile dans l'arsenal d'outils de diagnostic disponibles pour les développeurs Android. Grâce à cette solution, les développeurs peuvent rechercher et résoudre des problèmes de performances subtils, des fuites d’objets et d’autres problèmes d’exécution difficiles à trouver. Utilisez-vous StrictMode? Existe-t-il d'autres stratégies que vous voudriez voir ajoutées à cette fonctionnalité du SDK Android??
Les développeurs mobiles Lauren Darcey et Shane Conder ont co-écrit plusieurs livres sur le développement Android: un livre de programmation en profondeur intitulé Développement d'applications sans fil Android, deuxième édition et Sams Teach Yourself Développement d'applications Android dans 24 heures, Deuxième édition. Lorsqu'ils n'écrivent pas, ils passent leur temps à développer des logiciels mobiles dans leur entreprise et à fournir des services de conseil. Vous pouvez les contacter par courrier électronique à l'adresse [email protected], via leur blog à l'adresse androidbook.blogspot.com et sur Twitter @androidwireless..
я я 
Accentsconagua