Új hozzászólás Aktív témák

• #3593 Keeperv85 nagyúr air #3585

  Új Válasz 2013-03-31 08:24:23 #3593

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Keeperv85

  nagyúr

  válasz air #3585 üzenetére

  Oké, így már értem mi a helyzet. Csak nem kicsit "hamis" képet fest a progi.

  A AM.jar (AlarmManager) egy framework ősosztály. Ő felelős a teljes folyamatkontroll felett, tehát az egész AS (alarm services) felügyelete az ő dolga. Az összes intent, ami keletkezik az AM-re irányul futás időben. Ha egy Intent rendelkezik broadcasting lehetőséggel is, akkor az AM képes elindítani akkor is, ha korábban teljesen kikapcsolt állapotban volt, teljesen automatikusan.

  Mivel az összes futó folyamat (service) is itt kapja meg a státuszát (fut, nem fut, várakozik), így az AM mindig fut.

  Többnyire a végfelhasználó felé ebből annyi látszik pl., hogy a "Android rendszer" a fogyasztások 80%-a. Ez normális, nem hiba!

  Tehát nem túlfogyasztásról van szó, mint elszabadult folyamat! Csak a számítás miatt néz ki furcsán. Lássunk egy példát, hogy egyszerű legyen. A rendszer összefogyasztása mindig 100%-nak van számítva.

  Tehát, alap fogyasztás:

  Android OS: 42%
  Képernyő: 13%
  Cella készenlét: 15%
  Wi-Fi: 15%
  Opera Mobile: 7%
  Telefon tétlen: 4%
  Android rendszer: 4%

  Játszunk a Temple Run 2-vel:

  Képernyő: 52%
  Temple Run 2: 13%
  Cella készenlét: 12%
  Wi-Fi: 12%
  Android OS: 5%
  Opera Mobile: 3%
  Telefon tétlen: 2%
  Android rendszer: 1%

  Mit látunk? Azt hogy a rendszer fogyasztása értelem szerűen 100%-os most is, csak most az arányok eltolódtak a valós fogyasztó felé.

  (Akit zavarna az, hogy miért van két Android rendszer: ez egy HT.s processzor, az kavarja meg...)

Új hozzászólás Aktív témák