Share
Het maakt niet uit hoe innovatief en handig uw Android-app is, als hij laggy is, vatbaar voor bevriezing of voor het geheugen van varkens, niemand zal hem willen gebruiken.
Prestaties zijn erg belangrijk, maar het is ook iets dat je gemakkelijk vergeet wanneer je bezig bent met het voltooien van je mooie gebruikersinterface of nieuwe en opwindende functies voor je app bedenkt.
Dat wil zeggen, totdat de negatieve beoordelingen van Google Play binnenkomen.
In dit artikel krijg je een spoedcursus in de algemene prestatieproblemen waar elke Android-ontwikkelaar op moet letten. Je leert hoe je kunt testen of deze problemen zich voordoen in je eigen projecten, met behulp van de tools van de Android SDK-plus één tool die al op je Android-apparaat is geïnstalleerd.
Als je een prestatieprobleem in je app ontdekt, wil je dit natuurlijk graag oplossen. Onderweg bekijken we dus ook hoe u de Android SDK-tools gebruikt om meer informatie te verzamelen over prestatieproblemen die u ontdekt. Zodra u over deze informatie beschikt, begrijpt u beter hoe u de prestaties van uw app kunt perfectioneren en uiteindelijk een app kunt maken die mensen zullen gebruiken liefde gebruik makend van.
De gebruikersinterface van uw app is uw verbinding met de gebruiker, maar het maken van iets dat er leuk uitziet, is slechts de helft van de strijd. U moet ook zorgen dat uw gebruikersinterface snel wordt weergegeven en soepel functioneert.
Een van de meest voorkomende oorzaken van een laggy, niet reagerende gebruikersinterface is overdisponeren. Overdraw is waar je de GPU-verwerkingstijd verspilt door in pixels te kleuren die alleen weer door iets anders ingekleurd worden.
Stel u bijvoorbeeld een blauwe achtergrond voor met tekst eroverheen. Android schildert niet alleen de delen van blauw die zichtbaar zijn voor de gebruiker, het schildert de hele blauwe achtergrond en tekent dan de tekst bovenaan. Dit betekent dat sommige pixels twee keer ingekleurd zijn, wat een overdraw is.
Sommige overdraw, zoals in het bovenstaande voorbeeld, is onvermijdelijk. Te veel overdraw kan echter een merkbaar effect hebben op de prestaties van uw app, dus u wilt overdraw zo veel mogelijk beperken.
Het is relatief eenvoudig om uw app te controleren op overdraw. Grote hoeveelheden overschrijdingen kunnen wijzen op een onderliggend probleem met de gebruikersinterface van uw app, zoals overbodige weergaven, daarover later meer. Om deze redenen is overdraw een verstandige plaats om te beginnen wanneer u uw app test op prestatieproblemen.
Het goede nieuws is dat je Android-apparaat al een ingebouwde functie heeft waarmee je de hoeveelheid overdraw kunt controleren ieder app op uw apparaat geïnstalleerd.
Omdat deze functie op uw apparaat leeft, is de eerste stap het installeren van de app die u wilt testen op uw Android-apparaat. Als u de hoeveelheid overdraw wilt controleren, opent u eenvoudig uw apparaat instellingen, kiezen Ontwikkelaarsopties, en tik op Debug GPU Overdraw gevolgd door Laat overdraw gebieden zien.
Deze tool gebruikt kleurblokken om de verschillende hoeveelheden overdraw te markeren. Het enige dat u hoeft te doen, is de app die u wilt testen lanceren en zien wat de situatie van overdraw is.
Nadat u een gebied met significante overdraw hebt geïdentificeerd, is de gemakkelijkste manier om deze overdraw te verminderen, de XML-bestanden van uw app te openen en te zoeken naar overlappende delen, met name drawables die niet zichtbaar zijn voor de gebruiker, en achtergronden die op elkaar worden getrokken.
Je moet ook zoeken naar gebieden waar het attribuut background is ingesteld op wit, ook al heeft een ouder al een witte achtergrond geschilderd. Al deze dingen kunnen aanzienlijke overdrawing veroorzaken.
Het Android-systeem kan eenvoudig eenvoudige gevallen van overdraw verminderen, maar het is de moeite waard op te merken dat dit zich niet uitstrekt tot complexe aangepaste weergaven waar Android geen inzicht heeft in hoe u uw inhoud tekent.
Als u complexe aangepaste weergaven in uw app gebruikt, kunt u de mogelijke grenzen voor uw weergaven definiëren met behulp van de clipRect methode. Voor meer informatie, raad ik aan de officiële Android-documentatie te bezoeken.
Een andere veel voorkomende oorzaak van prestatieproblemen is de weergavehiërarchie van uw app. Om elke weergave weer te geven, doorloopt Android drie fasen:
De tijd die Android nodig heeft om deze fasen te voltooien, is evenredig met het aantal weergaven in uw hiërarchie. Dit betekent dat een van de gemakkelijkste manieren om de weergavesnelheid van uw app te verminderen, is om weergaven te identificeren en te verwijderen die niet bijdragen aan de uiteindelijke afbeelding die de gebruiker op zijn apparaat ziet.
Zelfs als alle weergaven in uw hiërarchie nodig zijn, kan de manier waarop deze weergaven zijn geordend een aanzienlijke invloed hebben op de meetfase van het weergaveproces. Over het algemeen geldt dat hoe dieper uw weergavehiërarchie is, hoe langer het duurt om de meetfase te voltooien.
Tijdens het weergaveproces geeft elke weergave zijn dimensies aan de bovenliggende weergave. Als de bovenliggende weergave een probleem ontdekt met een van deze dimensies, kan dit elk kind dwingen opnieuw te meten.
Herzieningen kunnen zelfs optreden wanneer er is niet een foutmelding. Relatieve lay-outs bijvoorbeeld, moeten hun kinderen vaak twee keer meten om alles passend te maken. Lineaire lay-outs met kinderen die de layout_weight parameter routinematig elk kind twee keer meten.
Afhankelijk van hoe uw weergaven zijn geordend, kunnen metingen en herberekeningen een kostbaar, tijdrovend proces zijn dat een merkbare invloed heeft op de weergavesnelheid van uw app.
De sleutel om ervoor te zorgen dat uw gebruikersinterface snel en soepel verloopt, is om onnodige weergaven te verwijderen en naar mogelijkheden te zoeken om uw lay-out af te vlakken.
De Android SDK bevat een tool, Hiërarchische viewer, waarmee u uw volledige weergavehiërarchie kunt visualiseren. Met deze tool kunt u zowel overtollige weergaven herkennen en geneste lay-outs.
Voordat we de Hiërarchische viewer gereedschap, er zijn een paar eigenaardigheden waar je je bewust van moet zijn. Ten eerste kan de hiërarchieviewer alleen communiceren met een actieve app, niet de broncode van uw toepassing. Dit betekent dat je de app die je wilt testen, op je Android-apparaat moet installeren of een emulator moet gebruiken.
Er is echter nog een andere, grotere vangst. Hiërarchie Viewer kan standaard alleen communiceren met een apparaat waarop een ontwikkelingsversie van het Android-besturingssysteem wordt uitgevoerd. Als u geen ontwikkelaarstoestel heeft, kunt u deze beperking omzeilen door de ViewServer klasse voor uw toepassing.
Zodra u klaar bent om Hiërarchie Viewer te gebruiken, start u Android Studio en selecteert u Hulpmiddelen van de werkbalk, gevolgd door Android en Android-apparaatmonitor.
Klik op de Hiërarchische weergave knop aan de rechterkant zoals weergegeven in de onderstaande schermafbeelding.
Langs de linkerkant van het scherm staat een ramen tabblad met alle gedetecteerde Android-apparaten en emulators. Selecteer uw apparaat en u ziet een lijst met de processen die op dat apparaat worden uitgevoerd. Selecteer het proces dat u van dichterbij wilt bekijken en drie gebieden van de hiërarchische viewer worden automatisch bijgewerkt.
Deze drie vensters bieden drie verschillende visuele representaties van de weergavehiërarchie:
Deze drie vensters zijn gekoppeld. Als u een weergave in één venster selecteert, wordt deze in de andere twee gemarkeerd weergegeven. U kunt alle drie vensters tegelijkertijd gebruiken om overtollige weergaven op de loer te zoeken in de weergavehiërarchie.
Als u niet zeker weet of een weergave echt iets bijdraagt aan de uiteindelijke afbeelding, gaat u gewoon naar Boom zicht en klik op het knooppunt in kwestie. U ziet een voorbeeld van hoe deze weergave op het scherm wordt weergegeven, zodat u precies kunt zien wat deze weergave bijdraagt aan uw app.
Maar alleen omdat een weergave iets toevoegt aan het uiteindelijke gerenderde beeld, wil dat nog niet zeggen dat het niet bijdraagt aan een groot prestatieprobleem. U hebt al gezien hoe u de hiërarchielviewer kunt gebruiken om voor de hand liggende geneste lay-outs te herkennen, maar wat als dit nesten van prestaties niet zo duidelijk is? Of wat als iets anders ervoor zorgt dat een weergave langzaam wordt weergegeven?
Het goede nieuws is dat u ook Hiërarchie Viewer kunt gebruiken om te bepalen hoe lang het duurt voordat elke weergave door de verschillende fasen van het weergaveproces gaat. Dit geeft je een manier om problemen op te lossen die op het eerste gezicht misschien niet voor de hand liggen.
In de volgende sectie wordt uitgelegd hoe u Hiërarchie Viewer gebruikt om de verschillende weergaven in uw lay-out te profileren om eventuele renderingproblemen die zich onder de oppervlakte op de loer bevinden te herkennen.
De eenvoudigste manier om knelpunten in uw gebruikersinterface te identificeren, is door gegevens te verzamelen over hoe lang het duurt om elk van uw weergaven te voltooien om de fasen voor maat, lay-out en tekenen van het renderingproces te voltooien.
Niet alleen kunt u Hiërarchie Viewer gebruiken om deze informatie te verzamelen, Hiërarchie Viewer toont deze gegevens ook op een gemakkelijk te begrijpen, visuele manier zodat u in een oogopslag kunt zien welke weergaven niet goed presteren.
Hiërarchie Viewer geeft standaard geen weergavetijden weer. U kunt deze informatie toevoegen door naar Boom zicht en het selecteren van het hoofdknooppunt van het deel van de stamboom dat u wilt testen. Roep vervolgens de profileringsfunctie van de hiërarchie aan door op het groene, rode en paarse Venn-diagrampictogram te klikken zoals in de onderstaande schermafbeelding wordt getoond.
Drie gekleurde stippen verschijnen op elk knooppunt in dit deel van de hiërarchie. Van links naar rechts vertegenwoordigen deze stippen:
Elke punt heeft ook een toegewezen kleur:
Nadat u deze gegevens hebt verzameld, weet u niet alleen welke weergaven u moet optimaliseren, maar weet u ook precies welk deel van het renderingproces ervoor zorgt dat die weergave trager wordt weergegeven.
Houd er rekening mee dat hoewel weergave met gele en rode stippen de logische plaats is om uw optimalisatie-inspanningen te starten, deze prestatie-indicatoren relatief zijnnaar de andere geprofileerde knooppunten in de weergavehiërarchie. Met andere woorden, je krijgt altijd een aantal weergaven die langzamer worden weergegeven dan andere.
Voordat u begint met het doorzoeken van uw code naar manieren om een bepaalde weergave te optimaliseren, vraagt u zich af of deze weergave een goede reden heeft om langzamer weer te geven dan de andere geprofileerde knooppunten of dat dit echt een kans is om de renderingstijd van uw app te verminderen..
Hoewel Android een door het geheugen beheerde omgeving is, laat dit je niet in een vals gevoel van veiligheid dwingen - geheugenlekken kunnen nog steeds voorkomen. Dit komt omdat garbage collection (GC) kan enkel en alleen verwijder objecten die worden herkend als onbereikbaar. Als er geen onbereikbaar object wordt gevonden, krijgt dat object geen afval verzameld.
Deze onbereikbare objecten hangen rond, vervuilen je hoop en nemen waardevolle ruimte in beslag. Naarmate uw app objecten blijft lekken, wordt de hoeveelheid bruikbare ruimte kleiner en kleiner, wat op zijn beurt leidt tot frequentere en langere GC-gebeurtenissen.
Dit is slecht nieuws om twee redenen. Ten eerste: hoewel GC-gebeurtenissen normaal geen merkbare invloed hebben op de prestaties van uw app, kunnen veel GC-gebeurtenissen die zich in een korte tijdspanne voordoen, resulteren in een traag reagerende gebruikersinterface. Het tweede probleem is dat mobiele apparaten in het begin te kort zijn voor het geheugen, dus een geheugenlek kan snel escaleren naar een OutOfMemoryError, waardoor uw app crasht.
Geheugenlekken kunnen moeilijk te detecteren zijn. U kunt zich alleen realiseren dat geheugen een probleem is voor uw app wanneer uw gebruikers beginnen te klagen. Gelukkig heeft de Android SDK een aantal handige tools die je kunt gebruiken om je app te doorzoeken op die soms subtiele tekenen van geheugenlekken.
Geheugenmonitor is een eenvoudige manier om een overzicht te krijgen van het geheugengebruik van uw app in de loop van de tijd. Houd er rekening mee dat dit hulpprogramma alleen verbinding kan maken met een actieve app, dus zorg ervoor dat de app die u wilt testen, is geïnstalleerd op uw Android-apparaat en dat uw apparaat is aangesloten op uw computer.
Deze tool is ingebouwd in Android Studio, dus u hebt toegang tot deze tool door op de knop te klikken Geheugen tab naar de onderkant van je IDE. Zodra Memory Monitor uw actieve toepassing detecteert, begint het geheugengebruik van uw app te registreren.
Als Memory Monitor de opname niet start, controleer dan of uw apparaat is geselecteerd in het vervolgkeuzemenu Apparaten.
Als Memory Monitor terugkeert a Geen debuggable applicaties bericht, open Android Studio's Hulpmiddelen menu, selecteer Android, en zorg ervoor Schakel adb-integratie in is geselecteerd. Deze functie kan nogal temperamentvol zijn, dus u moet mogelijk wisselen Schakel adb-integratie in aan en uit een paar keer. Het kan ook helpen om je Android-apparaat te verwijderen en vervolgens opnieuw verbinden.
Zodra Memory Monitor uw actieve toepassing heeft gedetecteerd, geeft deze de hoeveelheid geheugen weer die uw app gebruikt in donkerblauw en het niet-toegewezen geheugen in lichtblauw.
Besteed enige tijd aan interactie met uw apparaat terwijl u in de gaten houdt hoe het geheugengebruik van uw app verandert in Memory Monitor. Uiteindelijk zal het toegewezen geheugen groeien totdat er geen vrij geheugen meer over is. Op dit punt zal het systeem geheugen vrijmaken door een GC-gebeurtenis te activeren. Telkens wanneer u een significante daling in het toegewezen geheugen ziet, is dit een teken dat er zich een GC-gebeurtenis heeft voorgedaan.
GC-evenementen zijn volkomen normaal, maar maak je geen zorgen als je ziet dat je app veel geheugen toewijst in een korte periode of als GC-evenementen frequenter worden. Dit zijn beide veelbetekenende signalen dat er een geheugenlek optreedt in uw app.
Als u Memory Monitor gebruikt om een vermoedelijk geheugenlek gedurende een lange periode op te sporen, ziet u mogelijk dat het Android-systeem compenseert voor de groeiende geheugenbehoeften van uw app door uw app een hoger geheugenplafond te geven, waarna de cyclus opnieuw begint.
Uiteindelijk kunt u zelfs zien dat uw app zoveel geheugen verbruikt dat het systeem niet langer meer geheugen beschikbaar kan maken voor uw app. Als je dit ziet gebeuren, is er iets ernstig mis met de manier waarop je app geheugen gebruikt.
Een andere tool die u kan helpen meer informatie te verzamelen over geheugenlekken en andere geheugengerelateerde problemen is de Android-apparaatmonitor Hoop tab.
De Hoop Met het tabblad kunt u geheugenlekken diagnosticeren door te laten zien hoeveel geheugen het systeem uw app heeft toegewezen. Zoals reeds vermeld, is het geheugen sterk toegenomen als het toegewezen geheugen blijft toenemen. Dit is een sterke indicatie dat uw app een geheugenlek heeft.
Maar deze tool biedt ook veel gegevens over het gebruik van de heap van uw app, inclusief het soort objecten dat uw app toewijst, het aantal toegewezen objecten en hoeveel ruimte deze objecten in beslag nemen. Deze extra informatie kan van onschatbare waarde zijn als u de bron van geheugenlekken en andere geheugengerelateerde problemen in uw app opzoekt.
Om toegang te krijgen tot deze tool, start u Android-apparaatmonitor en selecteert u de DDMS tab. In de apparaten paneel, selecteer uw apparaat en het proces dat u wilt onderzoeken. Selecteer vervolgens de Hoop tabblad, zoals weergegeven in de onderstaande schermafbeelding, en besteed enige tijd aan interactie met uw app.
De heap-uitvoer wordt alleen weergegeven na een GC-gebeurtenis, dus als u dit tabblad wilt vullen met gegevens, moet u wachten totdat een GC-gebeurtenis van nature plaatsvindt, of u kunt een GC forceren door op de knop te klikken. Oorzaak GC knop.
Nadat een GC-gebeurtenis heeft plaatsgevonden, is de Hoop tabblad wordt bijgewerkt met veel informatie over het gebruik van de heap van je app. Deze gegevens worden na elke GC-gebeurtenis vernieuwd.
In deze zelfstudie hebben we enkele van de meest voorkomende prestatieproblemen besproken waarvan u op de hoogte moet zijn bij het ontwikkelen van Android-apps, overdraw, geheugenlekken en trage weergave van gebruikersinterfaces.
Je hebt ook grip op een aantal tools die je kunt gebruiken om te controleren of deze problemen zich voordoen in je eigen Android-projecten en hebt gezien hoe je meer informatie kunt verzamelen over de prestatieproblemen die zich voordoen in je eigen apps. Hoe meer informatie u heeft, hoe groter de kans dat u de oorzaak van het probleem opspoort en verhelpt.
De Android SDK heeft nog veel meer tools waarmee u prestatieproblemen kunt opsporen en verhelpen. Als je meer wilt weten, bevatten de officiële Android-documentatiepagina's over Traceview en dmtracedump en Allocation Tracker meer informatie.
Accentsconagua