Naar content
Trending apps
  • Google Duo: videogesprekken van hoge kwaliteit

  • Gmail

  • Maps: Navigatie en OV

  • WhatsApp Messenger

  • Messenger: gratis sms'en en videobellen

Trending games
  • Fortnite

  • Minecraft Earth

  • Dr. Mario World

  • Harry Potter: Wizards Unite

  • Breaking Bad: Criminal Elements

Trending smartphones
  • OnePlus Nord N10 5G

  • POCO X3

  • Google Pixel 5

  • Google Pixel 4a

  • OnePlus Nord

Nieuwste tablets
  • Samsung Galaxy Tab S6

  • Samsung Galaxy Tab A 10.5

  • Samsung Galaxy Tab S4

  • Samsung Galaxy Tab S3 9.7

  • Asus Zenpad 3S 10

Wij werken momenteel aan een nieuw forum voor Androidworld. Het is daarom momenteel niet mogelijk om te reageren of nieuwe topics aan te maken.

Elmar

  • Lid sinds 15 november 2011
  • Berichten 10
  • Reputatie 0
  • #1
  • 6 januari 2012
  • 14:53

Ik heb de tutorial van Wouter met plezier gevolgd (klein stuk overgeslagen, omdat ik het database stuk voorlopig niet nodig heb).
Mijn eerste app gebouwd, een metronoom, om me te helpen bij een andere hobby. Ik weet dat er al veel zijn, maar ik wou gewoon een projektje om eens iets te zelf te maken.

Toen alles stabiel werkte, ging ik eens kijken wat het nu eigenlijk deed op de emulator en telefoon met CPU gebruik etc. Dus met ‘adb shell’ naar de android omgeving en met ps en top kijken wat er zoal gebeurd als de applicatie draait.
En toen schrok ik toch wel: die ‘simpele’ app gebruikte 24% CPU.

Dus in de code gaan optimaliseren. Waar ik vooral tegenaan liep: als je op het internet zoekt naar hoe je animaties of graphics gebruikt onder android, dan maken ze gebruik van een thread die in een constante loop de graphics creeerd. Door de app thread aan te passen dat hij dat alleen maar doet als er een update noodzakelijk is, en anders een wait uit te voeren van een paar miliseconden, heb je al een grote winst. Een alternatief voor veel applicaties zou ook kunnen zijn om de wait altijd uit te voeren. dat heb ik nu niet gedaan, omdat ik in pauze stand helemaal niets wil zien. Nu is het terug naar gemiddeld zo'n 1% als hij daadwerkelijk loopt. In pauze-stand is het 0.1%. En al ik hem ‘afsluit’ dan zie ik hem helemaal niet meer terug in top, terwijl hij nog wel in de proceslijst blijft staan.
Problemen met het oplopen van het aantal threads wat ik ook constateerde is van een andere orde: dat kan ik alleen oplossen door een rewrite.

Dus toen eens kijken hoe dat met andere apps zit. En dan schrik ik toch wel.
Apps die schaamteloos meer dan 90% CPU gebruiken! En dat soms ook blijven doen als je ze afsluit… Dat dit funest is voor de levensduur van je batterij zal ik niet hoeven uit te leggen…

Dus mijn gewetensvraag: als je een app ontwikkelt, doe je dan deze of vergelijkbare controles?

Bewerkt (24 april 2013 14:00)

botteaap

  • Lid sinds 02 augustus 2010
  • Berichten 29
  • Reputatie 0
  • #2
  • 7 januari 2012
  • 11:44

Ja, dat is iets waar je op moet letten, maar ik wil het wel een beetje nuanceren, want het hangt sterk van de app af.

Veel CPU gebruiken hoeft niet een groot probleem te zijn als er ook daadwerkelijk wat gebeurt in zo'n app. Games of andere apps die constant animeren zijn daar een voorbeeld van. Een best practice is de frame rate limiteren. Op “trage” telefoons zal zo'n app dan meer CPU pakken en op snellere telefoons draait de app op een maximale frame rate.

Belangrijker is wat je app doet als ie NIET zichtbaar is. Apps die niet zichtbaar zijn zouden in principe ook geen resources moeten gebruiken. Let wel dat Android het app proces cached dus die 0.1% CPU die je ziet is waarschijnlijk niets anders dan de tijd die het OS neemt om te checken of die app nog wat wil doen.

Bewerkt (24 april 2013 14:00)

Elmar

  • Lid sinds 15 november 2011
  • Berichten 10
  • Reputatie 0
  • #3
  • 10 februari 2012
  • 12:46

Die framerate heb ik maar eens getest. Want het kan best de best practice zijn, maar als ik naar de standaard code kijk die ik op het internet vind, dan is dat met een ongelimiteerde framerate. Het resultaat was een app die een sinus grafiek laat zien met 1 tot oneindig aantal frames per seconde. Als je dan met een adb shell kijkt naar het CPU gebruik, loopt het met deze app uiteen van 0% (1fps) tot 25% bij ongelimiteerd. Het aantal fps dat wordt gehaald is afhankelijk van de stand van het scherm (hij haalt minder FPS bij een horizontaal scherm, terwijl hij evenveel moet tekenen. Zal te maken hebben met transformatie van de image) en de grootte van de surfaceview.

De resulterende code is terug te vinden op: https://github.com/kolkmane/Public-Android-apps/tree/master/GraphCPUcheck, voor geinteresseerden.

Bewerkt (24 april 2013 14:13)

Reageer

We werken momenteel hard aan een nieuw forum voor Androidworld. Het is daarom helaas niet mogelijk om op dit topic te reageren.