Из памяти ошибка при загрузке изображений в Glide

Это не точное решение вашей проблемы, но вам нужно иметь это в виду при загрузке изображений в списке с помощью Glide.

основная угрожающая часть вашей проблемы-это размер изображения. Изображение вы получаете почти 1Мб каждого! Который на самом деле слишком велик для отображения их в список, содержащий более 300 элементов. Поэтому, если вы также делаете серверную сторону, всегда рекомендуется иметь изображения в нескольких разных размерах.

например, в случае показывая список друзей вместе с их фотографиями профиля, я бы предложил вам сначала получить весь список с сервера. Затем извлеките все изображения профиля и сохраните их локально. Затем заполните ListView. И самая важная часть-при загрузке профильного изображения пользователя на сервер, после его загрузки сервер должен сохранить несколько его размеров, например, версию с низким, средним и высоким разрешением. Так что во время обслуживания url-адреса изображения профиля для ListView сервер может обеспечить изображения с низким разрешением, поскольку они будут использоваться, скорее всего, для эскизов.

используя RecyclerView вместо ListView Это тоже хороший вызов. Но это не решит проблему, которую вы здесь, когда вы находитесь в устройстве низкого класса.

OMM не имеет ничего общего с можно решить программно. Вам нужно изменить размер изображения до более низкой версии res.

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

удачи.

использовать recyclerView вместо ListView. Это многоразовый один элемент для рендеринга элементов. Я использую glide С recyclerView где я загружаю обои с более чем 100 элементами.

в ListView каждый раз, когда вы создаете представление, если у вас есть 100+ view, и он создаст 100+ views, где, как и в recyclerview, он создает, сколько видимых элементов есть на экране +2.

использование Glide не гарантирует no Out of Memory ошибки, вам нужно использовать несколько небольших шагов, чтобы уменьшить вероятность не получить OOM's.

Шаг 1: понять кэширование механизм в Glide

Шаг 2: Я предпочитаю загружать thumbnails в recyclerview

Glide  
    .with( context )
    .load( UsageExampleGifAndVideos.gifUrl )
    .thumbnail( 0.1f )
    .into( imageView2 );

Не забудьте всегда запрашивать изображение небольшого размера, если больше или HD-изображения не требуется.

1. убедитесь, что ImageView имеет match_parent или фиксированный dp как размеры wrap_content в качестве параметров делает скольжение полном разрешении загружать растровые изображения.
2. .placeholder () показывает изображение вместо пустого пространства при загрузке большого растрового изображения
3. .thumbnail (float) быстро загружает уменьшенную версию, в то время как большее изображение загружается в фоновом режиме
4. и посмотрите вокруг вопросы Глайд, может быть, вы найдете что-то полезное.

я столкнулся с аналогичной проблемой . Я делюсь тем, как я ее решил . Создайте папку с именем drawable-nodpi положить golive_load_image и golive_cancel_im‌​age файл в эту папку и удалите эти два файла изображения из другого места, например drawable-ldpi,drawable-hdpi etc (если у вас есть). И добавить skipMemoryCache( true )

     Glide.with(context).load(rowItem.getPosteduserpostimage())
                            .skipMemoryCache( true )
                            .placeholder(R.drawable.golive_load_image).error(R.drawable.golive_cancel_image)
                            .override(600, 200)
                            .into(holder.ivPostedImage);

причина в том, что при прокрутке glide продолжает выполнять процесс изображения, даже связанные представления удаляются из списка. Добавьте этот код в onScrollStateChanged вашего listview.

if (view.getContext() != null) {
        switch (scrollState) {
            case SCROLL_STATE_IDLE:
                Glide.with(view.getContext()).resumeRequests();
                break;
            case SCROLL_STATE_TOUCH_SCROLL:
            case SCROLL_STATE_FLING:
                Glide.with(view.getContext()).pauseRequests();
                break;
        }
    }

• ваши изображения не должны быть слишком большими ( если они есть, использовать .thumbnail(...f) )
• использовать .skipMemoryCache(true) Если вы не заставляете хранить изображения в кэше
• можно использовать .diskCacheStrategy(DiskCacheStrategy.NONE) отключить кэш диска

во избежание ошибки памяти можно просто принять меры предосторожности, чтобы убедиться, что это не произойдет. Таким образом, ответ на этот вопрос на самом деле является кучей предложений, которые можно предложить. И я тоже.--5-->

как было предложено @Reaz Murshed Я также рекомендую иметь изображения в нескольких разных размерах. Кроме этого, я хотел бы добавить еще несколько вещей, которые могут помочь вам проанализировать эту проблему и решить ее.

насколько я помню, ум был всегда ошибка использования,largeHeap просто задержит его; или если это большая нагрузка, то, возможно, это невозможно. Поэтому я предлагаю вам следовать этой ссылка для диагностики утечек памяти.

трассировки стека OutOfMemoryErrors не поможет в диагностике их. Он просто говорит тебе, что он сломан, и что-то заполнило его. память. Это заполнение происходит задолго до фактического исключения заброшенный. Это также означает, что обычно все, что бросает OOM не на самом деле виновник. Единственное исключение-когда сумма Wannabe выделенная память просто слишком велика, например: массив для быть выделенным больше, чем максимальная память, тогда вы знаете, что некоторые вычисления пошли действительно неправильно, как изображение 32000x32000@4 занимает около 4 ГБ памяти.

если вы можете воспроизвести: получить дамп "кучи" и анализа использования приложения. Нормальные шаги диагностики OOM:

• воспроизвести исключение (ждать пока вы не увидите его в LogCat)

• взять дамп "кучи" (для анализа утечек памяти)

• проанализируйте его для больших объектов и утечек

в выше общей ссылке есть несколько других ссылок, касающихся how to take heap dump? и вопросы которые идентичны этому.

поэтому я предлагаю вам проанализировать утечки памяти и принять необходимые меры для предотвращения OOM.

надеюсь, это поможет вы.

вероятно, для решения этой проблемы можно использовать другой подход. Для достижения этого вы можете использовать разные ImageAdapter С

Glide.with(mActivity).loadFromMediaStore(_imageInfo.getmUri())

это не сбой при использовании MediaStoreThumbFetcher

чтобы иметь больше контроля над нагрузкой, выполните следующие действия с помощью Glide v4

// usage:
Glide.with(mActivity).load(_imageInfo)....

// in GlideModule.registerComponents
registry.prepend(ImageInfo.class, ImageInfo.class, new UnitModelLoader.Factory<ImageInfo>());
registry.prepend(ImageInfo.class, Bitmap.class, new ImageInfoBitmapDecoder(context));

class ImageInfoBitmapDecoder implements ResourceDecoder<ImageInfo, Bitmap> {
    private final ContentResolver contentResolver;
    private final BitmapPool pool;
    public ImageInfoBitmapDecoder(Context context) {
        this.contentResolver = context.getContentResolver();
        this.pool = Glide.get(context).getBitmapPool();
    }
    @Override public boolean handles(ImageInfo source, Options options) { return true; }
    @Override public @Nullable Resource<Bitmap> decode(ImageInfo source, int width, int height, Options options) {
        Bitmap thumb = Thumbnails.getThumbnail(contentResolver, source.getmId(), Thumbnails.MINI_KIND, null);
        return BitmapResource.obtain(thumb, pool);
    }
}

используя следующие API, мы можем выяснить свободную память, оставленную вне и размер растрового изображения

вы можете проверить доступную память и детали растрового изображения (при необходимости) в качестве предварительной проверки

проверьте количество свободной памяти

public static final float BYTES_IN_MB = 1024.0f * 1024.0f;

    public static float megabytesFree() {
        final Runtime rt = Runtime.getRuntime();
        final float bytesUsed = rt.totalMemory();
        final float mbUsed = bytesUsed/BYTES_IN_MB;
        final float mbFree = megabytesAvailable() - mbUsed;
        return mbFree;
    }

    public static float megabytesAvailable() {
        final Runtime rt = Runtime.getRuntime();
        final float bytesAvailable = rt.maxMemory();
        return bytesAvailable/BYTES_IN_MB;
}

проверьте, насколько велика растровая карта, которую мы хотим загрузить

private void readBitmapInfo() {
        final Resources res = getActivity().getResources();
        final BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeResource(res, R.drawable.brasil, options);
        final float imageHeight = options.outHeight;
        final float imageWidth = options.outWidth;
        final String imageMimeType = options.outMimeType;
        Log.d(TAG, "w,h, type:"+imageWidth+", "+imageHeight+", "+imageMimeType);
        Log.d(TAG, "estimated memory required in MB: "+imageWidth * imageHeight * BYTES_PER_PX/MemUtils.BYTES_IN_MB);
}

для получения более подробной информации пройдите методы Java для проверки памяти и растровые и обсуждение github