Android ART

[Jaiel]

Hi ich habe heute (endlich) Android 5.0.1 auf mein Note 4 bekommen. Jetzt läuft die ART und im LogCat kommen jetzt nciht mehr die normalen GC Meldungen wenn er meine Bitmaps aufräumt

Diese treten nun auch nciht mehr so häufig auf wie unter Dalvik


hier mal ein Ausschnitt

04-08 15:31:28.618: D/ResourcesManager(29761): creating new AssetManager and set to /data/app/de.jaielsoft.activities-2/base.apk
04-08 15:31:28.668: D/Activity(29761): performCreate Call debug elastic valuetrue
04-08 15:31:28.858: D/OpenGLRenderer(29761): Render dirty regions requested: true
04-08 15:31:28.948: I/Adreno(29761): EGLInit: QTI Build: 03/02/15, 210b328, I0829b9e471, LA.BF.2.1.05.00.00.203.165
04-08 15:31:28.968: I/OpenGLRenderer(29761): Initialized EGL, version 1.4
04-08 15:31:28.968: I/Adreno(29761): GetNativeFormatFromQctPixelFormat: Invalid qct format (611)
04-08 15:31:28.968: D/OpenGLRenderer(29761): Get maximum texture size. GL_MAX_TEXTURE_SIZE is 16384
04-08 15:31:28.968: D/OpenGLRenderer(29761): Enabling debug mode 0
04-08 15:31:29.408: I/Timeline(29761): Timeline: Activity_idle id: android.os.BinderProxy@3e084a45 time:20951971
04-08 15:31:29.688: I/Timeline(29761): Timeline: Activity_launch_request id:de.jaielsoft.activities time:20952254
04-08 15:31:29.878: D/Activity(29761): performCreate Call secproduct feature valuefalse
04-08 15:31:29.878: D/Activity(29761): performCreate Call debug elastic valuetrue
04-08 15:31:30.718: I/Timeline(29761): Timeline: Activity_idle id: android.os.BinderProxy@2d727cfd time:20953283
04-08 15:31:31.368: I/Timeline(29761): Timeline: Activity_launch_request id:de.jaielsoft.activities time:20953930

Was ich gemacht habe:
Habe mal zu testzwecken den backButton so gesetzt, dass sich 2 Activites immer aufrufen also Activity A ruft B wenn Backbutton auf und dann B wieder A bei Backbutton
Ich wollte sehen wie sich die Activites verhalten da ich in onCreate meine Bitmap alloziiere und den GC herausfordern

Nach ca. 10 sekunden kam auch dann endlich:

04-08 15:31:47.678: E/art(29761): Throwing OutOfMemoryError "Failed to allocate a 37748748 byte allocation with 16777120 free bytes and 20MB until OOM"

Kann mir jemand diese Meldungen erklären und ich würde gern wissen wie das jetzt ist mit dem ART ... wie unterscheidet er sich jetzt in der Ausführung gegenüber Dalvik?

Ich weiß nur dass jetzt einiges Vorkompiliert wird um performance zu erhöhen

Aber wie kommt es dass der GC jetzt weniger aufräumt oder "erzählt" er mir das jetzt nur nciht mehr so oft?

Der ursprüngliche Beitrag von 15:42 Uhr wurde um 15:53 Uhr ergänzt:

Und das hier: lese ich richtig?
256 MB an RAM?

Wieso läuft überhauopt der Speicher über? Ich habe Anfang gar nicht so sehr darüber nachgedacht hab es einfach angnommen dass es so kommt ohne eine Erklärung warum eigenltich!

04-08 15:48:31.548: I/art(439): Clamp target GC heap from 260MB to 256MB
04-08 15:48:31.658: I/art(439): Alloc partial concurrent mark sweep GC freed 16(672B) AllocSpace objects, 1(36MB) LOS objects, 6% free, 219MB/235MB, paused 387us total 11.961ms
04-08 15:48:31.718: I/art(439): WaitForGcToComplete blocked for 5.886ms for cause Alloc
04-08 15:48:31.738: I/art(439): Clamp target GC heap from 262MB to 256MB

Da ich jetzt zum Beispiel einen waitforgc...sehe frag ich mcih warum es also nciht wartet bis der GC fertig ist und dann alloziiert!

Der ursprüngliche Beitrag von 15:53 Uhr wurde um 16:05 Uhr ergänzt:

Und ncoh was:

04-08 15:58:44.698: E/AndroidRuntime(1620): java.lang.OutOfMemoryError: Failed to allocate a 14745612 byte allocation with 9118296 free bytes and 8MB until OOM

bedeutet das dass ich 9,12 MB freien speicher habe aber bei 8MB mehr wird OOM getriggert?

Oder ich hab 9,12 + 8MB zur Verfügung bevor OOM(ne oder sonst hätte er nciht getriggert)

 

[DevPatrick]

In dem Artikel der Android Devs ist das Problem sehr genau beschrieben: http://developer.android.com/training/displaying-bitmaps/index.html

 

[Jaiel]

Ich kenne diese Seite gut...
Mein Code ist schon angepasst es wird OOM getriggert bei einem Bild dass ich als Hintergrund verwende und dementsprechend hochskaliere aus einem 288x512 Bild
ein Bild dass so groß ist wie die Bildschirm Auflösung hat nun mal 1440x2560x4 Bytes bei meinem Note 4 das sind diese 14 MB eben
Da kann ich noch so effizient vorgehen diese 14 MB müssen alloziert werden anders gehts halt nicht

das Problem hier ist ja dass der GC meine zuvor allozierten Bilder in der vorangegangenen activity nicht schnell genug wegräumen oder diese sind noch referenziert sind
ich sollte den thread eigenhändig killen beim verlassen der activity und nicht auf den GC vertrauen der kommt wohl so schnell nicht nach die activity die zugehörige view und den thread zur view so schnell zu collected dass der Speicher überläuft

Jedenfalls triggert er das nach einer bestimmten zeit8-15 Sekunden wenn ich natürlich ganz schnell hintereinander die activities tausche

 

[Jaiel]

Hab das Problem jetzt so gelöst dass ich den MainThread der alle bitmaps hält kille und auf 0 setze zusätzlich ncih ein System.gc() einschiebe und erst danach startactivity() und finish() calle

Davor habe ich das in OnDestroy()
Also vetraut nciht darauf dass OnDestroy() schnell genug aufgerufen wird um Speicher frei zugeben lieber sofort nach einer best. Aktion