OutofMemoryError: размер растрового изображения превышает бюджет виртуальной машины (Android)

Я думаю, что это - то, что он говорит. Ваше изображение слишком велико, и, поскольку оно загружается в поток, когда память исчерпана, возникает исключение. Вопрос даже не в том, сколько памяти у вас в целом, а в том, сколько доступно вашей конкретной деятельности.

] В итоге я изменил размер растрового изображения, используя следующий код, который, похоже, решил проблему:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 8;
Bitmap preview_bitmap = BitmapFactory.decodeFile(mPathName, options);

Убедитесь, что ваше создание растрового изображения защищено от ошибок нехватки памяти! На большинстве платформ у Android не так много памяти, с которой можно поиграть, и она быстро расходуется с растровыми изображениями. Кроме того, не забудьте вручную переработать растровые изображения, насколько это возможно, я заметил, что сборка мусора может быть довольно медленной.

try{            
  Bitmap myFragileBitmap = Bitmap.createBitmap(500, 500, Bitmap.Config.ARGB_8888);
}
catch(IllegalArgumentException e){
  Log.e(TAG,"Illegal argument exception.");
}
catch(OutOfMemoryError e){
  Log.e(TAG,"Out of memory error :(");
}

inSampleSize - хороший намек. Но фиксированное значение часто не работает нормально, поскольку большие растровые изображения из файлов обычно являются пользовательскими файлами, которые могут варьироваться от крошечных эскизов до 12-мегапиксельных изображений с цифровой камеры.

Вот быстрая и грязная процедура загрузки. Я знаю, что есть возможности для улучшения, например, более приятный цикл кодирования, использование степени 2 для более быстрого декодирования и т. Д. Но это начало работы ...

public static Bitmap loadResizedBitmap( String filename, int width, int height, boolean exact ) {
    Bitmap bitmap = null;
    BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeFile( filename, options );
    if ( options.outHeight > 0 && options.outWidth > 0 ) {
        options.inJustDecodeBounds = false;
        options.inSampleSize = 2;
        while (    options.outWidth  / options.inSampleSize > width
                && options.outHeight / options.inSampleSize > height ) {
            options.inSampleSize++;
        }
        options.inSampleSize--;

        bitmap = BitmapFactory.decodeFile( filename, options );
        if ( bitmap != null && exact ) {
            bitmap = Bitmap.createScaledBitmap( bitmap, width, height, false );
        }
    }
    return bitmap;
}

Между прочим, в новых API также есть множество BitmapFactory.Option для подгонки изображения под разрешение экрана, но я не уверен, действительно ли они что-то упрощают. Использование android.util.DisplayMetrics.de density или просто фиксированного размера для меньшего потребления памяти, похоже, работает лучше imho.

Проверяли ли вы DDMS? С тем, с чем я столкнулся, это, вероятно, не размер изображений, потому что Android, похоже, довольно хорошо обрабатывает большие изображения.Если вы отследите кучу с помощью DDMS, вы можете обнаружить, что у вас много свободной памяти. Вы можете «расширить» свою кучу, добавив этот

static { @SuppressWarnings("unused")
byte dummy[] = new byte[ 8*1024*1024 ]; }    

в свой код, чтобы заставить кучу расширяться. Это может сделать это немного реже. К сожалению, за исключением того, что он утверждает, что не может выделить какое-то количество байтов. Скажите 1M. Если вы посмотрите на «свободную» строку, вы увидите, что самый большой блок составляет >> 1M. Там есть что-то странное, чего я не могу понять. Это не связано даже со скоростью перелистывания изображений. Я видел в каком-то треде, что вы можете назвать «переработку» или что-то в этом роде для растровых изображений. Я до сих пор не понимаю, почему это должно помочь, если размер кучи намного превышает взятый размер.