2010-08-23 11 views
2

Je vais avoir du mal à comprendre pourquoi ce codeallocation bitmap Android bizarreries

 
public class BitmapAllocTest extends Activity { 
    /** Called when the activity is first created. */ 
    @Override 
    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState);  
     byte[] b = new byte[20 * 1000 * 1000]; 
     b = null; 
     Bitmap.createBitmap(2500, 2000, Bitmap.Config.ARGB_8888); 
    } 
} 

lance une exception OutOfMemory sur un dispositif avec une limite de tas de 24MB. Si je commente l'une ou l'autre des allocations, cela fonctionne bien. J'avais l'impression que java vm essaierait de ramasser les ordures avant de lancer les exceptions OutOfMemory.

Je suppose qu'il s'agit d'android allouer les bitmaps sur le tas natif.

Répondre

0
J'avais l'impression que java vm tenterait de ramasser les ordures avant de lancer des exceptions OutOfMemory.

Vous devez déclencher le CPG par vous-même et réessayer. Je devais le faire récemment et ne pouvais pas trouver une autre façon de le faire.

+0

J'ai essayé d'appeler votre suggestion System.gc() avant l'attribution bitmap, également essayé attraper l'erreur, appelant gc(), puis essayer de répartir à nouveau le bitmap. Je reçois toujours l'erreur OOM cependant. :( – Viktor

+0

pouvez-vous me montrer comment vous appelez et retenter – WarrenFaith

+0

octet [] b = new byte [20 * 1000 * 1000];? b = null; System.gc(); try { Bitmap.createBitmap (2500, 2000, Bitmap.Config.ARGB_8888); } catch (e OutOfMemoryError) { System.gc(); Bitmap.createBitmap (2500, 2000, Bitmap.Config.ARGB_8888);} – Viktor

1

J'ai posté ceci sur la question suivi et a obtenu cette réponse:

Il y a quelques choses qui se passent.

La VM sur les périphériques plus anciens utilise collection conservative. La plupart (mais pas tous) les périphériques exécutant> = utiliser GC de type précis, mais aucun d'entre eux encore avoir GC direct précis.

Ce que cela signifie est, le fait que vous ensemble « b = null » ne garantit pas que toutes les copies de cette référence sont partis - une copie pourrait encore être assis dans un registre quelque part, et sans détection de vivacité le GC ne peut pas savoir qu'il ne sera plus jamais utilisé. Il est également parfaitement légal que le compilateur rejette l'affectation "b = null" car vous ne regardez plus jamais "b" .

Les données de pixel bitmap utilisent le mécanisme "allocation externe" magique plutôt que que l'allocateur de tas habituel. Parfois, vous obtenez des interactions désagréables.

Nous travaillons sur la résolution de toutes ces questions .

Lien: http://code.google.com/p/android/issues/detail?id=10821