Out-Of-Memory-Fehler Beim laden mehr Bilder in Glide

Bearbeitet:

In meiner Anwendung, ich bin laden mehr als 300 Bilder in der Homepage. Ich verwendet glide Bilder laden. Ich bin immer Out of Memory Error.

Benutzt habe ich große Haufen wahr manifest :

android:largeHeap="true"

Glide Version:

compile 'com.github.bumptech.glide:glide:3.7.0'

Gerät/Android-Version:

Nexus-Gerät version 6.0

Jeder Bilder, ich bin immer von Json wäre 800kb bis 1mb.

activity_layout:

<RelativeLayout
    android:id="@+id/home_layout_bottom"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_below="@+id/home_layout_top_recycler"
    android:layout_margin="5dp">

    <android.support.v7.widget.RecyclerView
        android:id="@+id/rv_list_tab_home_recycler"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:clipToPadding="false"
        android:scrollbars="vertical"
        android:visibility="visible" />

    <TextView
        android:id="@+id/no_user_posts_item_tv_recycler"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/rv_list_tab_home_recycler"
        android:layout_marginTop="80dp"
        android:layout_centerHorizontal="true"
        android:text="@string/txt_no_posts_available"
        android:textColor="@color/txt_common_black"
        android:textSize="@dimen/txt_size" />
</RelativeLayout>

- adapter, code:

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    ViewHolder holder = null;

    final HomePostItems rowItem = getItem(position);

    LayoutInflater mInflater = (LayoutInflater) context.getSystemService(Activity.LAYOUT_INFLATER_SERVICE);
    if (convertView == null) {

        convertView = mInflater.inflate(R.layout.lv_adapter_post_items_layout, null);

      holder = new ViewHolder();

      holder.ivPostedImage = (ImageView) convertView.findViewById(R.id.iv_posted_img);


        convertView.setTag(holder);
    } else {
        holder = (ViewHolder) convertView.getTag();
    }

      ..................

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

adapter_layout.xml:

<RelativeLayout
    android:id="@+id/rl_lv_user_post_adapter_img_holder_home"
    android:layout_width="match_parent"
    android:layout_height="300dp"
    android:layout_marginLeft="1dp"
    android:layout_marginRight="1dp"
    android:layout_below="@+id/tv_user_posted_msg_post_items_home" >

    <ImageView
        android:id="@+id/iv_posted_img_home"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_centerInParent="true"
        android:scaleType="fitXY"
        android:background="#ffffff"
        android:contentDescription="@string/cont_desc"/>
</RelativeLayout>

Logcat:

Request threw uncaught throwable
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Failed to allocate a 6365196 byte allocation with 865912 free bytes and 845KB until OOM
at java.util.concurrent.FutureTask.report(FutureTask.java:94)
at java.util.concurrent.FutureTask.get(FutureTask.java:164)
at com.bumptech.glide.load.engine.executor.FifoPriorityThreadPoolExecutor.afterExecute(FifoPriorityThreadPoolExecutor.java:96)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
at com.bumptech.glide.load.engine.executor.FifoPriorityThreadPoolExecutor$DefaultThreadFactory$1.run(FifoPriorityThreadPoolExecutor.java:118)
Caused by: java.lang.OutOfMemoryError: Failed to allocate a 6365196 byte allocation with 865912 free bytes and 845KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
at android.graphics.BitmapFactory.decodeStreamInternal(BitmapFactory.java:635)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:611)
at com.bumptech.glide.load.resource.bitmap.Downsampler.decodeStream(Downsampler.java:329)
at com.bumptech.glide.load.resource.bitmap.Downsampler.downsampleWithSize(Downsampler.java:220)
at com.bumptech.glide.load.resource.bitmap.Downsampler.decode(Downsampler.java:153)
at com.bumptech.glide.load.resource.bitmap.StreamBitmapDecoder.decode(StreamBitmapDecoder.java:50)
at com.bumptech.glide.load.resource.bitmap.StreamBitmapDecoder.decode(StreamBitmapDecoder.java:19)
at com.bumptech.glide.load.resource.bitmap.ImageVideoBitmapDecoder.decode(ImageVideoBitmapDecoder.java:39)
at com.bumptech.glide.load.resource.bitmap.ImageVideoBitmapDecoder.decode(ImageVideoBitmapDecoder.java:20)
at com.bumptech.glide.load.resource.gifbitmap.GifBitmapWrapperResourceDecoder.decodeBitmapWrapper(GifBitmapWrapperResourceDecoder.java:121)
at com.bumptech.glide.load.resource.gifbitmap.GifBitmapWrapperResourceDecoder.decodeStream(GifBitmapWrapperResourceDecoder.java:94)
at com.bumptech.glide.load.resource.gifbitmap.GifBitmapWrapperResourceDecoder.decode(GifBitmapWrapperResourceDecoder.java:71)
at com.bumptech.glide.load.resource.gifbitmap.GifBitmapWrapperResourceDecoder.decode(GifBitmapWrapperResourceDecoder.java:61)
at com.bumptech.glide.load.resource.gifbitmap.GifBitmapWrapperResourceDecoder.decode(GifBitmapWrapperResourceDecoder.java:22)
at com.bumptech.glide.load.engine.DecodeJob.decodeFromSourceData(DecodeJob.java:190)
at com.bumptech.glide.load.engine.DecodeJob.decodeSource(DecodeJob.java:177)
at com.bumptech.glide.load.engine.DecodeJob.decodeFromSource(DecodeJob.java:128)
at com.bumptech.glide.load.engine.EngineRunnable.decodeFromSource(EngineRunnable.java:122)
at com.bumptech.glide.load.engine.EngineRunnable.decode(EngineRunnable.java:101)
at com.bumptech.glide.load.engine.EngineRunnable.run(EngineRunnable.java:58)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588) 
at java.lang.Thread.run(Thread.java:818) 
at com.bumptech.glide.load.engine.executor.FifoPriorityThreadPoolExecutor$DefaultThreadFactory$1.run(FifoPriorityThreadPoolExecutor.java:118)

Ich weiß nicht, wie man dieses Problem beheben OOM Problem. Bitte teilen Sie Ihren Vorschlag, wenn Sie bereits vertraut mit diesem Thema.

Wo speicherst du die alten Klingelton?
Bekommt man OOM während scrollling oder auf der ersten Seite laden?
nach dem durchblättern der Bilder bin ich immer dieses Problem.
als Sie sagte,ich habe

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

.in(imageViewResize); muss hinzufügen centercrop oder fitcenter? ich bin noch immer OOM
können Sie bitte teilen Sie adapter s-code mit dem Wunsch ss

InformationsquelleAutor Stephen | 2016-07-25

android out-of-memory

8

Dies ist nicht eine exakte Lösung für Ihr problem, aber Sie brauchen, um zu halten diese Dinge im Hinterkopf, während das laden von Bildern in einer Liste mit Glide.

Haupt droht ein Teil des Problems ist die Größe des Bildes. Das Bild, das Sie bekommen, ist fast 1mb! Das ist in der Tat zu groß für die Darstellung in einer Liste mit 300+ items. Also, wenn Sie tun, die server-Seite auch, es ist immer empfohlen, die Bilder in verschiedenen Größen.

Zum Beispiel für den Fall zu zeigen, eine Freundesliste zusammen mit Ihren Profil-Bildern ist, würde ich vorschlagen, erhalten Sie die gesamte Liste vom server. Dann Holen alle Profil-Bilder und speichern Sie Sie lokal. Dann füllen Sie die ListView. Und der wichtigste Teil ist beim hochladen ein Profilbild eines Nutzers an den server, nach dem hochladen, der server braucht, um mehrere Größen von z.B. low -, mid-und high-res-version. Also, wenn man das Profil Bild-urls für den ListView dem server könnte die Bilder mit low-res, wie Sie genutzt werden höchstwahrscheinlich für die Vorschaubilder.

Mit RecyclerView statt ListView ist eine gute zu nennen. Aber Sie lösen nicht das problem, Sie haben hier, wenn man in einer low-end-Gerät.

OMM hat nichts damit zu tun, die Sie lösen können programmgesteuert. Sie müssen, um die Größe Ihres Bildes auf eine niedrigere res-version.

Können Sie überprüfen, für die Glide ist caching-Mechanismus zu. Ich schlage vor, Sie verwenden die caching-Strategie, so dass jedes mal, wenn Sie nicht haben, laden Sie das Bild vom server.

Glück.

InformationsquelleAutor Reaz Murshed
5
- Ich löste dieses Problem, indem entfernen von verschachtelten scroll-view oben gelegt
  recyclerview. Warum OutOfMemory-Fehler bedeutet, beim laden mehr
  über 200 Bilder in der Startseite, es lädt alle 200 Bilder aufgrund der Verwendung von
  verschachtelte scroll-Ansicht oben recyclerview.
- So, ich kann nicht überprüfen Sie die logcat-Ansicht die Breite und Höhe einer von einem in
  adapter.
- Nach entfernt verschachtelte scroll-view behoben-out of memory " - Fehlermeldung.weil es
  geladen wird nur 3 Bilder angezeigt, im Gerät kommen, wenn zu Hause
  Aktivität.
- Überprüfen Sie auch
  diese, wie zu verwenden, Blättern Sie anstelle von geschachtelten Blättern-Ansicht.
InformationsquelleAutor Stephen
4

Mit Glide nicht garantieren, dass keine Out of Memory Fehler, müssen Sie einige kleine Schritte, um die Wahrscheinlichkeit zu verringern, um nicht OOM's.

Schritt 1: Verstehen, die caching-Mechanismus in Glide

Schritt 2: ich lieber zum laden thumbnails in recyclerview
```
Glide  
    .with( context )
    .load( UsageExampleGifAndVideos.gifUrl )
    .thumbnail( 0.1f )
    .into( imageView2 );
```
Denken Sie daran, immer kleine Anfrage Größe Bild, wenn größer oder HD Bilder
nicht erforderlich.

InformationsquelleAutor Murtaza Khursheed Hussain
3

Verwenden recyclerView statt ListView. Es wiederverwendbare single-Element für die Darstellung der Elemente. Ich bin mit glide mit recyclerView wo ich bin laden-Wallpaper mit 100+ items.

In ListView, jedes mal, wenn Sie erstellen anzeigen, wenn Sie 100+ Sicht, und es wird mit 100+ views wo, wie in recyclerview es schafft, wie viele sichtbare Elemente gibt es in screen +2.

bitte überprüfen Sie meine post bearbeitet.
Sieht aus wie Sie nicht aktualisiert, adapter, code
Ein ListView würde auch nicht dazu führen, jede OOMEs
ListView erstellen Sie keine 100+ views, aber wiederverwendet, alte Ansicht - convertView. Dies ist also kein Fall da sein. @Naruto was ist Android-version auf Ihrem test-Gerät?
marshmallow-version 6.0

InformationsquelleAutor subrahmanyam boyapati
3
1. Stellen Sie sicher, dass die Bildansicht hat match_parent oder Feste dp Abmessungen
  wrap_content macht Glide laden voller Auflösung Bitmaps.
2. .Platzhalter() zeigt ein Bild statt des leeren Raumes beim laden von großen bitmap -
3. .Miniaturansicht(float) lädt eine version mit Downsampling schnell, während das größere Bild, ist das laden im hintergrund
4. Schauen auch rund um die Glide Probleme, vielleicht findest du etwas hilfreiches.
Für mehr Informationen stackoverflow.com/questions/30718303/...

InformationsquelleAutor Jamil Hasnine Tamim

Ich Stand vor dem ähnlichen problem . Ich Teile die Art, wie ich es gelöst . Erstellen Sie einen Ordner namens drawable-nodpi setzen Sie Ihre golive_load_image und golive_cancel_im‌age - Datei in diesen Ordner , und entfernen Sie die beiden image-Datei von einem anderen Ort wie drawable-ldpi,drawable-hdpi etc (wenn Sie es haben ) . Und fügen Sie 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);

InformationsquelleAutor Mithun Sarker Shuvro

Der Grund ist, beim scrollen, gleiten, halten Sie dabei Bild-Prozess selbst verbundenen Ansichten entfernt aus der Liste. Fügen Sie diesen code in Ihre listview onScrollStateChanged.

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;
        }
    }

InformationsquelleAutor invisbo

1
- Ihre Bilder sollten nicht zu groß sein ( wenn Sie, verwenden Sie .thumbnail(...f) )
- verwenden .skipMemoryCache(true) wenn Sie nicht mit Gewalt, damit die Bilder im cache
- können Sie .diskCacheStrategy(DiskCacheStrategy.NONE) so deaktivieren Sie den Festplatten-cache
InformationsquelleAutor Misagh
1

Um zu verhindern, dass Out-of-Memory-Fehler kann man nur treffen Vorkehrungen, um sicherzustellen, dass es nicht Auftritt. Also ist die Antwort auf diese Frage ist eigentlich eine Reihe von Anregungen kann man empfehlen. So do I.

Vorgeschlagen von @Reaz Murshed bin ich auch empfehlen, die Bilder in verschiedenen Größen. Abgesehen von dieser möchte ich hinzufügen, einige weitere Dinge, die helfen könnten, Sie analysieren das Problem und lösen es.

Soweit ich mich erinnere OOM war immer ein Syntax-Fehler, largeHeap wird nur verzögern; oder wenn es ist eine große Last, dann ist es vielleicht nicht möglich. Also ich schlage vor, Sie Folgen diese link diagnostizieren, die für Speicherlecks.
Stack-traces von OutOfMemoryErrors helfen nicht bei der Diagnose
. Es zeigt nur, dass es kaputt ist und etwas befüllt
Speicher. Diese Füllung geschieht sehr viel, bevor die eigentliche Ausnahme war
geworfen. Dies bedeutet auch, dass in der Regel was auch immer wirft die OOM ist nicht
eigentlich der Schuldige ist. Die einzige Ausnahme ist, wenn der Betrag der
Möchtegern-Speicher zugewiesen, ist einfach zu groß, zum Beispiel: ein array an
zugewiesen werden, ist größer als die maximale Speichermenge an, dann wissen Sie, dass
einige der Berechnung ging wirklich schief, wie ein 32000x32000@4 Bild
nehmen Sie rund 4 GB Speicherplatz.

Wenn Sie sich reproduzieren können: Holen Sie sich ein heap-dump und analysieren Sie Ihre app-Nutzung.
Normal OOM diagnostische Schritte:
- Reproduzieren Ausnahme
  (warten Sie, bis Sie sehen, wie es in LogCat)
- Einen heap dump(Zum analysieren von memory-leaks)
- Analysieren es für große Objekte und Lecks
Im oben geteilten link gibt es einige weitere links in Bezug auf how to take heap dump? und Fragen, die identisch mit dieser.

So, ich schlage vor, Sie zu analysieren, für memory-leaks und die notwendigen Maßnahmen ergreifen, um zu verhindern, dass OOM.

Hoffe, dies wird Ihnen helfen.

InformationsquelleAutor Pravin Divraniya

Wahrscheinlich einen anderen Ansatz genommen werden kann, diese zu lösen.
Um dies zu erreichen können Sie ein anderes ImageAdapter mit

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

diese nicht Abstürzen, wird mit MediaStoreThumbFetcher

Haben mehr Kontrolle über die Last sollten Sie die folgenden using-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);
    }
}

Verwendung der folgenden API ' s können wir herausfinden, freien Speicher gelassen und Größe der bitmap

Können Sie überprüfen Sie den verfügbaren Speicher-und bitmap-Daten (wenn nötig) als pre-check

Prüfen, wie viel freier Speicher übrig

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;
}

Überprüfen, wie groß ist die bitmap, die wir laden wollen,

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);
}

Für weitere details gehen Sie durch Java-Methoden zur überprüfung der Speicher-und bitmap und github-Diskussion

InformationsquelleAutor Sreehari

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.