Share
I dagens hyperkoblede verden vil folk raskt få resultater. Som mobilutviklere er vi mer oppmerksomme på dette enn de fleste. Brukerne våre setter seg ikke foran et skrivebord. De er på farten, kjører appene våre mens de prøver å gå, snakke og kjøre, slik at de forventer snakkende opplevelser. Kom inn, kom deg ut.
Flere studier fra Akamai, Google og andre har korrelert nettsidehastighet med brukeroppbevaring. Og så langt, tyder bevis på at folk er minst like krevende når de bruker innfødte apps. I en undersøkelse av mobilbrukere gjort av Apigee fryser den øverste klagen om mobilapplikasjoner, og over 44% av de undersøkte brukerne sa at de ville slette en sakte utfører app umiddelbart.
Spør Facebook om viktigheten av raske mobilapper. Når deres lager bunnet ut i de høye tenårene, sa Mark Zuckerberg at å basere sin app på HTML5 var den største feilen de gjorde som et selskap. Hvorfor? Fordi det var sakte. Innen tre uker etter utgivelsen av Facebooks nye, raskere innfødte app, hadde søknadens rangering klatret fra 1,5 stjerner til 4. Sakte applikasjoner forårsaker betydelig bedriftssmerter. Tapt brukere. Tapt dollar.
Når du først snakket med utviklere om å overvåke appens ytelse i produksjon, var det vanligste svaret: "Min app er allerede rask."
Problemet er, som en verden av mobile fragmenter, det er vanskelig å levere en konsekvent rask opplevelse. Hvordan utfører appen din i Kina på en gammel telefon og sakte nettverk? Jeg er villig til å satse du har ingen anelse. Det er absolutt ikke det samme som det utfører på din splitter nye iPhone som er koblet til Wi-Fi-kontoret ditt.
Ytelsen er helt avhengig av konteksten der søknaden din kjører. Her er en rask, men absolutt ikke fullstendig liste over prestasjonskomchaser:
Vi er vant til å tenke på internettproblemer når det gjelder båndbreddebegrensninger, men i mobilnettverk er latens ofte den dominerende faktoren. På et 3G-nettverk kan det ta ca. 2,5 sekunder å gå fra tomgang til tilkoblet før en enkelt byte overføres. Og Sprint sier gjennomsnittlig ventetid på deres 3G-nettverk er 400ms. Det spiller ingen rolle hvor fort serveren din behandler en forespørsel hvis svaret er sakte å komme til telefonen.
Som nekter utvikler vi ofte med det nyeste og beste, men det meste av verden, inkludert massive markeder du vil trenge inn i, gir opp fart for å oppnå overkommelig pris. Våre tester viser at CPU-bundet kode på en iPod 4G tar omtrent fire ganger lengre enn på en iPhone 5S. På Android er forskjellen enda viktigere.
Hvis appen bruker for mye minne, blir det drept av operativsystemet. Til brukeren ser dette ut som et nullpunkts unntak. Selv om koden din er squeaky ren uten en enkelt minnelekkasje, kan minnet høyt vannmerke føre til krasjer på mindre kraftige, men populære, telefoner på viktige markeder.
Batterier er en av de første tingene å få ned, når produsenter prøver å spare plass og penger. Men det vil ikke gjøre brukerne mer forståelige når appen din tømmer all sin kraft.
La oss si et øyeblikk at du er overbevist om at du trenger en rask søknad, og den skal være rask overalt, ikke bare for deg når du kjører appen din via Apples Instruments CPU-profiler. Hva er en utvikler å gjøre? Akkurat nå har du to grunnleggende alternativer:
En rask API betyr en rask app. Ikke sant? Dette er en webutvikleres mentalitet, og hvis du er en mobilutvikler, er det feil.
Internett er en tynn klientarkitektur. Ved å legge til side JavaScript store webapps, kjører det meste av den interessante koden bak nettsteder på serveren. Klienten-nettleseren-er faktisk bare en statsløs gjengivelsesmotor. Når ytelsen synker, er det vanligvis et skaleringsproblem i infrastrukturen for backend.
Native, mobile apps, derimot, er tykke klienter. De har store, multi-threaded kodebaser. De opprettholder staten. Og de må utføre på et stort utvalg av telefoner, operativsystemer og nettverk. Serverteamet ditt kan fortsatt skru opp brukerens opplevelse, men det er et helt nytt sett med problemer som ikke kommer til å dukke opp i dine servervarsler..
Fint. Du får det. Du må sørge for at du tester appene dine i en haug med virkelige verden scenarier. Så du skal bygge en fancy QA-lab med 100 forskjellige håndsett. Deretter skal du legge dem inn i et faradaybur, slik at du kan simulere ugunstige nettverksforhold, og ansette en hær av QA-folk for å kjøre hver ny utgave gjennom alle mulige tiltak i søknaden din.
Jeg innrømmer at hvis du har råd til det, er dette ikke en dårlig ide. Men kombinasjonene blir raskt overveldende. Tenk deg at du bryr deg om de 100 beste telefonene, 10 nettverkshastigheter, 20 forskjellige utenlandske markeder med forskjellige latenser og 5 forskjellige OS-versjoner. Forestill deg nå at du har 50 forskjellige handlinger i appen din. Ignorerer gjensidig avhengighet mellom handlingene og varierende brukerdata, du har 1 million kombinasjoner for å teste. au!
Dette er et klassisk QA-problem. Kvalitetssikring betyr at du gjør ditt beste for å teste de vanligste bruksområdene. Men det er aldri ment å være en erstatning for overvåking. Det er rett og slett umulig å holde seg på toppen av alle mulige sviktstilfeller.
Vi trenger et nytt verktøysett, bygget fra bakken, for å spesifikt måle ytelsesproblemene i mobilappene. Hvilke beregninger skal disse nye verktøyene fange opp?
Ingenting irriterer en bruker mer enn en frossen skjerm. Ved å fange hver gang appen din tar over en tidsgrense for å lage en ramme, kan du få en ide om hvor ofte de ser en merkbar frysning.
Hvis du følger gode UI / UX-praksis, når som helst du trenger å gjøre arbeid som skal ta mer enn noen få millisekunder, bør du gjøre det i bakgrunnen og kaste opp en spinner. Men selv om du er på toppen av tråden din, har brukerne fortsatt begrenset tålmodighet.
Etter 1 sekund har brukerne en mental kontekstbryter, og etter 10 sekunder forlater brukerne sin oppgave. Hvis du fanger hver gang du viser en spinner, har du en god generisk indikator for hvor lenge den typiske brukeren venter på appen din.
Memory bugs er en av de vanskeligste tingene å spore, spesielt siden Tomt for minne Killer på IOS resulterer ikke i et stakkespor. Det er for dyrt å spore alle tildelinger, men det er bra å registrere innbyggert minne på iOS eller VM Heap-bruk på Android, lave overheadmålinger.
Latency og båndbredde er begge svært variabel på mobilnett, og spiller en nøkkelrolle i brukeropplevelsen. For hver API-forespørsel kan du registrere hvor lang tid det tar å få det første svaret (latens), hvor lang tid det tar å få full respons (nedlastingstid), og bytes nedlastet (bytes / nedlastingstid tilsvarer båndbredde).
En av de få grunnene til at jeg avinstallerer apper, er bruk av høyt batteri. Det er åpenbart batteri suger, som å bruke enhetens GPS, men det er andre uventede gotchaser, for eksempel å aktivere den trådløse antennen for ofte. Både iOS og Android tilbyr APIer for å overvåke batteriladningsnivåer.
I mobil er konteksten alt. Når noe går galt, bør du i det minste kende applikasjonsversjon, plassering, transportnettverk, versjon av operativsystemet og enheten.
Hvis du er ambisiøs, kan det hende du har noen hjemmegående ytelsesinstrumenter i søknaden din. Du har sannsynligvis noen grunnleggende timere for viktige handlinger i appen din, og deretter huser du dataene via en logg eller en spesialisert pakke med JSON.
Hvis ja, klapp deg selv på ryggen. Du har gjort langt mer enn de fleste. Men det er mange ulemper med denne tilnærmingen. Hva om du har ytelsesproblemer på uventede steder i appen din? Hvis du har et problem, hvordan vet du hva som forårsaket det? Var det en lang metodeoppringing, en sakte API-forespørsel, eller for mye data på ledningen?
Og når du får de raske ytelsesdataene, hvordan analyserer du og visualiserer den? Hvis du skriver et engangsskript, hvor ofte kjører du det? Og, Gud forby, hva skjer hvis ytelsesinstrumentet ditt medfører ytelsesproblemer?
På Pulse.io har vi jobbet hardt i det siste året og bygget en SDK-full av overvåkning av godhet. Vi fanger opp alle beregningene som er oppført ovenfor, mens du opprettholder et veldig lett fotavtrykk. Vi bruker mindre enn 3% av CPU, batch sender våre data for å unngå å slå på radioen, og begrense vår bruk av minne ved å kaste bort lav prioritetsinformasjon.
Den beste delen om Pulse.io er at den fanger opp alt dette automatisk. Det er en ting å manuelt instrumentet din app med din hjemme voksen løsning. Det er en annen ting helt å overbevise hver ingeniør på teamet ditt for å gjøre det, og å bruke samme instrumentasjonsmetode konsekvent over tid.
Med Pulse.io slipper du bare i SDK-en, og den finner automatisk alle brukerinteraksjonene i appen din og poster når disse interaksjonene forårsaker dårlig oppførsel som skjerm fryser eller lange asynkrone oppgaver.
Installering av Pulse.io vil ta deg mindre tid enn å lese denne artikkelen. Vi er for tiden i privat beta, men hvis du skyter oss en epost på beta [at] puls [dot] io og nevner at du leser om oss på Tuts +, setter vi deg på en konto.
Når du har lastet ned SDK, er installasjonen super enkel. Slipp SDK-en i appen din, legg til noen avhengigheter, og ring [PulseSDK-skjerm: @ "YOUR_APP_KEY"] i appen din main.m. Du er ferdig.
Forhåpentligvis har jeg overbevist deg om tre ting:
Jeg oppfordrer deg til å undersøke din egen apps virkelige verden. Gi Pulse.io et forsøk. Det er ikke mye å tape og mye prestasjon å vinne.
Accentsconagua