Winst:
- Door eerst een profiel te maken en het echte knelpunt te meten, optimalisatie te maken op basis van data in plaats van giswerk en de profieluitvoer te laten interpreteren door kunstmatige intelligentie
- Mogelijkheid om de duurste operatie te targeten in termen van opstarttijd, vloeiendheid, geheugen en batterij en het zware werk uit de hoofdlijn te verwijderen
- Mogelijkheid om de batterij- en processorkosten van AI-mogelijkheden zoals on-device-modellen en cloudbellen te beheren door middel van sampling en batchverwerking
Mobiele gebruikers zijn ongeduldig. Als de app langzaam opent, blijft hangen tijdens het scrollen of de batterij snel leegraakt, verwijdert de gebruiker deze en geeft deze een sterbeoordeling in de winkel. Prestaties en batterij-efficiëntie zijn een kwestie van overleven van een mobiele app; Het heeft een directe invloed op zowel de gebruikerstevredenheid als de winkelrangschikking. AI is een krachtig hulpmiddel bij het opsporen van prestatieknelpunten (knelpunten), het interpreteren van meetresultaten en het aanbevelen van optimalisaties. Maar de gouden regel blijft: eerst meten, later optimaliseren. In deze unit leren we prestatie- en batterijproblemen op een datagebaseerde manier op te lossen met AI. Een bijzonder belangrijke kwestie is het beheren van de impact op de batterij en de prestaties van de AI-mogelijkheden die we in eerdere eenheden hebben toegevoegd (model op het apparaat, cloudbellen).
Optimaliseren zonder meten
De grootste fout van een onervaren ontwikkelaar is voorspellende optimalisatie: tijd verspillen door te zeggen "deze moet langzaam zijn". Het echte knelpunt zit bijna altijd op een onverwachte plek. Dus eerst wordt het profiel gemaakt (profilering – meten welk deel van de applicatie hoeveel tijd/geheugen/batterij verbruikt). Android Studio Profiler en Xcode Instruments zijn voor deze taak. Het geven van meetgegevens aan AI versnelt de interpretatie; Maar zonder te meten betekent het vertellen aan AI: “Mijn applicatie is langzaam, versnel hem” dat je blindelings voorspellingen doet.
De vier belangrijkste prestatie-assen zijn:
as
symptoom
typische oorzaak
Begintijd
Applicatie wordt laat geopend
Zwaar werk aan de hoofddraad
Vloeiendheid (jank)
Scrollen loopt vast
Lange verwerkingstijd, onnodig opnieuw tekenen in UI-thread
geheugen
zwelling, instorting
Lekkage, grote afbeelding, ongecontroleerde cache
batterij/warmte
snelle ejaculatie
Continue locatie, netwerk, sensor, achtergrondtaak
Tip: Wanneer u de AI vraagt naar een prestatieprobleem, geeft u de profieluitvoer op (welke functie duurt hoe lang, geheugengrafiek). Harde data als ‘Die functie duurt 30 ms per frame’ zorgen ervoor dat de AI zich kan concentreren op het echte knelpunt; Een subjectieve uitdrukking als 'langzaam' levert een algemeen en nutteloos antwoord op.
Batterijkosten van AI-vaardigheden
De AI-functies die we in deze module hebben toegevoegd zijn krachtig, maar ze zijn niet gratis. Het extraheren van een model op het apparaat belast de processor en de batterij; Een constant actieve beeldherkenning (bijvoorbeeld de camera die elk frame verwerkt) zal de telefoon binnen enkele minuten opwarmen en de batterij leegmaken. Cloud AI-oproepen vreten daarentegen de batterij op door de netwerkradio (de antenne die gegevens verzendt en ontvangt) de hele tijd aan te laten staan. Oplossingen: voer het on-device-model alleen uit wanneer dat nodig is, bemonster de camera een paar keer per seconde in plaats van elk frame, verzend batchgewijs cloudverzoeken, doe het zware werk terwijl het apparaat wordt opgeladen of inactief is.
Let op: een constant actieve AI-functie (live vertaling, continue objectherkenning) kan de batterij zeer snel leegmaken, het apparaat opwarmen en mogelijk door het systeem worden gesmoord. Een functie waardoor de gebruiker het gevoel krijgt dat deze kosten zijn verwijderd. Ik vraag AI altijd: "Hoe maak ik deze functie batterijvriendelijk?" Stel ook de vraag.
Stappen van optimalisatie
- Maatregel. Vind het echte knelpunt met Profiler; raad het niet.
- Kies het grootste probleem. Ga niet voor een verbetering van 1%; Streef naar de duurste transactie.
- Vraag AI met data. Vraag optimalisatiesuggestie aan met profieluitvoer + relevante code.
- Toepassen en opnieuw meten. Is de verbetering reëel? Is het aantal gedaald?
- Regressiecontrole. Heeft optimalisatie iets opgeleverd? Herhaal visuele en functionele tests.
drie minikoffers
Geval 1 — Zoeken op de verkeerde plaats. Eén team dacht dat de lijsten vastzaten en herwerkte de scrollcode wekenlang zonder resultaat. Toen ze de profiler gebruikten en de gegevens aan de AI voerden, bleek dat het echte knelpunt was dat de afbeeldingen bij elke rij opnieuw over het netwerk werden geladen. Toen de visuele cache werd toegevoegd, nam de vloeiendheid toe van 42 FPS naar 60 FPS. Les: meten voorkomt wekenlange nutteloze inspanningen.
Geval 2 – Batterijmonsterfunctie. Een vertaalapp heeft live tekstvertaling met camera toegevoegd; Gebruikers klaagden dat "de telefoon binnen 15 minuten warm werd en dat 30% van de batterij leeg was." Toen de AI werd geraadpleegd, bleek de camera 30 beelden per seconde te verwerken; Toen dit werd teruggebracht tot 5 frames en het resultaat met een paar frames ertussen werd bijgewerkt, daalde het batterijverbruik tot een derde en was de kwaliteit niet merkbaar. Les: Stel de AI altijd in met het batterijoog.
Geval 3 – Langzaam begin. Een app werd binnen 4,5 seconden geopend; 20% van de gebruikers verliet het programma bij het opstarten. Uit het profiel bleek dat al het initiële werk (analyse, laden van gegevens, modelvoorbereiding) opeenvolgend op de hoofdthread werd uitgevoerd. Met het AI-voorstel zijn deze uitgesteld en op een laag pitje gezet; De openingstijd werd teruggebracht tot 1,3 seconden en het verlatingspercentage werd gehalveerd. Les: doe in het begin alleen het essentiële werk.
Zwakke prompt/sterke prompt
Zwakke prompt: "Mijn app is traag, versnel hem."
Krachtige prompt: "Het scrollen door de lijst loopt vast (jank) in mijn Android-applicatie. Profiler-gegevens: bindImageView duurt 28 ms op elk frame, afbeeldingen worden elke keer van het netwerk geladen, er is geen cache. Gerelateerde code: [RecyclerView-adaptercode]. Beveel de drie meest effectieve optimalisaties aan in volgorde van impact. Geef voor elk de verwachte winst en mogelijke bijwerkingen aan. Geef prioriteit aan oplossingen die de beeldkwaliteit niet verminderen."
Kopieerbare sjablonen
Sjabloon voor knelpuntenanalyse: "Interpreteer de volgende profielgegevens en vind de drie duurste bewerkingen: [profileruitvoer]. Stel voor elk een mogelijke oorzaak en concrete optimalisatie voor. Geef eerst de hoogste impact."
Sjabloon voor batterijoptimalisatie: "Deze functie zorgt ervoor dat de batterij snel leeg raakt: [functie, bijvoorbeeld een permanente locatie]. Maak het batterijvriendelijk: - Verlaag de bemonsteringsfrequentie - Beperking op de achtergrond - Batchverwerking - Alleen uitvoeren wanneer dat nodig is Sorteer oplossingen zonder de gebruikerservaring te verstoren. [code]"
Sjabloon voor opstartsnelheid: "Versnel het opstarten van applicaties. Dingen die momenteel worden gedaan bij het opstarten: [lijst]. Welke kunnen worden uitgesteld, op de achtergrond gezet of lui geladen? Scheid de essentiële. [code]"
Sjabloon voor kosten van AI-functies: "Evalueer de prestaties en batterijkosten van de functie [model op apparaat / cloudoproep] die ik heb toegevoegd. Maak een lijst van de statistieken die ik moet meten en strategieën om de kosten te verlagen. [code]"
Veel voorkomende fouten
- Optimaliseren zonder meten. Het echte knelpunt zit vaak op een andere locatie dan voorspeld.
- Het najagen van kleine winsten. Streef naar de duurste actie in plaats van naar een verbetering van 1%.
- Het negeren van de batterijkosten van AI-functies. Als het model/camera/netwerk voortdurend actief is, slurpt het de batterij op.
- De rode draad vermoeien. Het zware werk van starten en scrollen mag niet op de UI-thread plaatsvinden.
- Niet opnieuw meten na optimalisatie. Controleer of de verbetering reëel is en niets kapot maakt.
- Prestaties meten in de emulator. De werkelijke apparaatsnelheid, temperatuur en batterij zijn compleet verschillend.
Samengevat
Prestaties en batterij zijn een kwestie van overleven van mobiele apps. De gouden regel: eerst meten, later optimaliseren. Het geven van profielgegevens aan de AI versnelt de interpretatie; Het onmetelijke verlangen om te "versnellen" leidt tot blinde gissingen. Streef naar de duurste transactie, jaag geen kleine winsten na. De AI-mogelijkheden die in deze module zijn toegevoegd, zijn krachtig maar brengen batterij- en processorkosten met zich mee; Beheer deze kosten door de bemonsteringsfrequentie en batchverwerking te verminderen en deze alleen uit te voeren wanneer dat nodig is. Meet na elke optimalisatie opnieuw op het echte apparaat.
Applicatie taak
Importeer een profiel in een applicatie (uw eigen project of voorbeeld) of maak een voorbeeldprofieluitvoer en laat deze door de AI interpreteren met het "Knelpuntanalysesjabloon". Pas de hoogste impactoptimalisatie toe en meet opnieuw: is het aantal daadwerkelijk gedaald? Evalueer ook een AI-functie die u in deze module hebt toegevoegd (model op het apparaat of cloudoproep) in termen van batterij met de "AI-functiekostensjabloon" en bepaal ten minste één batterijvriendelijke instelling.
controlelijst
- [ ] Ik heb een profiel gekregen vóór de optimalisatie, ik had het niet geraden
- [ ] Ik mikte op de duurste handel, ik strooide niet met kleine winsten
- [ ] Ik heb de AI-profielgegevens in concrete cijfers gegeven
- [ ] Ik heb de batterij-/processorkosten van AI-functies geëvalueerd
- [ ] Ik heb het zware werk uit de hoofddraad gehaald
- [ ] Na de optimalisatie heb ik opnieuw gemeten op het echte apparaat en de regressie gecontroleerd