Dual Core und RAM Limit

N

Neeldarax

Fortgeschrittenes Mitglied
32
Hallo zusammen,

ich habe gerad eine was gesehen, was ich mir nicht ganz erklären kann.

Meine APP beansprucht 50% der CPU last vom S2 (dual core handy). Wieso kann macht der zweiter Prozessor nichts? Gibt es da ne Einstellung vom Android? Kann mir jemand dazu was sagen?

Und das zweite ist, wenn ich es schaffe ca. 60MB RAM zu belegen, verursachen bestimmte Aktionen, die im normalen Lauf keine Probleme verursachen, eine Meldung vom System "Beenden erzwingen oder Warten". (da ist mir auch schon ma meine App um die Ohren geflogen)
Da ist bestimmt der GC mit cleanen schuld. Kann man das Limit bzw. den zugeordneten Speicher mit Parameter setzten? (so kenn ich das für Eclipse start)

Ich kann die CPU-Last und den Speicher nicht mit wenig Aufwand reduzieren, bequemer wäre es das Limit des Smartphones auszureizen. Um haltbarkeit des Akkus kümmere ich mich, wenns soweit kommt *g

Danke für jeden, der sich schon ma damit auseinander gesetzt hat und uns einweiht ;)

regards


Wenn die APP einem um die Ohrenfliegt:
Code: 
09-15 16:07:30.814: ERROR/ActivityManager(2696): ANR in mein.package (mein.package/mein.package.Maske)
09-15 16:07:30.814: ERROR/ActivityManager(2696): Reason: keyDispatchingTimedOut
09-15 16:07:30.814: ERROR/ActivityManager(2696): Load: 2.85 / 2.14 / 1.56
09-15 16:07:30.814: ERROR/ActivityManager(2696): CPU usage from 19598ms to 0ms ago:
09-15 16:07:30.814: ERROR/ActivityManager(2696):   1.8% 9502/mein.package: 0.5% user + 1.2% kernel / faults: 23 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   1% 2696/system_server: 0.3% user + 0.7% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 6889/com.sec.android.widgetapp.buddiesnow: 0% user + 0% kernel / faults: 55 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.1% 514/com.sec.android.app.controlpanel: 0.1% user + 0% kernel / faults: 66 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.3% 1308/cm3663_light_wq: 0% user + 0.3% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.2% 2592/adbd: 0% user + 0.2% kernel / faults: 36 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.1% 2803/com.sec.android.widgetapp.digitalclock: 0.1% user + 0% kernel / faults: 49 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.1% 2823/com.android.systemui: 0.1% user + 0% kernel / faults: 1 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 9/events/0: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0.1% 524/kondemand/0: 0% user + 0.1% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 10270/wpa_supplicant: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 336/bdi-default: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 1267/file-storage: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 1293/irq/328-mxt224_: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 1445/mmcqd: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 2577/drexe: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 5114/logcat: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 8479/com.sec.android.app.FileTransferServer: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   0% 10266/dhd_dpc: 0% user + 0% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696): 4.5% TOTAL: 1.8% user + 2.6% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696): CPU usage from 376ms to 889ms later:
09-15 16:07:30.814: ERROR/ActivityManager(2696):   5.7% 2696/system_server: 1.9% user + 3.8% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):     3.8% 2763/InputDispatcher: 0% user + 3.8% kernel
09-15 16:07:30.814: ERROR/ActivityManager(2696):   1.6% 9502/mein.package: 1.6% user + 0% kernel / faults: 1 minor
09-15 16:07:30.814: ERROR/ActivityManager(2696): 1.9% TOTAL: 0% user + 1.9% kernel
Wenn der GC Überstunden schiebt:
Code: 
09-15 16:04:42.504: DEBUG/dalvikvm(8541): GC_FOR_MALLOC freed 1613K, 43% free 12007K/20743K, external 38169K/40217K, paused 43ms
09-15 16:04:42.619: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 2014K, 42% free 12033K/20743K, external 38071K/40119K, paused 2ms+3ms
09-15 16:04:42.749: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 694K, 36% free 13338K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:42.779: DEBUG/dalvikvm(8541): GC_FOR_MALLOC freed 2404K, 38% free 12915K/20743K, external 38071K/40119K, paused 23ms
09-15 16:04:42.824: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1697K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:42.854: DEBUG/dalvikvm(8541): GC_FOR_MALLOC freed 2263K, 38% free 12915K/20743K, external 38071K/40119K, paused 21ms
09-15 16:04:42.899: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1697K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:42.949: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:42.994: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.044: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.084: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+3ms
09-15 16:04:43.134: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.184: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.234: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.284: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.334: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.384: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.434: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.484: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.524: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.574: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.624: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+3ms
09-15 16:04:43.669: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.709: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.754: ERROR/lights(2696): write_int: path /sys/devices/virtual/misc/melfas_touchkey/brightness, value 2
09-15 16:04:43.754: WARN/PowerManagerService(2696): Timer 0x7->0x3|0x0
09-15 16:04:43.754: INFO/PowerManagerService(2696): Ulight 7->3|0
09-15 16:04:43.754: DEBUG/PowerManagerService(2696): setLightBrightness : mButtonLight : 0
09-15 16:04:43.759: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.814: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.859: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+2ms
09-15 16:04:43.899: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.949: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:43.999: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+3ms
09-15 16:04:44.039: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:44.089: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 1ms+3ms
09-15 16:04:44.139: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:44.179: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:44.229: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1980K, 37% free 13198K/20743K, external 38071K/40119K, paused 2ms+2ms
09-15 16:04:44.289: DEBUG/dalvikvm(8541): GC_FOR_MALLOC freed 2183K, 39% free 12755K/20743K, external 38071K/40119K, paused 26ms
09-15 16:04:44.354: DEBUG/dalvikvm(8541): GC_CONCURRENT freed 1145K, 35% free 13611K/20743K, external 38071K/40119K, paused 2ms+3ms
 
Bei Samsung Geräten läuft der gc von Haus aus dauernd

Ist am sgs 2 so und auch am galaxy Tag 10.1. Touchwiz vielleicht

Bzgl Nr: hat du überall threads eingebaut?
 
swordi schrieb:
Bzgl Nr: hat du überall threads eingebaut?
Zum Vergrößern anklicken....
Will heißen: Java nutzt prinzipiell nur eine CPU bzw. Kern, nur wenn du Threads verwendest werden diese auf die Kerne aufgeteilt :)
 
Hallo ihr beiden,

also es sind paar Threads..

(Anzahl variert, das ist ein Abbild meines derzeitigen Zustandes)
Code: 
DalvikVM[localhost:8608]    
    Thread [<3> main] (Running)    
    Thread [<27> Thread-3902] (Running)    
    Thread [<43> Timer-124] (Running)    
    Thread [<39> Timer-123] (Running)    
    Thread [<37> Timer-122] (Running)    
    Thread [<33> Timer-121] (Running)    
    Thread [<35> Timer-38] (Running)    
    Thread [<49> Timer-37] (Running)    
    Thread [<45> Timer-36] (Running)    
    Thread [<41> Timer-14] (Running)    
    Thread [<29> Timer-10] (Running)    
    Thread [<21> Timer-9] (Running)    
    Thread [<25> Timer-4] (Running)    
    Thread [<23> Timer-3] (Running)    
    Thread [<19> Timer-2] (Running)    
    Thread [<17> Timer-1] (Running)    
    Thread [<15> Timer-0] (Running)    
    Thread [<13> Binder Thread #2] (Running)    
    Thread [<11> Binder Thread #1] (Running)
Wäre aber denkbar, dass im Moment der Volllast, nur ein Thread arbeitet. Hier werden Aufgaben aus der Liste/Warteschlange ausgelesen und abgearbeitet.

Das Java nur ein Kern benutzt kenn ich noch aus Java 5/1.5 Zeiten *g
Wenn das immer noch der Fall ist, dann kann ich die 50% CPU-Last verstehen.

Aber kommen wir zum RAM. War gerade bei 77Mb und Android hat mir meine APP beendet, als ich es "minimiert" habe :ohmy: (jaja.. wenn Android Speicher brauch/will/what ever, beendet APPs im Hintergrund, um Speicher freizumachen...)

Optionen, Parameter oder Flags für RAM Zuordnung wären jetzt dann noch Interessant. Kennt sich da wer aus?

regards

edit: https://www.android-hilfe.de/forum/...4/dalivk-vm-heapsize-hoeher-setzen.57042.html
 
Zuletzt bearbeitet:
es gibt die Methode setPersistent() in der Klasse Activity, sollte jedoch mit Vorsicht benutzt werden.
 
Zum "RAM":

Jede App im Android hat einen "virtuellen" Speicher von 16MB (nicht mehr nicht weniger) Alles darüber hinaus führt zu OutOfMemoryError's.

Wenn deine App in "onPause()" geht und das Gerät speicher braucht, dann wirft das OS den GarbageCollector an und der Speicher deiner App wird freigegeben.

[Edit:] Die 16 MB können in manchen ROM's vergrößert werden, was allerdings einen Entwickler nicht tun sollte, da sonst die "Breite Masse" ausgeschlossen wird, welche nur die std. 16MB haben
 
  • Danke
Reaktionen: Neeldarax
der heapspace ist nicht bei jedem Android Gerät auf 16mb eingestellt.
Samsung z.B. stellt da stets viel höhere Werte ein.
Zur Not kannste noch nativ Speicher allokieren, da gibts dann keine Begrenzung pro App.
 
aber weniger als 16mb hat kein hersteller.

deshalb sollte man dann wohl im moment von maximal 16 mb ausgehen
 
Hallo zusammen,

also setPersistent() hab auf die schnelle nicht gefunden, aber da haste schon Recht Fr4gg0r, nur mit Vorsicht zu benutzen. Damit hebelt man das Androidsystem aus, das reguliert sich selbst und es ist auch gut so.

Das Android bei "onPause()" die APP vom GC gekillt wird, wenn diese den dalivk.vm.heapsize Wert erreicht bzw. übersteigt ist eig. auch logisch. Man müsste wohl Arbeit in die Bereinigung reinstecken, spätestens beim onPause aufruf.

Das beim Überstreiten der heapsize ein OutOfMemoryError auftritt, muss ich widerlegen!

Wie ich schon geschrieben habe, erreichte meine APP fast 80MB, der heapsize ist beim Atrix und S2 auf 30MB eingestellt. (Datei zu finden unter /system/build.prop)
Und da kommen wir wieder zu onPause und APP wird vom GC beendet.

Das Puzzel fügt sich ;)

Danke für eure Anregungen.

regards

EDIT:
Aber sowas wie ne Grenze scheint es doch zu geben *g
Code: 
09-21 14:03:33.085: ERROR/dalvikvm-heap(10386): 20736-byte external allocation too large for this process.
09-21 14:03:33.085: ERROR/GraphicsJNI(10386): VM won't let us allocate 20736 bytes
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

M
Zugriff auf Verzeichnisse und Dateien
  • MikelKatzengreis
Antworten
5
Aufrufe
132
swa00
swa00
Laser5001
TelecomManager.EndCall abgekündigt... und dann?
  • Laser5001
Antworten
3
Aufrufe
650
swa00
swa00
W
App Kopie erstellen und zweimal nutzen
  • WhiteFlake
Antworten
2
Aufrufe
744
rene3006
R
Zurück
Oben Unten