Ik ben nieuw in de Android SDK/API-omgeving. Het is de eerste die ik probeer om een plot/grafiek te tekenen. Ik heb geprobeerd verschillende soorten voorbeeldcodes op de emulator uit te voeren met behulp van 3 verschillende gratis bibliotheken, er wordt niets weergegeven op het lay-outscherm. De logcat herhaalt het volgende bericht:
W/Trace(1378): onverwachte waarde van nativeGetEnabledTags: 0 I/Choreograaf(1378): 55 frames overgeslagen! De toepassing doet mogelijk te veel werk aan de hoofdthread.
Het probleem bleef niet bestaan en de grafiek werkte toen ik een voorbeeldcode uitvoerde die betrekking had op een evaluatiekopie van een gelicentieerde bibliotheek.
Antwoord 1, autoriteit 100%
overgenomen van: Android-gebruikersinterface: overgeslagen frames herstellen
Iedereen die begint met het ontwikkelen van een Android-applicatie, ziet dit bericht op
logcat “Choreograaf(abc): xx frames overgeslagen! De toepassing kan zijn:
te veel werk aan zijn hoofdthema.”Dus wat doet het eigenlijk?
betekent, waarom zou u zich zorgen maken en hoe dit op te lossen.
Dit betekent dat het lang duurt om je code te verwerken en te framen
worden daardoor overgeslagen, misschien vanwege een of andere zware
verwerking die u aan het doen bent in het hart van uw aanvraag of DB
toegang of iets anders waardoor de thread een tijdje stopt.
Hier is een meer gedetailleerde uitleg:
Choreograaf laat apps zichzelf verbinden met de vsync, en
dingen goed timen om de prestaties te verbeteren.Android-weergave-animaties gebruiken intern Choreographer voor hetzelfde
doel: de animaties goed timen en eventueel verbeteren
prestaties.Aangezien Choreograaf wordt verteld over elke vsync-gebeurtenis, kan ik zien of
een van de Runnables doorgegeven door de Choreographer.post* apis
eindigt niet in één frame, waardoor frames worden overgeslagen.Naar mijn idee kan de choreograaf alleen het overslaan van het frame detecteren.
Het kan niet zeggen waarom dit gebeurt.Het bericht “De toepassing doet mogelijk te veel werk op het hoofdgedeelte
draad.” kan misleidend zijn.Waarom u zich zorgen zou moeten maken
Wanneer dit bericht verschijnt op Android
emulator en het aantal overgeslagen frames is dan vrij klein (<100)
je kunt er zeker van zijn dat de emulator traag is – wat gebeurt
bijna altijd. Maar als het aantal frames is overgeslagen en groot is
en in de orde van 300+ dan kunnen er serieuze problemen zijn met
jouw code. Android-apparaten komen in een breed scala aan hardware in tegenstelling tot ios
en Windows-apparaten. Het RAM en CPU varieert en als je een
redelijke prestaties en gebruikerservaring op alle apparaten dan jij
moet dit ding repareren. Wanneer frames worden overgeslagen, is de gebruikersinterface traag en
laggy, wat geen gewenste gebruikerservaring is.Hoe dit op te lossen
Om dit op te lossen, moeten knooppunten worden geïdentificeerd waar of
mogelijk kan gebeuren lange duur van de verwerking. De beste manier is om te doen
alle verwerking, hoe klein of groot ook, in een aparte draad
van de hoofd UI-thread. Dus of het nu gaat om toegang tot gegevens uit SQLite Database of
wat hardcore wiskunde doen of gewoon een array sorteren – Doe het in a
ander draadjeNu is er een addertje onder het gras, je maakt een nieuwe thread om te doen
deze bewerkingen en wanneer u uw toepassing uitvoert, zal deze crashen
zeggende “Alleen de originele thread die een weergavehiërarchie heeft gemaakt, kan”
zijn standpunten raken“. U moet dit feit weten dat de gebruikersinterface in Android kan zijn
gewijzigd door de hoofdthread of alleen de UI-thread. Elke andere thread
die dit probeert te doen, mislukt en crasht met deze fout. Wat jij
wat u hoeft te doen, is een nieuwe Runnable maken binnen runOnUiThread en inside
dit uitvoerbaar is, moet u alle bewerkingen uitvoeren met betrekking tot de gebruikersinterface. Vind
een voorbeeld hier.Dus we hebben Thread en Runnable voor het verwerken van gegevens uit de hoofdthread,
wat nog meer? Er is AsyncTask in Android waarmee je lang kunt doen
processen op de UI-thread. Dit is het handigst wanneer u
applicaties zijn data-gedreven of web-api-gedreven of gebruiken complexe UI’s
zoals die bouwen met Canvas. De kracht van AsyncTask is dat
maakt het mogelijk om dingen op de achtergrond te doen en als je klaar bent met het doen van de
verwerking, kunt u eenvoudig de vereiste acties op de gebruikersinterface uitvoeren zonder
waardoor een achterblijvend effect ontstaat. Dit is mogelijk omdat de AsyncTask
ontleent zichzelf aan de UI-thread van Activity – alle bewerkingen die u doet
op de gebruikersinterface via AsyncTask worden gedaan, is een andere thread dan de hoofdgebruikersinterface
thread, Geen belemmering voor gebruikersinteractie.Dus dit is wat je moet weten om een soepele Android te maken
applicaties en voor zover ik weet krijgt elke beginner dit bericht op zijn
console.
Antwoord 2, autoriteit 52%
Zoals anderen hierboven antwoordden: “55 frames overgeslagen!” betekent dat er een zware verwerking in uw aanvraag zit.
Voor mijn geval is er geen zwaar proces in mijn aanvraag. Ik heb alles dubbel en driedubbel gecontroleerd en dat proces verwijderd waarvan ik denk dat het een beetje zwaar was.
Ik heb fragmenten, activiteiten, bibliotheken verwijderd totdat alleen het skelet is over. Maar toch ging het probleem niet weg. Ik besloot om de bronnen te controleren en een aantal pictogrammen en achtergrond te vinden die ik gebruik zijn, zijn behoorlijk groot als ik vergat om de grootte van die bronnen te controleren.
Dus, mijn suggestie is als geen van de bovenstaande antwoorden helpt, kunt u ook de grootte van uw bronbestanden controleren.
3, Autoriteit 13%
Ik had ook hetzelfde probleem.
De mijne was een zaak waarin ik een achtergrondafbeelding gebruikte die in twijfel lag. Dat bijzondere afbeelding was van ca. 130kb en werd gebruikt tijdens het Splash-scherm en de startpagina in mijn Android-app.
Oplossing – Ik heb zojuist die specifieke afbeelding verschoven naar Tekenonderbrekingen-XXX-map van Tekens en was mogelijk vrij veel geheugen bezet op de achtergrond en het overslaan van frames springen niet langer.
Update Gebruik ‘NODP’ Trekbare resource map voor het opslaan van achtergrond Trajectables
bestanden.
zal een dichtheid gekwalificeerde opleiding map of tekenbare nodpi Heb je voorrang?
4, Autoriteit 4%
Nog een veelvoorkomende oorzaak van vertragingen op de UI-draad is de toegang van SharePreferences. Wanneer u een PreferenceManager.getSharedPreferencesen andere vergelijkbare methoden voor de eerste keer belt, wordt het bijbehorende .xml-bestand onmiddellijk geladen en geparseerd in dezelfde thread .
Een van goede manieren om dit probleem te bestrijden, is het veroorzaken van eerste sharedpreference-belasting van de achtergronddraad, gestart zo vroeg mogelijk (bijvoorbeeld van onCreatevan uw toepassingsklasse). Op deze manier kan het voorkeurobject al zijn geconstrueerd door de tijd die u het wilt gebruiken.
Helaas is het lezen van een voorkeursbestanden soms nodig tijdens vroege fasen van opstarten (bijvoorbeeld in de eerste activiteit of zelfs toepassing zelf). In dergelijke gevallen is het nog steeds mogelijk om te voorkomen dat u de UI vastgeeft met behulp van MessageQueue.IdleHandler. Doe al het andere dat u moet uitvoeren op de hoofddraad en installeer vervolgens de idlehandler om code uit te voeren zodra uw activiteit volledig is getekend. In die fruit moet u toegang hebben tot SharedPreferences zonder te veel tekenbewerkingen te vertragen en ongelukkig te verdienen.
5, Autoriteit 3%
Probeer de volgende strategieën te gebruiken om uw app-prestaties te verbeteren:
- Gebruik indien mogelijk multi-threading programmering. De prestatievoordelen zijn enorm, zelfs als uw slimme telefoon één kern heeft (threads kunnen in verschillende kernen lopen, als de processor twee of meer heeft). Het is handig om uw app-logica van de UI gescheiden te maken. Gebruik Java-threads, Assynctask of Intertservice. Controleer dit .
- Lees en volg de Misc-prestatietips van Android-ontwikkelingswebsite. controleer hier .
6, Autoriteit 3%
Ik had hetzelfde probleem. Android-emulator werkte perfect op Android & LT; 6.0. Toen ik emulator nexus 5 (Android 6.0) gebruikte, werkte de app erg traag met I/Choreographer: Skipped framesin de logs.
Dus, ik heb dit probleem opgelost door in het manifestbestand te veranderen hardwareAcceleratedOptie naar trueals volgt:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapplication">
<application android:hardwareAccelerated="true">
...
</application>
</manifest>
7, Autoriteit 2%
Ik ben geen expert, maar ik heb dit foutopsporingsbericht toen ik gegevens van mijn Android-applicatie naar een webserver wilde verzenden. Hoewel ik ASynctask-klasse heb gebruikt en de gegevensoverdracht op de achtergrond heeft gedaan, voor het verkrijgen van de resultaatgegevens terug van de server die ik heb gebruikt () methode van de Asynctask-klasse die het UI-synchroon maakt, wat betekent dat je UI te lang zal wachten. Dus mijn advies is om uw app elke netwerkgerichte taken op een afzonderlijke draad te laten doen.
8
Optimaliseer uw afbeeldingen … Gebruik geen afbeeldingen die groter zijn dan 100 kb … Beeld laden kost te veel CPU en zorg ervoor dat uw app hangt.
9
Ik had hetzelfde probleem. In mijn geval had ik 2 geneste relatieve lay-outs. Relativelayout hoeft altijd twee maatregelen te doen. Als u relativelayouts nestelt, krijgt u een exponentieel meetalgoritme.
10
Ik had hetzelfde probleem. Toen ik de code op een andere computer uitvoerde, werkte het prima. Op de mijne werd echter weergegeven: “De toepassing doet mogelijk te veel werk aan de hoofdthread”.
Ik heb mijn probleem opgelost door Android studio opnieuw op te starten [File -> Ongeldige caches / Herstart -> klik op “Ongeldig maken en opnieuw opstarten”].
Antwoord 11
In mijn geval was dat omdat ik per ongeluk een onderbrekingspunt op een methode had ingesteld. Nadat ik het had gewist, verdween de melding en verbeterden de prestaties aanzienlijk.
Antwoord 12
Mijn app had hetzelfde probleem. Maar het deed niet anders dan een lijst met kaarten en tekst erop weergeven. Niets draait op de achtergrond. Maar na enig onderzoek bleek dat de afbeelding voor kaartachtergrond dit veroorzaakte, hoewel het klein was (350 kb). Vervolgens heb ik de afbeelding geconverteerd naar 9patch-afbeeldingen met behulp van
http://romannurik.github.io/AndroidAssetStudio/index.html.
Dit werkte voor mij.
Antwoord 13
Ik kreeg hetzelfde probleem tijdens het ontwikkelen van een app die veel tekenbare png-bestanden gebruikt in de rasterlay-out. Ik heb ook geprobeerd mijn code zo ver mogelijk te optimaliseren.. maar het werkte niet voor mij.. Toen probeerde ik de grootte van die png te verkleinen.. en ik denk dat het absoluut goed werkt.. Dus mijn suggestie is om het te verkleinen grootte van beschikbare middelen, indien van toepassing..
Antwoord 14
Na veel R&D over dit probleem te hebben gedaan, kreeg ik de oplossing,
In mijn geval gebruik ik een service die elke 2 seconden wordt uitgevoerd en met de runonUIThread vroeg ik me af of het probleem er was, maar helemaal niet.
Het volgende probleem dat ik ontdekte, is dat ik een grote afbeelding in de app van mei gebruik en dat is het probleem.
Ik heb de afbeeldingen verwijderd en nieuwe afbeeldingen ingesteld.
Conclusie:- Kijk in je code of er een onbewerkt bestand is dat je gebruikt van grote omvang.
Antwoord 15
Lees eerst de waarschuwing. Er staat meer belasting op de hoofdthread. Dus wat u hoeft te doen, is gewoon functies uitvoeren met meer werk in een thread.
Antwoord 16
Zoals ik eerst deed gebruik bij voorkeur SVG-afbeeldingen in plaats van alle andere typen, comprimeer indien niet mogelijk al uw PNG– en JPG-bronnen met sommige beeldverwerkingstools zoals Adobe Photoshopof Fotosizer. een van de gemakkelijkste manieren zijn online hulpmiddelen voor het comprimeren van afbeeldingen, zoals dit, waarmee ik al mijn afbeeldingsbestanden tot bijna 50% heb teruggebracht van hun oorspronkelijke grootte.
Antwoord 17
Ik heb het nog niet opgelost, maar zal het doen. Voor mijn kleine project met één configureerbare functie (knop) en logica om te controleren of “com.whatsapp” -pakketten op het apparaat (emulator) bestaan, heb ik het volgende in hetzelfde logboek terwijl ik simulator start:
I/Choreographer: Skipped 34 frames! The application may be doing too much work on its main thread.
Antwoord 18
Dit is normaal als u async/wait-functionaliteiten in uw applicatie gebruikt.