Like interessant som webapplikasjoner er, er de ikke det eneste spillet i byen. I disse dager er mobilapplikasjoner en stor del av programvarenes utviklingslandskap. På samme måte som med webapps, vil vi at vår mobilapplikasjonskode skal være effektiv.
Heldigvis, i det siste året eller to, har New Relic fokusert hardt på å bygge opp en løsning for å overvåke ytelsen til mobilappene dine. I dag ser vi på hvordan du kan begynne å bruke New Relic for å overvåke ytelsen til en Android-applikasjon.
Hvorfor Overvåk Mobile Apps At All?
Det flotte med å bygge en webapp er at du alltid kan distribuere en ny versjon, umiddelbart tvinge hele brukerbasen din for å bruke den nye koden din. Så hvis du ikke overvåket koden før, kan du enkelt koble til New Relic eller hack opp noe tilpasset, skyve det ut og begynne å få beregninger innen få minutter.
Med mobilapper er du ikke så heldig. Du kan selvsagt frigjøre en ny versjon når som helst du vil, men prosessen er potensielt lenger godkjent av appbutikk, for eksempel. Og selv når den nye versjonen er der ute, kan du ikke tvinge brukerne til å oppgradere. Det er derfor viktig å tenke på hvilken som helst form for overvåkning du kanskje vil gjøre før du slipper den første versjonen av appen din.
Selv om du ikke trenger å bekymre deg for ytelsen til appen din for en stund, så har du allerede en overvåkingsløsning på plass, du må bare begynne å tolke beregningene.
I tillegg er det en sjelden mobil app i disse dager som ikke har en webkomponent til den. Omtrent hver applikasjon gjør i disse dager HTTP-forespørsler til en API- og ofte mange forskjellige APIer.
Som vi vet er nettverkssamtaler ikke alltid de mest pålitelige tingene. Det ville være flott hvis vi kunne finne ut hvor ofte API-samtaler mislykkes for våre brukere, og enda viktigere, hvor sakte våre API-anrop er i gjennomsnitt. Det er den eneste måten å vite om brukerne har en god opplevelse med applikasjonen vår, eller hvis de blir frustrert av lag.
Hvis du ikke overvåker søknaden din, kan du bare gjette om denne typen ting. Jeg vet ikke om deg, men jeg er vanligvis mye mer komfortabel med kalde harde data.
Det er mange andre viktige spørsmål som en god overvåkingsløsning kan hjelpe oss med å svare på, men vi kan dekke dem når vi jobber med vår Android-applikasjon, så la oss få sprekker.
Bygg en grunnleggende Android App
Normalt, for en introduksjonsartikkel som denne, liker jeg å fokusere på emnet ved å gi inn i dette tilfellet New Relic for mobil - og hold resten av koden som Hei Verden som mulig.
Det er lett å bygge en Hei Verden Android app, Google har selv en veiledning om den. Dessverre er den appen bare litt også grunnleggende. Det gjør ingen nettverkssamtaler, noe som betyr at vi ikke vil kunne se på en stor del av det New Relic tilbyr for mobilappovervåking. Så, vi vil litt endre vår grunnleggende app.
Vår app vil ha to skjermer, på den første skjermen vil vi kunne legge inn et Twitter-håndtak og sende det inn. På dette tidspunktet går vår app til den andre skjermen og viser noen plassholdertekst. I mellomtiden kommer søknaden vår til Twitter og henter den siste tweet for det håndtaket. Når tweet er tilgjengelig, oppdaterer vi den andre skjermen for å vise den. Appen er fortsatt ganske grunnleggende, men forhåpentligvis er det komplisert nok at vi kan få noen interessante data fra New Relic.
Jeg skal ikke gå gjennom å sette opp hele applikasjonen, men her er de interessante delene. I henhold til Google-opplæringen, når vi trykker på knappen på den første skjermen, vil den passere langs verdien av tekstfeltet til det andre skjermbildet, men i vårt tilfelle vil det være et Twitter-håndtak:
På den andre skjermen vil vi hente den siste tweeten for det håndtaket. Men vi kan ikke gjøre det på UIThread, vi trenger en AsyncTask. Vi lager en og sparker den inn i onCreate metode for den andre aktiviteten:
@Override protected void onCreate (Bundle savedInstanceState) super.onCreate (savedInstanceState); setContentView (R.layout.activity_display_message); setupActionBar (); String handle = getIntent (). GetStringExtra (MainActivity.EXTRA_MESSAGE); TextView textView = ny TextView (dette); textView.setTextSize (40); ny FetchLatestTweetTask (textView, handle) .execute (); // Sett tekstvisningen som aktivitetsoppsettet setContentView (textView);
Vi viser noen plassholdertekst før du henter tweet og oppdaterer plassholderteksten med tweets innhold etter at vi har hentet det. Vi bruker Twitter4J for å snakke med Twitter API. For at API-biblioteket skal virke, har jeg dumpet en twitter4j.properties fil i / src mappe av prosjektet slik at det ender opp på klassestien i henhold til dokumentasjonen.
Egenskapsfilen inneholder OAuth-forbrukernøkkel, forbrukerhemmelig, tilgangstokenøkkel og tilgangsfortegnelsehemmelighet for Twitter-appen som jeg opprettet bare for dette.
Dette er all den interessante koden i vår søknad, resten er bare generisk boilerplate som i den innledende Google-opplæringen.
Sette opp nye relikvier for deg App
Det er veldig enkelt å sette opp New Relic for å begynne å overvåke din Android-app. I din New Relic-konto klikker du på Mobil i menyen. Dette er hvor alle mobilappene dine vil leve, akkurat som webappene lever under applikasjoner menyelement.
Klikk nå på Legg til en ny app knapp:
Dette tar deg til en annen skjerm hvor New Relic vil gå deg gjennom å sette opp en ny app:
Vi klikker på Android og gi vår app et navn. Når du har gitt navnet ditt, må du trykke på Fortsette slik at New Relic genererer en ny API-nøkkel for søknaden din.
Deretter må vi installere New Relic-agenten. Jeg bruker Eclipse så jeg går til Hjelp> Installer ny programvare ... og legg til New Relic som et nettsted:
Klikk neste og vent på Eclipse å gjøre ting. Når det er gjort, må du starte Eclipse på nytt. På dette tidspunktet bør du kunne høyreklikke prosjektet ditt i Eclipse og det bør være en Installer New Relic menyalternativ. Når vi klikker på det, vil New Relic agent-krukken ende opp i / libs mappe av prosjektet vårt.
For øvrig, hvis en ny versjon av New Relic-agenten kommer sammen, oppdaterer du den på samme måte. Først må du gjøre Hjelp> Sjekk etter oppdateringer for å få de siste oppdateringene. Etter det, bare høyreklikk prosjektet ditt og det skal være en Oppdater New Relic menyalternativ, som vil oppdatere New Relic-jar når du klikker:
Nå må vi gi våre app-tillatelser for INTERNETT og ACCESS_NETWORK_STATE som New Relic må sende data tilbake til sine servere. Våre AndroidManifest.xml vil se slik ut:
...
Nå må vi bare lansere agenten. I vår MainActivity.java vi importerer New Relic:
Merk programtoken. Hvis du trykker på Fortsette Når du ga søknaden et navn, bør dette allerede være ferdigfylt for deg. Når appen din er oppe, kan du alltid se den opp igjen i innstillinger menyen for søknaden din.
Etter dette trinnet bygger vi prosjektet og distribuerer det til en emulator eller en fysisk enhet. Jeg foretrekker å distribuere til en testenhet som jeg finner det å være raskere, mer responsiv og lettere å jobbe med. Jeg vil bruke Nexus 4.
Hvis vi ser på LogCat-fanen når applikasjonen distribueres, bør vi se utgang som ligner dette:
Dette er New Relic som ringer hjem for å sende data. Hvis vi nå går tilbake til brukergrensesnittet New Relic, bør vi begynne å se data.
Utforske oversikten
Når du går for å se på appen din i New Relic, vil du først trykke på Oversikt skjerm. I likhet med skjermbildet for nettapplikasjon vises det flere viktige beregninger for appen din, for eksempel Http responstid, Tregeste interaksjoner, etc.
Aktiviteten på disse grafene er sporadisk siden vi bare har en klient som sender data tilbake, og vi har bare gjort et par samspill.
Så hva er noen av de mer interessante tingene du kan se i New Relic for mobilappen din? Vel, det er det App> Enheter fanen som viser hvilke enheter folk bruker din app på. Dette er interessant siden du kan fortelle hva slags telefoner / tabeller det meste av brukerbasen bruker. Er folk mest på eldre enheter eller nyere? Er de mest på tabletter eller telefoner? Dette er verdifulle data.
Du kan bore deg ned i hver enhet og se hvor bra appen din gjør der. Er samhandlingstiden for den enheten tregere enn hva du forventer? Hva med Http responstiden? Hvor mange aktive brukere bruker for øyeblikket appen din på denne typen enhet? I vårt tilfelle:
Det er bare en enhet, så det er ikke så mye å se. Men hvis en stor prosentandel av brukerbasen din var på en enhet der appen din ikke fungerte veldig bra, ville du se det med en gang og kunne løse problemet.
Ligner på enheter fan, det er OS versjoner fanen, som bryter ned bruken av appen din av den versjonen av Android som brukerne har installert:
Du kan fortelle om du trenger å fokusere mer på din oppmerksomhet på nyere versjoner av Android, eller hvis det meste av brukerbasen din fortsatt er på en eldre versjon.
Så er det Network fan og sine barn. I Kart fanen, kan du se hvilke APIer appen din kobler til og hvor godt hver av dem gjør det. Hva er gjennomstrømming, responstid og feilfrekvens:
I vårt tilfelle har vi bare Twitter API og det er ganske sakte faktisk. Kanskje vi kanskje vurderer å cache noen av svarene over en periode.
I Nettverk> Http-forespørsler fan, kan vi bore ned i hvert endepunkt for alle APIer som vi bruker på samme måte som hvordan vi driller ned i enheter og OS-versjoner. Vi kan finne ut hvilke sluttpunkter som brukes mest, og hvilke er de tregeste. Dette gir oss gode råd om hvor å styre optimaliseringsarbeidet. Dette gjelder spesielt hvis vi også kontrollerer APIene som blir brukt.
I Nettverk> Geografi fanen, kan du fortelle hvor de fleste brukerne kommer fra og i Carriers fanen du kan se hvilken type internettforbindelse brukerne har. I vårt tilfelle er jeg på Wi-Fi:
Det er svært verdifullt å vite om brukerbasen din bruker Wi-Fi, 3G eller 4G, da optimaliseringsarbeidet ditt kan være helt forskjellig avhengig av nedbrytingen..
Under Innstillinger> Varsler, Du kan også definere noen betingelser for dine eksterne APIer for New Relic å varsle deg om svarstidene overskrider en bestemt terskel, eller hvis feilfrekvensen overstiger en viss prosentandel.
Dette er potensielt mindre verdifullt for APIer du ikke kontrollerer, men fortsatt en god indikator hvis en API du bruker er ustabil eller ikke veldig effektiv.
De to siste interessante er Bruk> Versjoner og Bruk> Månedlige Uniques. Den første viser hvilke versjoner av appen du bruker i naturen. Dette lar deg fortelle hvor ivrige brukere laster ned oppdateringer av appen din. Det viser deg også hvor godt hver versjon av appen din utfører på enheten. Er den nye versjonen brukt med mer minne enn den forrige versjonen?
De månedlige unikene gir deg i utgangspunktet en ide om folk faktisk samhandler med appen din. Du kan ha 10 millioner nedlastinger, men hvis antall månedlige uniques er lave, er det ikke så bra som de ser ut til å være.
Konklusjon
Dette er en grunnleggende oversikt over noen, men ikke alle interessante, funksjoner i New Relic for Android-apper. I seg selv er ingen av funksjonene tankegang, men det er gode solide data at du for en mobilapp ikke kan få noen annen måte.
Hvordan appen din blir brukt og hvilke enheter, hvor bra nettverkssamtaler dine utfører på en langsom tilkobling, er dette typen data som tvinger deg til å slutte å gjette og ta informerte beslutninger om hvordan du kan forbedre appen din og gi brukerne en bedre opplevelse.
Husk at ytelsen er like viktig for mobilapper som det er for nettprogrammer, og det er ingen grunn til å gjette om hva som gjør appen sakte når det er en mye bedre måte lett tilgjengelig.
Share
Accentsconagua
