Share
Een recente update van het Android-platform heeft een nieuwe klasse toegevoegd, StrictMode (android.os.StrictMode). Deze klasse kan worden gebruikt voor het inschakelen en afdwingen van verschillende beleidsregels die kunnen worden gecontroleerd en gerapporteerd. Dit beleid omvat over het algemeen codeerproblemen van het type beste praktijk, zoals toezicht op acties die op de hoofdthema worden uitgevoerd en die niet zouden moeten zijn en andere ondeugende of luie codeermethoden..
StrictMode heeft verschillende beleidsregels. Elk beleid heeft verschillende regels. Elk beleid heeft ook verschillende manieren om te laten zien wanneer een regel wordt geschonden. We zullen deze eerst definiëren en dan een snel voorbeeld geven van hoe ze worden gebruikt.
Momenteel zijn er twee categorieën beleidsregels beschikbaar voor gebruik. De ene is het thread-beleid en de andere is het VM-beleid (virtuele machine, niet te verwarren met virtueel geheugen). Het threadbeleid kan controleren op:
De eerste drie items op deze lijst zijn relatief zelfverklarend over hoe ze worden geactiveerd. De vierde wordt geactiveerd door simpelweg een oproep die je naar de klas kunt doen. U doet dit vanuit uw eigen code waarvan bekend is dat deze traag is. De detectie van beleidsschendingen vindt plaats wanneer de oproepen op de hoofdthread worden gedaan. U kunt bijvoorbeeld de? Slow-code activeren? overtreding telkens wanneer uw toepassing een grote hoeveelheid gegevens downloadt en parseert.
Het VM-beleid kan de volgende problemen bewaken:
Terwijl de eerste twee items voor zichzelf spreken, is de derde iets minder. De gelekte afsluitbare objecten-checker controleert op objecten die moeten worden gesloten, via een oproep om te sluiten () of dergelijke, voordat ze worden gefinaliseerd.
Elk beleid heeft ook verschillende manieren om u te laten weten wanneer een regel is geschonden. Overtredingen kunnen worden geschreven naar LogCat (handig voor die trage codevoorbeelden), opgeslagen in de DropBox (android.os.DropBox) -service of de toepassing laten crashen. Bovendien kunnen schendingen van het regelbeleid de achtergrond van het scherm flitsen of een dialoogvenster weergeven. Al deze methoden kunnen worden gebruikt om u te helpen bij het op nul zetten en het uitbannen van deze applicatiestoringen.
Om StrictMode in uw toepassing in te schakelen en te configureren, wilt u de StrictMode-methoden van setThreadPolicy () en setVmPolicy () zo vroeg mogelijk in de levenscyclus van uw toepassing gebruiken. Als het gaat om het Thread-beleid, dat Thread it's ook op dingen lanceert (het kijkt alleen naar fouten op die thread, meestal de rode draad). Een goede plek om beleid in te stellen, is bij de toegangspunten tot uw toepassing en activiteiten. In een eenvoudige toepassing moet u bijvoorbeeld de code gewoon in de methode onCreate () van de klasse Activity starten zetten.
Met de volgende code kunnen alle regels voor zowel het huidige beleid worden gebruikt. Er wordt een dialoogvenster weergegeven als een regelregel in Discussie wordt geschonden.
StrictMode.setThreadPolicy (new StrictMode.ThreadPolicy.Builder () .detectAll () .penaltyLog () .penaltyDialog () .build ()); StrictMode.setVmPolicy (nieuwe StrictMode.VmPolicy.Builder (). DetectAll () .penaltyLog () .build ());
Laat deze code niet ingeschakeld in een productieapplicatie. Het is alleen bedoeld voor gebruik in de pre-productie. In plaats daarvan kan een vlag worden gebruikt om StrictMode voorwaardelijk in of uit te schakelen.
Een toepassing in StrictMode gedraagt zich niet anders dan normaal. Loop gewoon door je applicatie en test zoals je normaal zou doen. Het uitvoeren van een uitgebreid testscript dat uw applicatie grondig uitvoert en de volledige codebase raakt met StrictMode ingeschakeld, biedt u waarschijnlijk de meest bruikbare resultaten.
Hier is een voorbeeld van de LogCat-uitvoer wanneer we een versie van de TutList-applicatie uitvoeren met StrictMode ingeschakeld (alle beleidsregels, alle regels):
09-04 16: 15: 34.592: DEBUG / StrictMode (15883): schending van StrictMode-beleid; ~ duur = 319 ms: android.os.StrictMode $ StrictModeDiskWriteViolation: policy = 31 violation = 1 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.os.StrictMode $ AndroidBlockGuardPolicy.onWriteToDisk (StrictMode.java : 1041) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.database.sqlite.SQLiteStatement.acquireAndLock (SQLiteStatement.java:219) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883 ): op android.database.sqlite.SQLiteStatement.executeUpdateDelete (SQLiteStatement.java:83) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.database.sqlite.SQLiteDatabase.updateWithOnConflict (SQLiteDatabase.java: 1829) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op 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): android.content.ContentProvider $ Transport.update (ContentProvider .java: 233) 09-04 1 6: 15: 34.592: DEBUG / StrictMode (15883): op android.content.ContentResolver.update (ContentResolver.java:847) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): at com.mamlambo.tutorial .tutlist.data.TutListProvider.markItemRead (TutListProvider.java:229) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op com.mamlambo.tutorial.tutlist.TutListFragment.onListItemClick (TutListFragment.java:99) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.support.v4.app.ListFragment $ 2.onItemClick (ListFragment.java:53) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883 ): at android.widget.AdapterView.performItemClick (AdapterView.java:282) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): at android.widget.AbsListView.performItemClick (AbsListView.java:1037) 09- 04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.widget.AbsListView $ PerformClick.run (AbsListView.java:2449) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android. widget.AbsListView $ 1.run (AbsListView.java:3073) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): bij andro id.os.Handler.handleCallback (Handler.java:587) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.os.Handler.dispatchMessage (Handler.java:92) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op android.os.Looper.loop (Looper.java:132) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): android.app.ActivityThread.main (ActivityThread.java:4123) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): at java.lang.reflect.Method.invokeNative (Native Method) 09-04 16: 15: 34.592: DEBUG / StrictMode ( 15883): at java.lang.reflect.Method.invoke (Method.java:491) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): at com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run (ZygoteInit.java:841) 09-04 16: 15: 34.592: DEBUG / StrictMode (15883): op com.android.internal.os.ZygoteInit.main (ZygoteInit.java:599) 09-04 16: 15: 34.592 : DEBUG / StrictMode (15883): op dalvik.system.NativeStart.main (Native Method)
U kunt dit zelf zien door de StrictMode-code toe te voegen aan versienummer 13 van TutList. Selecteer eenvoudig een ander item uit de lijst.
Wat vertelt dit logboek ons? De handeling om een bericht simpelweg als gelezen te markeren zou uit de hoofdthread moeten zijn gedaan. In plaats daarvan is het een derde van een seconde aan het eten! Niet alleen is dat verrassend traag, het effect op de gebruikersinterface is merkbaar.
En hier is hoe het waarschuwingsvenster eruit ziet:
De meeste waarschuwingen gegenereerd door StrictMode moeten worden opgevolgd, maar niet alle gegenereerde waarschuwingen betekenen dat er iets mis is met uw code. Er zijn tal van situaties waarbij bijvoorbeeld een snel lezen vanaf schijf op de hoofddraad de toepassing niet merkbaar hindert. Of misschien heeft u een andere foutopsporingscode die de regels schendt die niet worden ingeschakeld in een productie-build.
De eerste manier om de beleidsschendingen te negeren, is door ze voor uzelf of uw team te documenteren en ze als bekende schendingen te vermelden. De tweede manier is om expliciet code toe te voegen aan het stoppen met controleren op een bepaalde regelovertreding net voordat de overtredende code wordt uitgevoerd en vervolgens detectie voor die regel opnieuw in te schakelen nadat de overtredende code is voltooid. Bijvoorbeeld:
StrictMode.ThreadPolicy old = StrictMode.getThreadPolicy (); StrictMode.setThreadPolicy (nieuwe StrictMode.ThreadPolicy.Builder (oud) .permitDiskWrites () .build ()); doCorrectStuffThatWritesToDisk (); StrictMode.setThreadPolicy (oud);
Deze code slaat het huidige beleid op, maakt een soortgelijk beleid dat de schending van schrijfbewerkingen negeert, de code uitvoert die op sommige schijven schrijft, en vervolgens het oorspronkelijke beleid herstelt.
StrictMode is een nuttige klasse in het arsenaal aan diagnostische tools die beschikbaar zijn voor Android-ontwikkelaars. Hierdoor kunnen ontwikkelaars subtiele prestatieproblemen, objectlekken en andere moeilijk te vinden runtime-problemen vinden en repareren. Gebruikt u StrictMode? Zijn er andere beleidsregels die u graag zou willen zien toegevoegd aan deze functie van de Android SDK?
Mobiele ontwikkelaars Lauren Darcey en Shane Conder hebben samen meerdere boeken geschreven over Android-ontwikkeling: een diepgaand programmeerboek getiteld Android Wireless Application Development, Second Edition en Sams Teach Yourself Android Application Development in 24 uur, tweede editie. Wanneer ze niet schrijven, besteden ze hun tijd aan het ontwikkelen van mobiele software bij hun bedrijf en het leveren van consultingservices. Ze zijn te bereiken via e-mail naar [email protected], via hun blog op androidbook.blogspot.com, en op Twitter @androidwireless.
я я 
Accentsconagua