Fresco: OOM fréquent lors de l'utilisation de Fresco lib
La description
J'utilise Fresco lib via gradle( 1.1.0 ) pour toute la gestion des Bitmaps dans notre application, après avoir utilisé l'application pendant un certain temps, elle lance fréquemment OOM, notre application traite de nombreuses images à la fois, il peut y avoir 8- 10 images (pas toutes de la même taille, certaines couvrent la moitié de l'écran tandis que d'autres ne prennent que 50 à 70 dp) affichées sur un seul écran et toutes sont chargées via le réseau à l'aide de fresques,
la plupart des images utilisées sont avec des composants déroulants tels que ListView, GridView, RecyclerView, tandis que certaines images sont recyclées via notre propre logique, ci-dessous est la mise en œuvre pour les mêmes.
Noter:
- La fresque est initialisée à l'aide de
setDownsampleEnabled - Toutes les images en cours de chargement sont
resized, bien que certaines de nos images soient de type.pngmais la plupart d'entre elles sont au formatjpeg
la reproduction
JOURNAL des plantages
03-15 22:21:21.199 7035-7203/com.xyz E/AndroidRuntime: FATAL EXCEPTION: Thread-442
Process: com.xyz, PID: 7035
java.lang.OutOfMemoryError: Failed to allocate a 1638412 byte allocation with 589552 free bytes and 575KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:831)
at android.graphics.Bitmap.createBitmap(Bitmap.java:808)
at android.graphics.Bitmap.createBitmap(Bitmap.java:775)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:55)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:30)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:259)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeStaticImageFromStream(ArtDecoder.java:137)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeJPEGFromEncodedImage(ArtDecoder.java:120)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decodeJpeg(DefaultImageDecoder.java:183)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder$1.decode(DefaultImageDecoder.java:63)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decode(DefaultImageDecoder.java:123)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.doDecode(DecodeProducer.java:239)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.access$200(DecodeProducer.java:111)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:144)
at com.facebook.imagepipeline.producers.JobScheduler.doJob(JobScheduler.java:207)
at com.facebook.imagepipeline.producers.JobScheduler.access$000(JobScheduler.java:27)
at com.facebook.imagepipeline.producers.JobScheduler$1.run(JobScheduler.java:78)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:43)
at java.lang.Thread.run(Thread.java:818)
03-15 22:44:53.849 8055-8055/com.xyz E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.xyz, PID: 8055
android.view.InflateException: Binary XML file line #2: Binary XML file line #2: Error inflating class <unknown>
at android.view.LayoutInflater.inflate(LayoutInflater.java:539)
at android.view.LayoutInflater.inflate(LayoutInflater.java:423)
at com.xyz.view.newswipe.view.FbLikesGridView$FbLikesAdapter.onCreateViewHolder(FbLikesGridView.java:195)
at com.xyz.view.newswipe.view.FbLikesGridView$FbLikesAdapter.onCreateViewHolder(FbLikesGridView.java:160)
at android.support.v7.widget.RecyclerView$Adapter.createViewHolder(RecyclerView.java:6319)
at android.support.v7.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:5507)
at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5392)
at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5388)
at android.support.v7.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2149)
at android.support.v7.widget.GridLayoutManager.layoutChunk(GridLayoutManager.java:556)
at android.support.v7.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1496)
at android.support.v7.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:593)
at android.support.v7.widget.GridLayoutManager.onLayoutChildren(GridLayoutManager.java:170)
at android.support.v7.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3535)
at android.support.v7.widget.RecyclerView.onMeasure(RecyclerView.java:2979)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureHorizontal(LinearLayout.java:1112)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:632)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureHorizontal(LinearLayout.java:1112)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:632)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18788)
at android.widget.RelativeLayout.measureChildHorizontal(RelativeLayout.java:715)
at android.widget.RelativeLayout.onMeasure(RelativeLayout.java:461)
at android.view.View.measure(View.java:18788)
at android.widget.RelativeLayout.measureChildHorizontal(RelativeLayout.java:715)
at android.widget.RelativeLayout.onMeasure(RelativeLayout.java:461)
at android.view.View.measure(View.java:18788)
at android.view.ViewGroup.measureChildWithMargins(ViewG
[REMPLISSEZ CECI : Comment pouvons-nous reproduire le bogue ? Fournissez des URL vers des images pertinentes si possible, ou un exemple de projet.]
Solution
[FACULTATIF : Savez-vous ce qui doit être fait pour résoudre ce problème ? Idéalement, fournissez une pull request qui résout ce problème.]
Information additionnelle
- Version fresque : [1.1.0]
- Version de la plate-forme : [ Android version 5 et supérieure]
c'est ainsi que nous initialisons la fresque.
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ImagePipelineConfig imagePipelineConfig = ImagePipelineConfig
.newBuilder(getApplicationContext())
.setDownsampleEnabled(true)
.setBitmapMemoryCacheParamsSupplier(new FrescoCacheParams(activityManager))
.build();
Fresco.initialize(getApplicationContext(), imagePipelineConfig);
c'est ainsi que la classe FrescoCacheParams est définie.
public class FrescoCacheParams implements Supplier<MemoryCacheParams> {
private ActivityManager activityManager;
public FrescoCacheParams(ActivityManager activityManager) {
this.activityManager = activityManager;
}
<strong i="17">@Override</strong>
public MemoryCacheParams get() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
int cacheSize = getMaxCacheSize();
Log.d("####","fresco cache size = " + cacheSize);
return new MemoryCacheParams(cacheSize, 1, 1, 1, 1);
} else {
return new MemoryCacheParams(
getMaxCacheSize(),
256,
Integer.MAX_VALUE,
Integer.MAX_VALUE,
Integer.MAX_VALUE);
}
}
private int getMaxCacheSize() {
final int maxMemory = Math.min(activityManager.getMemoryClass()
* ByteConstants.MB, Integer.MAX_VALUE);
if (maxMemory < 32 * ByteConstants.MB) {
return 4 * ByteConstants.MB;
} else if (maxMemory < 64 * ByteConstants.MB) {
return 6 * ByteConstants.MB;
} else {
if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.GINGERBREAD) {
return 8 * ByteConstants.MB;
} else {
return maxMemory / 6;
}
}
}
}
C'est ainsi que toutes les images sont chargées, où width et height sont la taille réelle de la vue qui affichera les images chargées.
ImageRequest request = ImageRequestBuilder.newBuilderWithSource(uri)
.setResizeOptions(new ResizeOptions(width, height))
.build();
DraweeController controller = Fresco.newDraweeControllerBuilder()
.setOldController(getController())
.setImageRequest(request)
.build();
setController(controller);
Vous trouverez ci-dessous un extrait de notre logique de recyclage, car nous avons une implémentation personnalisée de AdapterView nous nous occupons de libérer les ressources.
// calling on each Drawee, once it moves out of visible area
if (getController() != null) {
getController().onDetach();
}
````
// once a image moves out of display area, we are evicting it out of pipeline as well.
ImagePipeline imagePipeline = Fresco.getImagePipeline();
Uri uri = Uri.parse(url);
imagePipeline.evictFromMemoryCache(uri);
```
nous appelons le code ci-dessus sur tous les Drawee's qui sont utilisés pour afficher des images dans les cartes, une fois qu'ils sortent de la zone visible sur notre AdapterView
nucleartip
Tous les 15 commentaires
Salut @nucleartip , merci d'avoir soumis le rapport de bogue !
Avez-vous essayé de capturer un vidage de mémoire avant que le MOO ne se produise pour voir ce qui utilise toute la mémoire ?
Au fait, pour Lollipop et au-dessus, vous utilisez maxCacheEntrySize=1, est-ce une tentative de désactiver complètement le cache mémoire ou de le limiter à un seul élément ?
erikandre
le 15 mars 2017
@erikandre grande taille de file d'attente lançait OOM à un rythme encore plus fréquent, alors j'ai opté pour une entrée de cache faible juste pour désactiver pratiquement le cache mémoire.
permettez-moi de faire un vidage pour vous, mais dans tous les cas, pouvez-vous suggérer une solution de contournement, car ces MOO se produisent dans des appareils de nouvelle génération tels que Samsung S7, les derniers téléphones de la série Nexus, etc.
nucleartip
le 16 mars 2017
@erikandre voici un instantané du vidage de la mémoire, pris juste avant le crash de l'application en raison du MOO.
nucleartip
le 16 mars 2017
@nucleartip , vous serait-il possible de partager ce vidage de mémoire avec moi ?
erikandre
le 17 mars 2017
@erikandre tas dump a une taille d'environ 250 Mo, préférez-vous un lecteur ou une boîte de dépôt ?
nucleartip
le 20 mars 2017
@nucleartip L'un ou l'autre fonctionnerait bien :)
erikandre
le 20 mars 2017
Cela a-t-il déjà été résolu ? J'ai le même problème.
hackjedi
le 3 mai 2017
J'ai vérifié le vidage de la mémoire par Eclipse Memory Analyzer.
J'ai vu trop d'octets[] aussi.
Mais lorsque j'utilise le chemin vers GC, aucune référence n'est trouvée.
Il semble que ceux-ci soient référencés à partir de natifs, tels que NativePooledByteBuffer ou NativeMemoryChunk.
Je pensais que ceux-ci sont dans com.facebook.common.references.SharedReference.sLiveObjects, mais je n'ai pas de preuves.
Et je ne sais pas pourquoi ceux-ci ne sont pas libérés...
Je n'ai pas pu résoudre ce problème.
cattaka
le 2 juin 2017
J'ai également rencontré le même problème, voici les informations sur les exceptions :
E/AndroidRuntime: FATAL EXCEPTION: Thread-5458 Process:
package-name, PID: 4877
java.lang.OutOfMemoryError: Failed to allocate a 2560012 byte allocation with 1782384 free bytes and 1740KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:843)
at android.graphics.Bitmap.createBitmap(Bitmap.java:820)
at android.graphics.Bitmap.createBitmap(Bitmap.java:787)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:55)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:30)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:260)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeStaticImageFromStream(ArtDecoder.java:137)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeJPEGFromEncodedImage(ArtDecoder.java:120)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decodeJpeg(DefaultImageDecoder.java:186)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder$1.decode(DefaultImageDecoder.java:63)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decode(DefaultImageDecoder.java:126)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.doDecode(DecodeProducer.java:240)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.access$200(DecodeProducer.java:112)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:145)
at com.facebook.imagepipeline.producers.JobScheduler.doJob(JobScheduler.java:207)
at com.facebook.imagepipeline.producers.JobScheduler.access$000(JobScheduler.java:27)
at com.facebook.imagepipeline.producers.JobScheduler$1.run(JobScheduler.java:78)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:43)
at java.lang.Thread.run(Thread.java:818)
Il s'agit de toutes les informations du GC avant que le MOO ne se produise :
I/art: Starting a blocking GC Alloc
I/art: Starting a blocking GC Alloc
I/art: Alloc sticky concurrent mark sweep GC freed 92215(9MB) AllocSpace objects, 36(660KB) LOS objects, 8% free, 117MB/128MB, paused 1.228ms total 37.123ms
I/art: Starting a blocking GC Alloc
I/art: Starting a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
I/art: Clamp target GC heap from 188MB to 128MB
I/art: Alloc partial concurrent mark sweep GC freed 45395(2MB) AllocSpace objects, 43(860KB) LOS objects, 3% free, 124MB/128MB, paused 727us total 59.648ms
I/art: WaitForGcToComplete blocked for 25.090ms for cause Alloc
I/art: Starting a blocking GC Alloc
I/art: Starting a blocking GC Alloc
I/art: Starting a blocking GC Alloc
W/art: Suspending all threads took: 5.155ms
I/art: Waiting for a blocking GC Alloc
I/art: Alloc sticky concurrent mark sweep GC freed 2803(277KB) AllocSpace objects, 2(40KB) LOS objects, 0% free, 126MB/128MB, paused 579us total 19.249ms
I/art: Starting a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
I/art: Alloc sticky concurrent mark sweep GC freed 822(87KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 126MB/128MB, paused 547us total 12.316ms
I/art: WaitForGcToComplete blocked for 11.410ms for cause Alloc
I/art: Starting a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
I/art: Clamp target GC heap from 190MB to 128MB
I/art: Alloc partial concurrent mark sweep GC freed 4725(241KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 126MB/128MB, paused 658us total 46.759ms
I/art: WaitForGcToComplete blocked for 46.699ms for cause Alloc
I/art: Starting a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
I/art: Clamp target GC heap from 190MB to 128MB
I/art: Alloc concurrent mark sweep GC freed 801(78KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 126MB/128MB, paused 796us total 40.098ms
I/art: WaitForGcToComplete blocked for 35.773ms for cause Alloc
I/art: Starting a blocking GC Alloc
I/art: Forcing collection of SoftReferences for 2MB allocation
I/art: Waiting for a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
I/art: Clamp target GC heap from 191MB to 128MB
I/art: Alloc concurrent mark sweep GC freed 3661(366KB) AllocSpace objects, 1(20KB) LOS objects, 0% free, 127MB/128MB, paused 634us total 61.758ms
I/art: WaitForGcToComplete blocked for 60.363ms for cause Alloc
I/art: Starting a blocking GC Alloc
I/art: Waiting for a blocking GC Alloc
W/art: Suspending all threads took: 38.816ms
/I/art: Forcing collection of SoftReferences for 2MB allocation
/I/art: Waiting for a blocking GC Alloc
/I/art: Clamp target GC heap from 190MB to 128MB
/I/art: Alloc concurrent mark sweep GC freed 214(8KB) AllocSpace objects, 1(416KB) LOS objects, 0% free, 126MB/128MB, paused 876us total 42.655ms
/I/art: WaitForGcToComplete blocked for 82.057ms for cause Alloc
/I/art: Starting a blocking GC Alloc
/I/art: Starting a blocking GC Alloc
/W/art: Throwing OutOfMemoryError "Failed to allocate a 2560012 byte allocation with 1643888 free bytes and 1605KB until OOM"
/I/art: Waiting for a blocking GC Alloc
/I/art: Clamp target GC heap from 190MB to 128MB
/I/art: Alloc concurrent mark sweep GC freed 12633(1496KB) AllocSpace objects, 0(0B) LOS objects, 1% free, 126MB/128MB, paused 684us total 43.271ms
/I/art: WaitForGcToComplete blocked for 136.549ms for cause Alloc
/I/art: Starting a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
/I/art: Forcing collection of SoftReferences for 2MB allocation
/I/art: Waiting for a blocking GC Alloc
/I/art: Clamp target GC heap from 190MB to 128MB
/I/art: Alloc concurrent mark sweep GC freed 2239(265KB) AllocSpace objects, 0(0B) LOS objects, 1% free, 126MB/128MB, paused 1.282ms total 40.182ms
/I/art: WaitForGcToComplete blocked for 120.837ms for cause Alloc
/I/art: Starting a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
/I/art: Forcing collection of SoftReferences for 2MB allocation
/I/art: Waiting for a blocking GC Alloc
/W/art: Suspending all threads took: 30.572ms
/I/art: Clamp target GC heap from 190MB to 128MB
/I/art: Alloc concurrent mark sweep GC freed 7(1264B) AllocSpace objects, 0(0B) LOS objects, 1% free, 126MB/128MB, paused 2.697ms total 43.668ms
/I/art: WaitForGcToComplete blocked for 129.040ms for cause Alloc
/I/art: Starting a blocking GC Alloc
/I/art: WaitForGcToComplete blocked for 83.495ms for cause Alloc
/I/art: Starting a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
/W/art: Throwing OutOfMemoryError "Failed to allocate a 2560012 byte allocation with 1782384 free bytes and 1740KB until OOM"
/I/art: Waiting for a blocking GC Alloc
/I/art: Waiting for a blocking GC Alloc
1 Avant de planter, ouvrez une page Viewpager + RecyclerView dans la première :
Il y a environ 20 photos.
2 Avant de planter, ouvrez une page Viewpager + RecyclerView dans les deux premières :
Il y a environ 40 images, Viewpager des deux côtés du Pager ont chacun 30 images.
3 Après l'accident :
yanzhenjie
le 8 juin 2017
Je continue de voir cela de plus en plus fréquemment, en particulier sur les nouveaux appareils avec plus de RAM disponible. C'est comme si plus il y avait de RAM Fresco avec, plus les MOO étaient fréquents.
Ma configuration est celle par défaut (je n'ai pas encore essayé d'implémenter mes propres fournisseurs), mais je doute sérieusement que cela soit d'une grande aide (à moins que je définisse le nombre maximal d'entrées de cache sur 0, désactivant ainsi totalement le cache).
Une idée de comment on peut s'attaquer à ça ?
mradzinski
le 7 juil. 2017
@mradzinski J'ai fini par porter entièrement sur Glide , déclarant ainsi notre application exempte de MOO.
nucleartip
le 7 juil. 2017
Le fait amusant de
mradzinski
le 7 juil. 2017
Clôturant ceci car nous n'avons pas assez d'informations pour continuer l'enquête.
Pour tout autre problème de mémoire insuffisante, veuillez créer une nouvelle tâche et inclure de préférence un vidage mémoire HPROF.
erikandre
le 11 juil. 2017
@erikandre
Je sais que vous n'avez pas assez d'informations pour résoudre les problèmes de MOO. Je suggère simplement de publier un événement d'erreur avec rappel au lieu de simplement lancer une erreur OOM. Pour que nous puissions traiter nous-mêmes l'événement OOM.
AlexCJW
le 7 nov. 2017
@AlexCJW Je ne pense pas qu'il existe un moyen de gérer une exception déclenchée par le système telle qu'un MOO, et en outre, je ne peux pas penser à un scénario dans lequel votre application pourra répondre à un rappel après avoir reçu un MOO depuis ce rappel lui-même devrait également consommer de la mémoire indisponible après tout.
mradzinski
le 8 nov. 2017
Questions connexes
ykostova
·
3Commentaires
amodkanthe
·
3Commentaires
rhettor
·
3Commentaires
eldk
·
3Commentaires
rafaelekol
·
4Commentaires
Commentaire le plus utile
Le fait amusant de