Android выбрасывает ошибку памяти в приложении

Я делаю приложение для Android, которое может передавать видео с сервера на мобильный телефон Android. У меня есть потоковая передача изображений и работа, но через 15 секунд приложение вылетает. Мне удалось отследить это до Throwing OutOfMemoryError. Я попытался переработать растровое изображение после того, как передал ему интерфейс, чтобы передать его потоку для его отображения, но получаю сообщение об ошибке «невозможно повторно использовать переработанное растровое изображение». Я не уверен, как исправить эту ошибку, или даже если наклонить ее, это исправит.

                    int read_count = 1;
                    long start_time = System.currentTimeMillis();
                    long timeout = 10000;
                    boolean timed_out = false;

                    byte[] data = new byte[size + 1];
                    while (read_count < size && !timed_out)
                    {
                        int len = in.read(data, read_count, size - read_count);
                        read_count += len;
                        timed_out = (System.currentTimeMillis() - start_time) >= timeout;
                    }
                    data[0] = (byte)0x89;

                    if (read_count == size)
                    {
                        final boolean is_left = (side == 0);
                        final byte[] tmp = data;
                        Bitmap Image_data = null;
                        System.out.println(tmp.length);
                        if (Listener != null)
                        {
                            Image_data = BitmapFactory.decodeByteArray(tmp, 0, tmp.length);

                            Listener.OnNewImageListenerBitmap(Image_data, is_left);

                          // this is where i tried recycling it//
                        }

                    }

Мне удалось отследить ошибку памяти в строке «byte [] data = new byte [size + 1];» но после исследования у меня сложилось впечатление, что это связано с растровым изображением.

У кого-нибудь еще была проблема с этой проблемой и удалось ли ее исправить? любая помощь по этому поводу была бы потрясающей: D

Спасибо

ВЫВОД:

02-10 15:22:15.488  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/System.out﹕ 373348
02-10 15:22:16.655  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/System.out﹕ 373348
02-10 15:22:17.371  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/System.out﹕ 373348
02-10 15:22:18.827  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/System.out﹕ 373348
02-10 15:22:29.167  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/art﹕ Alloc sticky concurrent mark sweep GC freed 37627(1380KB) AllocSpace objects, 0(0B) LOS objects, 6% free, 114MB/122MB, paused 905us total 7.018ms
02-10 15:22:29.178  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/art﹕ Alloc partial concurrent mark sweep GC freed 110(3KB) AllocSpace objects, 2(92MB) LOS objects, 40% free, 22MB/36MB, paused 1.112ms total 11.404ms
02-10 15:22:29.202  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/art﹕ Alloc concurrent mark sweep GC freed 141(17KB) AllocSpace objects, 0(0B) LOS objects, 40% free, 22MB/36MB, paused 825us total 23.893ms
02-10 15:22:29.202  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/art﹕ Forcing collection of SoftReferences for 1GB allocation
02-10 15:22:29.223  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/art﹕ Alloc concurrent mark sweep GC freed 67(2520B) AllocSpace objects, 0(0B) LOS objects, 39% free, 22MB/36MB, paused 2.473ms total 18.440ms
02-10 15:22:29.223  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt E/art﹕ Throwing OutOfMemoryError "Failed to allocate a 1801149826 byte allocation with 15419532 free bytes and 233MB until OOM"
02-10 15:22:29.223  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt E/AndroidRuntime﹕ FATAL EXCEPTION: Thread-1308
    Process: com.google.vrtoolkit.cardboard.samples.treasurehunt, PID: 32097
    java.lang.OutOfMemoryError: Failed to allocate a 1801149826 byte allocation with 15419532 free bytes and 233MB until OOM
            at Socket.ClientThread.run(ClientThread.java:130)
02-10 15:22:29.833  32097-32121/com.google.vrtoolkit.cardboard.samples.treasurehunt I/MainActivity﹕ onRendererShutdown
02-10 15:22:32.793  32097-32122/com.google.vrtoolkit.cardboard.samples.treasurehunt I/Process﹕ Sending signal. PID: 32097 SIG: 9


person user3774031    schedule 10.02.2015    source источник
comment
comment
Я попытался посмотреть на это и использовать решение, и в моем случае это не сработало   -  person user3774031    schedule 10.02.2015


Ответы (1)


Была аналогичная проблема на Android 5. Переместите изображения в / drawable-nodpi вместо / drawable.

РЕДАКТИРОВАТЬ: Я думаю, что это как-то связано с автоматическим масштабированием изображения с использованием текущего DPI устройства. Например, если у вас есть большое изображение только в / drawable-mdpi, но ваше устройство xxxhdpi, тогда Android берет изображение, доступное в mdpi, и пытается масштабировать его, чтобы соответствовать xxxhdpi, что может занимать слишком много памяти. Но изображения из / drawable-nodpi не масштабируются, они используются как есть.

person Borzh    schedule 23.04.2015
comment
Исправлена ​​проблема для меня +1. - person Arun; 11.10.2015
comment
Спасибо .. это работает и для меня .. не могли бы вы объяснить мне, как это работает ?? - person Anil Chandra Varma Dandu; 05.01.2016
comment
Если вы правы, это означает, что изображения в каталоге drawable/ тоже масштабируются, верно? Но как в этом случае Android вычисляет коэффициент масштабирования (ведь здесь нет плотности)? - person flawyte; 18.05.2016
comment
Да, drawable/ масштабируется. Цитата из здесь: the resources in drawable/ are the default drawable resources. The system assumes that default resources are designed for the baseline screen size and density, which is a normal screen size and a medium-density. As such, the system scales default density resources up for high-density screens and down for low-density screens, as appropriate. - person Borzh; 18.05.2016