Zo interessant als webapplicaties, ze zijn niet het enige spel in de stad. Tegenwoordig maken mobiele applicaties een groot deel uit van het landschap voor softwareontwikkeling. Net als bij web-apps willen we dat onze mobiele applicatie-code performant is.
Gelukkig heeft New Relic de afgelopen twee jaar hard gewerkt aan het uitdenken van een oplossing voor het monitoren van de prestaties van uw mobiele apps. Vandaag zullen we bekijken hoe u New Relic kunt gaan gebruiken om de prestaties van een Android-applicatie te controleren.
Waarom mobiele apps in het geheel monitoren?
Het mooie van het bouwen van een webapp is dat je altijd een nieuwe versie kunt implementeren, direct forceren uw hele gebruikersbestand om uw nieuwe code te gebruiken. Dus als u uw code niet eerder hebt bewaakt, kunt u eenvoudig New Relic koppelen of iets op maat hakken, het eruit duwen en binnen een paar minuten statistieken ophalen..
Met mobiele apps heb je niet zoveel geluk. Je kunt natuurlijk een nieuwe versie vrijgeven wanneer je maar wilt, maar het proces is mogelijk een langere app-goedkeuring, bijvoorbeeld. En zelfs wanneer uw nieuwe versie beschikbaar is, kunt u uw gebruikers niet dwingen om te upgraden. Het is daarom belangrijk om na te denken over elke vorm van monitoring die u zou willen uitvoeren voordat u de eerste versie van uw app ooit publiceert.
Zelfs als u zich enige tijd geen zorgen hoeft te maken over de prestaties van uw app, is uw bewakingsoplossing al op zijn plaats, u hoeft alleen maar de statistieken te gaan interpreteren.
Bovendien is het tegenwoordig een zeldzame mobiele app die ook geen webcomponent heeft. Zowat elke applicatie maakt tegenwoordig HTTP-verzoeken naar een API - en vaak veel verschillende API's.
Zoals we weten, zijn netwerkoproepen niet altijd de meest betrouwbare dingen. Het zou geweldig zijn als we konden achterhalen hoe vaak API-aanroepen falen voor onze gebruikers en, nog belangrijker, hoe langzaam onze API-aanroepen gemiddeld zijn. Het is de enige manier om te weten of onze gebruikers een goede ervaring hebben met onze applicatie of dat ze gefrustreerd raken door vertraging.
Als u uw toepassing niet controleert, kunt u alleen maar gissen naar dit soort dingen. Ik weet niets over u, maar ik ben meestal veel comfortabeler met koude gegevens.
Er zijn nog veel andere belangrijke vragen die een goede monitoringoplossing ons kan helpen beantwoorden, maar we kunnen die behandelen terwijl we werken met onze Android-applicatie, dus laten we kraken.
Een eenvoudige Android-app bouwen
Normaal gesproken wil ik me, voor een inleidend artikel als dit, concentreren op het onderwerp bij de hand, in dit geval New Relic voor mobiel, en de rest van de code zo houden Hallo Wereld als mogelijk.
Het is eenvoudig om een te bouwen Hallo Wereld Android-app, Google heeft er zelfs een tutorial over. Helaas is die app maar een beetje te basic. Het maakt geen netwerkoproepen, wat betekent dat we niet in staat zijn om een groot deel van wat New Relic biedt voor het controleren van mobiele apps te bekijken. Dus we zullen onze basisapp enigszins aanpassen.
Onze app heeft twee schermen, op het eerste scherm kunnen we een Twitter-handle invoeren en verzenden. Op dit punt zal onze app naar het tweede scherm gaan en een plaatsaanduidingstekst weergeven. In de tussentijd gaat onze applicatie naar Twitter en haalt de laatste tweet voor die handle. Zodra de tweet beschikbaar is, werken we het tweede scherm bij om het weer te geven. De app is nog steeds vrij eenvoudig, maar hopelijk is het complex genoeg om interessante gegevens van New Relic te kunnen ontvangen.
Ik ga niet doorlopen met het instellen van de hele applicatie, maar hier zijn de interessante delen. Vanaf de Google-tutorial zal het, wanneer we op de knop op het eerste scherm drukken, de waarde van het tekstveld doorgeven aan het tweede scherm, maar in ons geval zal het een Twitter-handle zijn:
Op het tweede scherm willen we de laatste tweet ophalen voor die handle. Maar we kunnen het niet doen op de UIThread, we hebben een AsyncTask. We zullen er een maken en het in de onCreate methode van de tweede activiteit:
@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 = new TextView (this); textView.setTextSize (40); nieuw FetchLatestTweetTask (textView, handle) .Execute (); // Stel de tekstweergave in als de activiteitenlay-outsetContentView (textView);
De daadwerkelijke taak ziet er als volgt uit:
public class FetchLatestTweetTask breidt AsyncTask uit private TextView textView; privé String-handle; public FetchLatestTweetTask (TextView textView, String handle) this.textView = textView; this.handle = handle; @Override beschermd String doInBackground (Void ... args) Twitter twitter = new TwitterFactory (). GetInstance (); Stringstatus = null; probeer Gebruiker gebruiker = twitter.showUser (handle); status = user.getStatus (). getText (); catch (Uitzondering e) e.printStackTrace (); retourstatus; protected void onPreExecute () textView.setText (String.format ("Tweet ophalen door @% s ...", handle)); protected void onPostExecute (String tweet) textView.setText (tweet);
We plaatsen een tijdelijke aanduiding voor het ophalen van de tweet en werken de tekst van de tijdelijke aanduiding bij met de inhoud van de tweet nadat we deze hebben opgehaald. We gebruiken Twitter4J om met de Twitter API te praten. Om de API-bibliotheek te laten werken, heb ik een gedumpt twitter4j.properties bestand in de / src map van het project zodat het op het klassenpad terechtkomt volgens de documentatie.
Het eigenschappenbestand bevat de OAuth-gebruikerssleutel, het consumentengeheim, de toegangstokencode en toegangstokencode voor de Twitter-app die ik hiervoor heb ingesteld.
Dit is de interessante code in onze applicatie, de rest is gewoon generieke boilerplate volgens de inleidende Google-tutorial.
Nieuwe relikwie voor u instellen App
Het instellen van New Relic om je Android-app te monitoren is heel eenvoudig. Klik in uw nieuwe Relic-account op mobiel in het menu. Hier wonen al uw mobiele apps, net als de web-apps onder de toepassingen menu onderdeel.
Klik nu op de Voeg een nieuwe app toe knop:
Dit brengt je naar een ander scherm waar New Relic je helpt bij het instellen van een nieuwe app:
We klikken op Android en geef onze app een naam. Nadat u uw app een naam heeft gegeven, moet u op drukken Doorgaan met zodat New Relic een nieuwe API-sleutel voor uw toepassing genereert.
Vervolgens moeten we de New Relic-agent installeren. Ik gebruik Eclipse dus ik ga naar Help> Nieuwe software installeren ... en voeg New Relic toe als een site:
Klik volgende en wacht op Eclipse om zijn ding te doen. Als het klaar is, moet u Eclipse opnieuw starten. Op dit punt zou je in Eclipse met de rechtermuisknop op je project kunnen klikken en er zou een moeten zijn Installeer nieuwe relikwie menu-optie. Wanneer we erop klikken, komt de pot met de nieuwe Relic-agent in de / libs map van ons project.
Overigens, als er een nieuwe versie van de New Relic-agent langskomt, update je deze op dezelfde manier. Eerst, doe Help> Controleren op updates om de nieuwste updates te krijgen. Klik daarna met de rechtermuisknop op uw project en er moet een zijn Update nieuwe relikwie menuoptie, die de New Relic-pot zal bijwerken wanneer erop wordt geklikt:
Nu moeten we onze app-machtigingen voor geven INTERNET en ACCESS_NETWORK_STATE omdat New Relic gegevens moet terugsturen naar hun servers. Onze AndroidManifest.xml ziet er zo uit:
...
Nu moeten we gewoon de agent lanceren. In onze MainActivity.java we importeren New Relic:
import com.newrelic.agent.android.NewRelic;
Vervolgens starten we de agent binnen de onCreate methode:
protected void onCreate (Bundle savedInstanceState) super.onCreate (savedInstanceState); setContentView (R.layout.activity_main); . NewRelic.withApplicationToken ( "XXXXXXXXXXXXXXXXXXX") te starten (this.getApplication ());
Noteer het applicatietoken. Als u op hebt gedrukt Doorgaan met wanneer u uw aanvraag een naam heeft gegeven, moet deze al voor u zijn ingevuld. Zodra uw app actief is, kunt u deze altijd opnieuw opzoeken in de instellingen menu voor uw toepassing.
Na deze stap bouwen we het project en implementeren het op een emulator of een fysiek apparaat. Ik geef er de voorkeur aan om op een testapparaat te implementeren, omdat ik vind dat het sneller, responsiever en gemakkelijker om mee te werken is. Ik zal mijn Nexus 4 gebruiken.
Als we naar het LogCat-tabblad kijken wanneer de toepassing wordt geïmplementeerd, zien we uitvoer als volgt:
Dit is hoe we weten dat New Relic is geladen. Als we daarna naar LogCat blijven kijken, zien we hier ongeveer elke minuut iets:
02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: connected 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: Verzenden 2 HTTP-transacties. 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: verzenden van HTTP-fouten. 02-23 17: 55: 40.410: I / com.newrelic.agent.android (31413): Harvester: 0 activiteitssporen verzenden.
Dit is New Relic die naar huis belt om gegevens te verzenden. Als we nu teruggaan naar de gebruikersinterface van New Relic, moeten we beginnen met het bekijken van gegevens.
De dashboards verkennen
Wanneer je in New Relic naar je app gaat kijken, ga je eerst naar Overzicht scherm. Net als bij het overzichtsscherm van de webtoepassing worden verschillende belangrijke statistieken over uw app weergegeven, zoals Http reactietijd, Traagste interacties, enz.
De activiteit in die grafieken is sporadisch, omdat we maar één client gegevens terugsturen en we hebben maar een paar interacties gedaan.
Wat zijn enkele van de interessantere dingen die u in New Relic voor uw mobiele app kunt zien? Wel, daar is de App> Apparaten tabblad dat laat zien op welke apparaten mensen uw app gebruiken. Dit is interessant omdat u in één oogopslag kunt zien welk type telefoons / tabellen het grootste deel van uw gebruikersbestand gebruikt. Zijn mensen meestal op oudere apparaten of nieuwere? Zijn ze meestal op tablets of telefoons? Dit zijn waardevolle gegevens.
U kunt op elk apparaat inzoomen en zien hoe goed uw app daar presteert. Is de interactietijd voor dat apparaat langzamer dan wat u zou verwachten? Hoe zit het met de HTTP-responstijd? Hoeveel actieve gebruikers gebruiken uw app momenteel op dit type apparaat? In ons geval:
Er is maar één apparaat, dus er is niet zoveel te zien. Maar als een groot percentage van uw gebruikersbestand zich op een apparaat bevond waar uw app niet goed presteerde, zou u het meteen kunnen zien en het probleem kunnen verhelpen.
Vergelijkbaar met de apparaten tab, daar is de OS-versies tabblad, waarmee het gebruik van uw app wordt onderverdeeld in de versie van Android die uw gebruikers hebben geïnstalleerd:
U kunt zien of u meer aandacht moet besteden aan nieuwere versies van Android of dat het grootste deel van uw gebruikersbestand nog op een oudere versie is.
Dan is er de Netwerk tabblad en zijn kinderen. In de Kaart Op het tabblad kunt u zien met welke API's uw app verbinding maakt en hoe goed elk van hen met deze app bezig is. Wat is de doorvoer, responstijd en het foutenpercentage:
In ons geval hebben we alleen de Twitter API en het is eigenlijk best langzaam. Misschien kunnen we overwegen een deel van de antwoorden voor een bepaalde tijd in de cache op te slaan.
In de Netwerken> Http-aanvragen tab kunnen we in elk eindpunt van elke API die we gebruiken, op een vergelijkbare manier inzoomen op de manier waarop we naar apparaten en OS-versies inzoomen. We kunnen uitvinden welke eindpunten het meest worden gebruikt en welke het langzaamst zijn. Dit geeft ons een aantal solide aanknopingspunten voor waar we onze optimalisatie-inspanningen moeten richten. Dit geldt met name als we ook de API's controleren die worden gebruikt.
In de Netwerk> Geografie tab, kunt u zien waar de meeste van uw gebruikers vandaan komen en in de carriers tabblad kunt u zien wat voor soort internetverbinding uw gebruikers hebben. In ons geval zit ik op wifi:
Het is erg waardevol om te weten of uw gebruikersgroep wifi, 3G of 4G gebruikt, omdat uw optimalisatie-inspanningen totaal verschillend kunnen zijn, afhankelijk van de uitsplitsing.
Onder Instellingen> Waarschuwingen, u kunt ook een aantal voorwaarden voor uw externe API's definiëren voor New Relic om u op de hoogte te stellen als responstijden een bepaalde drempel overschrijden of als de foutenpercentages boven een bepaald percentage gaan.
Dit is mogelijk minder waardevol voor API's die u niet beheert, maar nog steeds een goede indicator als een API die u gebruikt, onstabiel of niet erg performant is.
De laatste twee interessante zijn Gebruik> Versies en Gebruik> Maandelijks Uniques. De eerste toont u welke versies van uw app in het wild worden gebruikt. Op deze manier kunt u zien hoe graag gebruikers updates van uw app downloaden. Het laat ook zien hoe goed elke versie van uw app op het apparaat presteert. Werkt de nieuwe versie met meer geheugen dan de vorige versie??
De maandelijkse uniques geeft je in principe een idee of mensen daadwerkelijk interactie hebben met je app. Je hebt misschien 10 miljoen downloads, maar als het aantal maandelijkse uniques laag is, zijn de dingen niet zo groot als ze lijken te zijn.
Conclusie
Dit is een basisoverzicht van enkele, maar niet allemaal interessante, eigenschappen van de nieuwe Relic voor Android-apps. Op zichzelf zijn geen van de functies verbluffend, maar het zijn goede solide gegevens dat je voor een mobiele app geen andere manier kunt krijgen.
Hoe uw app wordt gebruikt en op welke apparaten, hoe goed uw netwerkaanroepen op een langzame verbinding presteren, dit is het type gegevens dat u dwingt te stoppen met gissen en weloverwogen beslissingen te nemen over hoe u uw app kunt verbeteren en uw gebruikers een betere ervaring.
Houd er rekening mee dat prestaties net zo belangrijk zijn voor mobiele apps als voor web-apps, en er is geen reden om te raden wat uw app traag maakt als er een veel betere manier beschikbaar is.
Share
Accentsconagua
