Gevinster:
- Ved først å ta en profil og måle den virkelige flaskehalsen, gjøre optimalisering basert på data i stedet for gjetting og få profilutgangen tolket av kunstig intelligens
- Evne til å målrette den dyreste operasjonen når det gjelder oppstartstid, flyt, minne og batteri og fjerne det tunge arbeidet fra hovedtråden
- Evne til å administrere batteri- og prosessorkostnadene for AI-funksjoner som enhetsmodeller og nettsky-anrop gjennom sampling og batchbehandling
Mobilbrukere er utålmodige. Hvis appen åpnes sakte, henger mens du ruller eller tapper batteriet raskt, sletter brukeren den og gir den en stjernerangering i butikken. Ytelse og batterieffektivitet er et spørsmål om en mobilapps overlevelse; Det påvirker direkte både brukertilfredshet og butikkrangering. AI er et kraftig hjelpemiddel for å oppdage ytelsesflaskehalser (flaskehalser), tolke måleresultater og anbefale optimaliseringer. Men den gylne regelen består: mål først, optimaliser senere. I denne enheten skal vi lære å løse ytelses- og batteriproblemer på en databasert måte med AI. Et spesielt viktig problem er å håndtere innvirkningen på batteriet og ytelsen til AI-egenskapene vi har lagt til i tidligere enheter (modell på enheten, skysamtaler).
Optimalisering uten å måle
Den største feilen til en uerfaren utvikler er prediktiv optimering: å kaste bort tid på å si "denne må være treg". Den virkelige flaskehalsen er nesten alltid på et uventet sted. Så først blir profilen tatt (profilering — måler hvilken del av applikasjonen som bruker hvor mye tid/minne/batteri). Android Studio Profiler og Xcode Instruments er for denne jobben. Å gi måledata til AI gir raskere tolkning; Men uten måling betyr det å si til AI "min applikasjon er treg, få fart på den" å gjøre blinde spådommer.
De fire hovedaksene for ytelse er:
akse
symptom
typisk årsak
Starttid
Søknaden åpner sent
Tungt arbeid på hovedtråden
Flytende (jank)
Scroll setter seg fast
Lang prosessering, unødvendig omtegning i UI-tråden
minne
hevelse, kollaps
Lekkasje, stort bilde, cache ukontrollert
batteri/varme
rask utløsning
Kontinuerlig plassering, nettverk, sensor, bakgrunnsjobb
Tips: Når du spør AI om et ytelsesproblem, oppgi profilutdata (hvilken funksjon tar hvor lang tid, minnegraf). Harde data som "Denne funksjonen tar 30 ms per bilde" lar AI-en fokusere på den virkelige flaskehalsen; En subjektiv setning som "sakte" gir et generisk og ubrukelig svar.
Batterikostnad for AI-evner
AI-funksjonene vi la til i denne modulen er kraftige, men de er ikke gratis. Å trekke ut en modell på enheten belaster prosessoren og batteriet; En konstant kjørende bildegjenkjenning (f.eks. kamera behandler hvert bilde) vil varme opp telefonen og tappe batteriet i løpet av minutter. Cloud AI-anrop spiser derimot opp batteriet ved å holde nettverksradioen (antennen som sender og mottar data) på hele tiden. Løsninger: kjør modellen på enheten bare når det er nødvendig, prøv kameraet et par ganger per sekund i stedet for hvert bilde, send satsvis skyforespørsler, gjør tunge løft mens enheten lader eller er inaktiv.
Forsiktig: En konstant kjørende AI-funksjon (live-oversettelse, kontinuerlig gjenkjenning av objekter) kan tømme batteriet veldig raskt, varme opp enheten og kan bli strupet av systemet. En funksjon som gjør at brukeren føler at denne kostnaden er slettet. Jeg spør alltid AI "hvordan gjør jeg denne funksjonen batterivennlig?" Still også spørsmålet.
Trinn for optimalisering
- Mål. Finn den virkelige flaskehalsen med Profiler; ikke gjett.
- Velg det største problemet. Ikke jag etter 1% forbedring; Sikt på den dyreste transaksjonen.
- Spør AI med data. Be om optimaliseringsforslag med profilutgang + relevant kode.
- Påfør og mål på nytt. Er forbedringen reell? Har tallet sunket?
- Regresjonskontroll. Har optimalisering ødelagt noe? Gjenta visuell og funksjonell testing.
tre minisaker
Tilfelle 1 – Søker på feil sted. Ett team trodde listene satt fast og omarbeidet rullekoden i flere uker uten resultat. Da de tok profileren og matet dataene til AI, viste det seg at den virkelige flaskehalsen var bildene som ble lastet inn på nytt over nettverket med hver rad. Da den visuelle cachen ble lagt til, økte flyten fra 42 FPS til 60 FPS. Leksjon: måling unngår uker med meningsløs innsats.
Tilfelle 2 — Batterimonsterfunksjon. En oversettelsesapp la til live tekstoversettelse med kamera; Brukere klaget over at "telefonen ble varmet opp på 15 minutter og 30 % av batteriet var borte." Da AI ble konsultert, ble kameraet funnet å behandle 30 bilder per sekund; Da dette ble redusert til 5 bilder og resultatet ble oppdatert med noen bilder fra hverandre, sank batteriforbruket til en tredjedel, og kvaliteten var ikke merkbar. Leksjon: Still alltid AI med batteriøyet.
Tilfelle 3 - Sakte innsettende. En app åpnet på 4,5 sekunder; 20 % av brukerne avsluttet ved oppstart. Profilen viste at alt innledende arbeid (analyse, datainnlasting, modellforberedelse) ble gjort sekvensielt på hovedtråden. Med AI-forslaget har disse blitt utsatt og satt på baksiden; Åpningstiden ble redusert til 1,3 sekunder, og avbruddsraten ble halvert. Leksjon: gjør bare viktig arbeid i begynnelsen.
Svak forespørsel / Sterk forespørsel
Svak melding: "Appen min er treg, få fart på den."
Kraftig melding: "Rulling av liste blir sittende fast (jank) i Android-appen min. Profildata: bindImageView tar 28 ms på hver ramme, bilder lastes inn fra nettverket hver gang, det er ingen hurtigbuffer. Relatert kode: [RecyclerView-adapterkode]. Anbefal de 3 mest effektive optimaliseringene i rekkefølge av løsning og mulige bieffekter. Reduser ikke forventet gevinst for hvert bilde. kvalitet."
Kopierbare maler
Flaskehalsanalysemal: "Tolk følgende profildata og finn de 3 dyreste operasjonene: [profilutgang]. Foreslå mulig årsak og konkret optimalisering for hver. Gi størst effekt først."
Batterioptimaliseringsmal:"Denne funksjonen tapper batteriet raskt: [funksjon, f.eks. permanent plassering]. Gjør den batterivennlig:- Reduser prøvetakingsfrekvens- Begrensning i bakgrunnen- Batchbehandling- Kjør bare når det er nødvendig Sorter løsninger uten å forstyrre brukeropplevelsen. [kode]"
Oppstartshastighetsmal: "Fremskynd oppstart av applikasjoner. Ting som gjøres for øyeblikket ved oppstart: [liste]. Hvilken kan utsettes, settes i bakgrunnen eller lastes på latsiden? Skill de essensielle. [kode]"
AI-funksjonskostnadsmal: "Vurder ytelsen og batterikostnaden til funksjonen [på enhetsmodell / skysamtale] jeg la til. List opp beregningene jeg bør måle og strategier for å redusere kostnadene. [kode]"
Vanlige feil
- Optimalisering uten å måle. Den virkelige flaskehalsen er ofte på et annet sted enn forutsagt.
- Jager små gevinster. Sikt på den dyreste handlingen i stedet for forbedringen på 1 %.
- Ignorerer batterikostnadene til AI-funksjoner. Konstant løpende modell/kamera/nettverk spiser opp batteriet.
- Sliter opp hovedtråden. De tunge løftene med start og rulling bør ikke være på UI-tråden.
- Måles ikke på nytt etter optimalisering. Kontroller at forbedringen er reell og ikke ødelegger noe.
- Måling av ytelse i emulatoren. Faktisk enhetshastighet, temperatur og batteri er helt forskjellige.
Oppsummert
Ytelse og batteri er et spørsmål om mobilapp-overlevelse. Den gylne regel: mål først, optimaliser senere. Å gi profildata til AI gjør tolkningen raskere; Det umåtelige ønsket om å «speede opp» fører til blinde gjetninger. Sikt på den dyreste transaksjonen, ikke jag etter liten fortjeneste. AI-egenskapene som legges til i denne modulen er kraftige, men bærer batteri- og prosessorkostnader; Administrer denne kostnaden ved å redusere prøvetakingsfrekvensen, batching og kjøring bare når det er nødvendig. Mål igjen på den virkelige enheten etter hver optimalisering.
Søknadsoppgave
Importer en profil i en applikasjon (ditt eget prosjekt eller eksempel) eller lag en prøveprofilutgang og få den tolket av AI med "flaskehalsanalysemalen". Bruk den høyeste effektoptimaliseringen og mål igjen: sank antallet faktisk? Evaluer også en AI-funksjon du har lagt til i denne modulen (modell på enheten eller nettsky-anrop) når det gjelder batteri med "AI-funksjonskostnadsmalen" og bestem minst én batterivennlig innstilling.
sjekkliste
- [ ] Jeg fikk profil før optimalisering, jeg gjettet ikke
- [ ] Jeg siktet på den dyreste handelen, jeg strørte ikke på små fortjenester
- [ ] Jeg ga AI-profildataene i konkrete tall
- [ ] Jeg evaluerte batteri-/prosessorkostnadene for AI-funksjoner
- [ ] Jeg fjernet de tunge løftene fra hovedtråden
- [ ] Etter optimalisering målte jeg igjen på den virkelige enheten og sjekket regresjonen