Share
Testing er en viktig del av Android-utviklingen, slik at du kan stryke ut alle feilene, feilene og ytelsesproblemer som kan lure deg i appen din, før du slipper det ut på allmennheten.
Hver gang du støter på en feil, genererer Android en feilmelding, og deretter vises den meldingen som en del av Android Studio Logcat Monitor eller som en dialog på enheten du bruker til å teste appen din.
Disse feilmeldingene er vanligvis korte og til poenget, og ved første øyekast kan det ikke virke som det er nyttig. Men disse meldingene inneholder faktisk all den informasjonen du trenger for å få prosjektet tilbake på sporet. Du trenger bare å vite hvordan du kan dechifrere dem!
I denne artikkelen skal vi ta en grundig titt på de 13 feilmeldingene du mest sannsynlig støter på når du utvikler noen Android app. Vi vil undersøke hva hver av disse feilmeldingene egentlig betyr å undersøke alle mulige årsaker til at du kanskje støter på hver feil, og viktigst av alt, deling av trinnvise instruksjoner om hvordan du kan løse dem.
Det er et bredt spekter av feilmeldinger du kan støte på når du tester appen din, alt fra alvorlige feil som vil føre til at appen din krasjer første gang du prøver å installere den på en målenhet til mer subtile feil som forringer programmets ytelse over tid.
Avhengig av hvilken type feil du opplever, vil Android vise feilmeldingen enten på enheten du bruker for å teste appen din eller i Android Studio.
Spotting feilmeldinger som vises på en fysisk enhet eller AVD er enkelt - du trenger bare å være oppmerksom på eventuelle dialoger som vises på enhetens skjerm! Spottingsfeil som vises i Android Studio kan imidlertid være vanskelig, da Logcat Monitor registrerer en stor mengde informasjon, noe som gjør det enkelt å gå glipp av viktige feilmeldinger..
Den enkleste måten å forsikre deg om at du ikke går glipp av feilmeldinger, er å åpne Logcat Monitor utførlig dropdown og sett den til Feil, som vil filtrere ut alt unntatt feilmeldinger.
Denne feilen oppstår når Android Studio ikke kan generere din R.java fil riktig, og det kan ofte kaste seg opp fra ingenting - ett minutt vil alt fungere bra, og neste minutt vil hver del av prosjektet ikke kompilere. For å gjøre saken verre, når Android Studio møter R.layout Feil, det vil vanligvis flagge alle layout ressursfilene som inneholder feil, noe som gjør det vanskelig å vite hvor du skal begynne å lete etter feilkilden.
Ofte er den mest effektive løsningen det enkleste: Rengjør og gjenoppbygg prosjektet ditt. Å velge Bygg> Ren prosjekt vent på noen få minutter fra Android Studio-verktøylinjen, og bygg prosjektet ditt ved å velge Bygg> gjenoppbygg prosjektet.
Hvis en enkelt ren / rebuild-syklus ikke virker, prøv å gjenta denne prosessen et par ganger, ettersom noen utviklere har rapportert positive resultater etter å ha fullført flere rene / gjenoppbygge sykluser i rask rekkefølge.
Hvis du støter på denne feilen etter at du har flyttet noen filer og kataloger rundt, er det mulig at R.layout Feil blir forårsaket av feil samsvar mellom Android Studio cache og prosjektets nåværende layout. Hvis du mistenker at dette kan være tilfelle, velg deretter Fil> Ugyldig Caches / Restart> Invalidize and Restart fra Android Studios verktøylinje.
Problemer med navnene på ressursene dine kan også forhindre R.java filen blir opprettet riktig, så sjekk at du ikke har flere ressurser med samme navn og at ingen av filnavnene inneholder ugyldige tegn. Android Studio støtter bare små bokstaver a-z, 0-9, fullstopp og understreker, og et enkelt ugyldig tegn kan forårsake en R.layout feil over hele prosjektet ditt, selv om du ikke egentlig bruk denne ressursen hvor som helst i prosjektet ditt!
Hvis du identifiserer og løser en feil, vises Android Studio fortsatt R.layout feil, må du kanskje fullføre en ren / gjenoppbyggings syklus før Android Studio registrerer dine endringer på riktig måte.
Når du kompilerer appen din, inneholder APK kjørbare bytecode-filer i form av bytekstfiler av Dalvik Executable (DEX). DEX-spesifikasjonen angir at en enkelt DEX-fil kan referere maksimalt 65.536 metoder, og hvis du støter på For mange felt ... feil da betyr det at appen din har gått over denne grensen. Merk at dette er en begrensning på antall metoder prosjektet ditt referanser, og ikke antall metoder prosjektet ditt definerer.
Hvis du støter på denne feilen, kan du enten:
Prosessen med å aktivere multidex-støtte vil variere avhengig av versjoner av Android som støttes av prosjektet.
Hvis du målretter mot Android 5.0 eller høyere, åpner du det første trinnet på modulnivå build.gradle-filen og innstillingen multiDexEnabled til ekte:
android defaultConfig minSdkVersion 21 multiDexEnabled true
Men hvis din minSdkVersion er 20 eller lavere, må du legge til multiDexEnabled true Tilordne og legg deretter til multidex-støttebiblioteket som en prosjektavhengighet:
avhengigheter compile 'com.android.support:multidex:1.0.1'
Det neste trinnet avhenger av om du overstyrer eller ikke applikasjon klasse.
Hvis prosjektet ditt tilsidesetter applikasjon klasse, åpne deretter manifestet ditt og legg til følgende i
...
Hvis prosjektet ditt ikke tilsidesætter applikasjon klasse, så må du utvide MultiDexApplication i stedet:
offentlig klasse MyApplication utvider MultiDexApplication
Til slutt, hvis du overstyrer applikasjon klassen, men kan ikke endre grunnklassen, så kan du aktivere multidex ved å overstyre attachBaseContext () metode og samtale MultiDex.install (denne), for eksempel:
@Override protected void attachBaseContext (Kontekstbase) super.attachBaseContext (base); MultiDex.install (this);
Hvis du får en JDK-feil når du prøver å bygge appen din, betyr det at Android Studio sliter med å finne hvor JDK er installert på utviklingsmaskinen din.
For å fikse denne feilen:
Hvis dette ikke løser problemet, kan du navigere tilbake til Fil> Prosjektstruktur ...> SDK-plassering, og skriv inn den fullstendige filbanen manuelt for JDK. Hvis du ikke er sikker på hvor JDK er installert på utviklingsmaskinen din, kan du finne ut ved å åpne Terminal (Mac) eller Command Prompt (Windows) og skrive inn følgende kommando:
/ Usr / libexec / JAVA_HOME
Mens AVD-er er gode for testing av appen din på tvers av et bredt spekter av annen maskinvare og programvare, bør du alltid teste appen din på minst en fysisk Android-smarttelefon eller nettbrett. Imidlertid er Android Studio's evne til å gjenkjenne en tilkoblet Android-enhet berømt og savnet.
Hvis du har koblet enheten til utviklingsmaskinen din, men støter på en Feil ved installering av APK melding når du prøver å installere APK, eller enheten din vises ikke engang i Velg Distribusjonsmål vindu, prøv deretter følgende rettelser:
Åpne enheten din innstillinger, velg deretter Utviklermuligheter, og sørg for USB-feilsøking Er på. Hvis du ikke ser Utviklermuligheter i innstillinger menyen, og velg deretter Om telefonen og fortsett å tappe Bygg nummer inntil a Du er nå en utvikler varsel vises. Gå tilbake til hovedmenyen innstillinger skjermen, og du bør finne det Utviklermuligheter har blitt lagt til.
Noen ganger kan enheten kreve ekstra tilleggsinngang før den kobles til utviklingsmaskinen din. For eksempel kan det be deg om å velge mellom forskjellige moduser, eller for å eksplisitt godkjenne tilkoblingen.
Hvis du utvikler deg på Windows, må du laste ned den riktige OEM USB-driveren for enheten din. Hvis du er en Nexus-bruker, kan du laste ned Google USB driver gjennom Android Studio SDK Manager.
Du finner prosjektets minimum SDK i gradle.build-modulen på modulnivå, og kan se hvilken versjon av Android som er installert på enheten ved å åpne dens innstillinger og swiping til Om telefonen seksjon.
Åpne et Terminal eller Command Prompt-vindu, og endre deretter katalogen (cd), så det peker på din plattform-verktøy vindu, for eksempel:
cd / brukere / nedlastinger / adt-bundle-mac / sdk / platform-verktøy
Deretter avslutter og starter om adb-prosessen ved å skrive inn følgende kommandoer, den ene etter den andre:
./ adb kill-server
./ adb start-server
Hvis alt annet feiler, kan du prøve å koble fra og deretter koble til enheten, starte enheten på nytt, starte Android Studio på nytt og, som en absolutt siste utvei, starte maskinen på nytt..
Hvis du støter på denne feilen når du prøver å installere prosjektet, betyr det at målenheten ikke har nok minne.
Hvis du prøver å installere prosjektet ditt på en AVD, bør du sjekke hvor mye plass du har tildelt denne bestemte AVD:
Denne delen viser de forskjellige typer minne du har tildelt til denne bestemte AVD. Hvis noen av disse verdiene er uvanlig lave, bør du øke dem for å gjenspeile minnet som er tilgjengelig for din typiske Android-smarttelefon eller nettbrett:
Hvis det ikke er noe rart om AVDs minne, eller du prøver å installere appen din på en fysisk Android-smarttelefon eller nettbrett, betyr denne feilen vanligvis at din kompilerte app bare er for stor. En applikasjon som tar en betydelig bite ut av enhetens minne ved installasjonstid, kommer aldri til å gå bra.
Hvis du trenger å redusere størrelsen på APK din dramatisk, kan du prøve følgende teknikker:
Bruk ProGuard til å fjerne ubrukte klasser, felt, metoder og attributter. For å aktivere ProGuard, åpne modulen build.gradle filen på modulnivå og legg til følgende:
Accentsconagua
buildTypes release // Aktiver ProGuard // minifyEnabled true // Siden vi vil redusere vår APK-størrelse så mye som mulig, bruker jeg innstillingene fra proguard-android-optimize.txt filen // proguardFiles getDefaultProguardFile ('proguard -android-optimize.txt '),' proguard-rules.pro 'shrinkResources true til prosjektets build.gradle-fil.android: tint og tintMode, og du kan rotere et bilde ved hjelp av android: fromDegrees, android: toDegrees, android: pivotX, og android: pivotY.Optimaliser biblioteker. Prøv å fjerne eventuelle unødvendige eller minneintensive biblioteker fra prosjektet ditt. Hvis du trenger å bruke et stort bibliotek, kontroller du om det er noen måte du kan optimalisere dette biblioteket for mobilmiljøet, da ekstern bibliotekskode ofte ikke er skrevet med mobil i tankene. Du bør også huske på at mange biblioteker inneholder en stor mengde lokaliserte strenger. Hvis appen din ikke støtter disse bibliotekene offisielt, kan du kanskje redusere størrelsen på biblioteket ved å fortelle Gradle om ikke å inkludere disse strengene i kompilert APK. Hvis du vil spesifisere språkene som appen din støtter offisielt, åpner du modulen build.gradle-filen på modulnivå og bruker resConfigs Egenskap. Her spesifiserer vi for eksempel at vi bare vil ta med engelskspråklige strenger i prosjektet vårt:
android defaultConfig resConfigs "no"
Vurder om APK inneholder en stor mengde innhold som den enkelte brukeren kan laste ned, men aldri bruke. For eksempel har en enhet med en HDD-skjerm ikke mye bruk for xxxhdpi eiendeler! En av de mest effektive måtene å redusere størrelsen på APK er å skille den i flere APKer, så når brukeren laster ned appen din, mottar de en APK som bare inneholder koden og ressursene som gir mening for den aktuelle enheten. Du finner mer informasjon om å opprette APKer som målretter mot forskjellige skjermdensiteter og bestemte ABIer (applikasjons binære grensesnitt) over på de offisielle Android-dokumentene.
en ActivityNotFoundException oppstår når en samtale til startActivity (Intent) eller en av dens varianter svikter fordi Aktivitet kan ikke utføre oppgaven Intent.
Den vanligste årsaken til en ActivityNotFoundException glemmer å erklære en aktivitet i manifestet ditt, så åpne manifestet ditt og kontroller at du har erklært alle dine aktiviteter. Du bør også kontrollere at du har erklært hver aktivitet riktig, bruker enten et fullt kvalifisert klassenavn eller en fullstopp som en kortskrift for pakkenavnet. For eksempel er begge følgende gyldige:
Hvis du ikke kan se noen problemer med manifestet ditt, er det noen andre mulige årsaker til ActivityNotFoundExceptions. For det første, hvis du støter på denne feilen etter at du har flyttet en Aktivitet klassen fra en pakke til en annen, så er det mulig at du har forvirret Android Studio og bare trenger å rengjøre og gjenoppbygge prosjektet ditt.
en ActivityNotFoundException kan også oppstå hvis en feil i målet Aktivitet lastes ikke inn riktig. For å sjekke om dette skjer i prosjektet, sett inn hensiktskoden i en prøvefeltboks:
prøv // Din kode her // fangst (ActivityNotFoundException e) e.printStackTrace ();
Kjør programmet på nytt, og ta en titt på Android Studio's Logcat Monitor for å se om det er tatt noen unntak som kan hindre at målaktiviteten blir opprettet. Hvis dette er tilfelle, bør løsningen av disse feilene løses ActivityNotFoundException, også.
De ClassCastException Feil er relatert til Javas type konvertering funksjon, som lar deg kaste variabler av en type til en annen. Du møter en ClassCastException når du prøver å kaste et objekt til en klasse som det ikke er en forekomst. For eksempel vil begge følgende kodestykker resultere i en ClassCastException:
Objekt x = nytt heltal (0); System.out.println ((String) x);
ImageView image = (ImageView) context.findViewById (R.id.button);
Denne feilmeldingen inneholder informasjon om linjen som forårsaker ClassCastException feil, så naviger til denne delen av prosjektet, sjekk hvilke objekter som blir kastet der, og løse eventuelle feilmatcher.
Hvis du ikke kan oppdage et problem med avstøpningen din, må du vurdere om du nylig har flyttet noen Visninger rundt i layout ressursfiler, som noen brukere har rapportert støter på a ClassCastException etter omarrangering av deres Visninger. Hvis du mistenker at dette kan være årsaken til din ClassCastException, Fortell deretter Android Studio å regenerere layoutfilene dine fra bunnen av, ved å utføre en ren / gjenoppbyggings-syklus. Dette tvinger Android Studio til riktig å registrere de siste layoutendringene, som skal løse din ClassCastException.
I Java, når du erklære en referansevariabel, lager du faktisk en peker til et objekt. Du kan erklære at et objekt peker på et ukjent data ved å tildele en nullverdi til objektets referanse. Nullverdier kan være nyttige ved koding av noen designmønstre, men hvis du støter på en NullPointerException (NPE), betyr det at du har forsøkt å bruke en referanse som peker på null-verdi, som om det refererte til et objekt. Siden det ikke er noen kode som skal utføres på stedet der denne referansen peker, slutter du med en NPE.
En NPE følger vanligvis med informasjon om hvor dette unntaket ble fanget, så Logcat Monitor skal inneholde den nøyaktige linjen der denne feilen oppstod. Naviger til dette området av prosjektet ditt og identifiser referansen som tilsvarer null. Du må da finne plasseringen der verdien skal settes og sette den.
De findViewById Metoden kan også returnere null hvis den forespurte Utsikt kan ikke bli funnet, så hvis din NPE forekommer i en linje som inneholder a findViewById, Kontroller at du har initialisert oppsettet som inneholder dette Utsikt. Vær også på utkikk etter stavefeil eller skrivefeil som kan ha skjedd inn i din findViewById ring, da disse også kan resultere i en NPE.
For å unngå NPE som forekommer i prosjektet, må du kontrollere at alle objektene dine initialiseres før du prøver å bruke dem, og kontroller alltid at en variabel ikke er null før du ber om en metode eller et felt fra objektet.
Dette er en feil som vises som en dialog på Android-enheten eller AVD du bruker til å teste appen din. De Søknad som ikke svarer (ANR) -feil oppstår når appens brukergrensesnitt fryser og forblir uresponsivt til brukerinngang i mer enn fem sekunder. Dette skjer vanligvis fordi appen din prøver å utføre lange eller intensive operasjoner på Android-hovedbruddstråden.
I Android er hovedbruddstråden ansvarlig for å sende alle brukerinngangshendelser til de aktuelle brukergrensesnittene, og for å oppdatere appens brukergrensesnitt. Denne tråden kan imidlertid bare behandle en oppgave om gangen, så hvis du blokkerer hovedtråden med langvarig eller intensiv operasjon, vil brukergrensesnittet ditt helt uten å svare til denne oppgaven er fullført.
Hvis du støter på en ANR-melding mens du tester appen din, så helt sikkert trenger å se på arbeidet du utfører på hovedtråden. Men hvis du ikke eksplisitt støter på denne feilen, men legger merke til at appen din noen ganger føles trist eller laggy, er dette en indikasjon på at du er på randen av en ANR-feil, og igjen bør du ta en titt på staten av brukergrensesnittet ditt.
Å løse ANR-feil (og nær-ANR-feil), må du identifisere alle operasjoner som har potensial til å kjøre sakte, eller som krever betydelig prosessorkraft, og deretter flytte dem av hovedtråden. Dette gjør du ved å lage en arbeidstråd hvor disse operasjonene kan utføres med null risiko for å blokkere hovedbruddstråden.
Det finnes flere metoder for å lage flere tråder, men den enkleste løsningen er å bruke en AsynTask, da denne klassen allerede inneholder sin egen arbeidstråd og en onPostExecute () tilbakeringing som du kan bruke til å kommunisere med Android's hovedbruker-tråd.
Imidlertid er AsyncTasks bedre egnet til å utføre kort bakgrunnsoperasjoner, så hvis du trenger å utføre en langvarig operasjon, bør du bruke en Service eller en IntentService i stedet.
Selv om flytting av langvarige og intensive oppgaver ut av hovedtråden, har størst innvirkning på appens ytelse, er det best å utføre så lite arbeid som mulig på hovedbruddstråden. Selv om du kjører en liten mengde unødvendig kode på hovedtråden, kan det få innvirkning på appens responsivitet, så når du har flyttet alle dine langvarige og intensive operasjoner, bør du se på om det er noe mer kode du kan flytt av hovedtråden.
I Android kan du bare oppdatere brukergrensesnittet ditt fra hovedtråden. Hvis du prøver å få tilgang til brukergrensesnittelementer fra en hvilken som helst annen tråd, så kommer du til å møte denne feilen.
For å løse dette problemet, identifiser den delen av bakgrunnsoppgaven din som forsøker å oppdatere brukergrensesnittet og flytte den til en runOnUiThread, for eksempel:
runOnUiThread (new Runnable () @Override public void run () // Oppdater ditt brukergrensesnitt //);
Alternativt kan du bruke en handler eller utføre bakgrunnsarbeidet ditt i en AsyncTask, slik du kan kommunisere med hovedtråden ved hjelp av AsyncTask s onPostExecute () tilbakeringingsmetode. Til slutt, hvis du finner deg selv regelmessig å bytte mellom tråder, vil du kanskje se på RxAndroid, da dette biblioteket lar deg lage en ny tråd, planlegge arbeid som skal utføres på denne tråden, og deretter legge resultatene til hovedtråden, alt med bare noen få linjer med kode.
Dette unntaket blir kastet når appen din forsøker å utføre nettverksoperasjoner på hovedtråden, for eksempel å sende API-forespørsler, koble til en ekstern database eller laste ned en fil. Siden nettverksoperasjoner kan være tidkrevende og arbeidskrevende, er de høyst sannsynlig å blokkere hovedtråden, så Android 3.0 (Honeycomb) og høyere vil kaste denne feilen når du prøver å foreta en nettverksforespørsel på hovedtråden.
Hvis du møter a NetworkOnMainThreadException, Finn deretter nettverkskoden som kjører på hovedtråden din, og flytt den til en egen tråd.
Hvis du trenger å foreta hyppige nettverksforespørsler, vil du kanskje se på Volley, et HTTP-bibliotek som starter egne bakgrunnstråder, slik at alle nettverksforespørsler blir utført av hovedtråden som standard.
Denne feilen oppstår når du prøver å vise en dialog etter at aktiviteten er avsluttet. Hvis du støter på dette problemet, åpner du aktiviteten din og sørger for at du avviser dialogen riktig, ved å ringe avskjedige() i enten aktiviteten din onDestroy () eller onPause () metode, for eksempel:
@Override protected void onDestroy () super.onDestroy (); hvis (pDialogue! = null) pDialogue.dismiss ();
Denne feilen oppstår når appen lager en minneforespørsel som systemet ikke kan møte. Hvis du støter på denne feilmeldingen, starter du ved å utelukke alle de vanligste feilene i minnestyringen. Kontroller at du har husket å avregistrere alle dine sendemottakere, og at du har stoppet alle tjenestene dine. sørg for at du ikke holder på referanser i noen statiske medlemsvariabler, og at du ikke forsøker å laste inn noen store bitmaps.
Hvis du har utelukket alle de åpenbare årsakene til en OutOfMemoryError, da må du grave dypere og undersøke nøyaktig hvordan appen din tilordner minne, fordi det er sjanse for at det er noen områder hvor du kan forbedre appens minnehåndtering.
Android Studio har et helt område dedikert til å hjelpe deg med å analysere appens minnebruk, så start med å velge Vis> Verktøy-vindu fra Android Studio-verktøylinjen. På dette punktet ser du enten en Android Monitor eller Android Profiler alternativ, avhengig av hvilken versjon av Android Studio du har installert.
Vi har diskutert å jobbe med Memory Monitor på denne nettsiden før, men siden Android Profiler er et nytt tillegg til Android Studio, la oss ta en rask titt på de viktigste funksjonene.
Når du åpner Android Profiler, begynner det å registrere tre deler av informasjonen automatisk.
Siden vi er interessert i måten vår app bruker minne, gi Hukommelse delen et klikk, som vil starte Memory Profiler.
Memory Profiler består av en tidslinje som viser de forskjellige typer minne som for øyeblikket tildeles av appen din, for eksempel Java, innfødt, og stable. Over denne grafen finner du en rad ikoner som du kan bruke til å utløse forskjellige handlinger:
Å identifisere delene av søknaden som er ansvarlig for OutOfMemoryError, bruke litt tid på å interagere med appen din, og følg hvordan appens minnefordeling endres som svar på ulike handlinger. Når du har identifisert delen av prosjektet ditt som forårsaker problemet, må du bruke litt tid på å undersøke det for eventuelle minnelekkasjer, samt eventuelle ineffektiviteter i måten det bruker minne.
I denne artikkelen så vi på 13 av feilmeldingene du mest sannsynlig støter på når du utvikler for Android. Vi diskuterte alle de forskjellige faktorene som kan bidra til disse feilene, og trinnene du må ta for å løse dem.
Hvis du blir plaget av en feilmelding som vi ikke dekker, bør du først kopiere / lime hele feilmeldingen til Google, da dette ofte vil vise opp tråder og blogginnlegg der folk diskuterer hvordan man skal løse denne spesielle feilen.
Og hvis du ikke finner en løsning hvor som helst på nettet, kan du alltid nå ut til Android-fellesskapet for hjelp direkte, ved å legge inn spørsmålet ditt til Stack Overflow.
Mens du er her, sjekk ut noen av våre andre innlegg på Android app utvikling!
