Fresco: متكرر OOM أثناء استخدام Fresco lib
وصف
أنا أستخدم fresco lib من خلال gradle ( 1.1.0 ) لجميع معالجة الصور النقطية في تطبيقنا ، بعد استخدام التطبيق لفترة من الوقت يلقي بشكل متكرر OOM ، يتعامل تطبيقنا مع الكثير من الصور في وقت واحد ، قد يكون هناك 8- يتم عرض 10 صور (ليست جميعها من نفس الأحجام ، بعضها يغطي نصف الشاشة بينما يأخذ بعضها حجم 50-70dp فقط) يتم عرضها في شاشة واحدة ويتم تحميلها جميعًا عبر الشبكة باستخدام لوحة جدارية ،
معظم الصور المستخدمة مع مكونات قابلة للتمرير مثل ListView و GridView و RecyclerView ، بينما يتم إعادة تدوير بعض الصور من خلال منطقنا الخاص ، فيما يلي تنفيذ لنفسه.
ملحوظة:
- تمت تهيئة Fresco باستخدام
setDownsampleEnabled - جميع الصور التي يتم تحميلها هي
resized، على الرغم من أن بعض الصور لدينا من النوع.pngلكن معظمها بتنسيقjpeg
التكاثر
سجل الأعطال
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
[املأ هذا: كيف يمكننا إعادة إنتاج الخطأ؟ قدم عناوين URL للصور ذات الصلة إن أمكن ، أو نموذج مشروع.]
حل
[اختياري: هل تعرف ما يجب القيام به لمعالجة هذه المشكلة؟ من الناحية المثالية ، قدِّم طلب سحب يعمل على إصلاح هذه المشكلة.]
معلومة اضافية
- إصدار فريسكو: [1.1.0]
- إصدار النظام الأساسي: [إصدار Android 5 وما فوق]
هذه هي الطريقة التي نهيئ بها اللوحة الجدارية.
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ImagePipelineConfig imagePipelineConfig = ImagePipelineConfig
.newBuilder(getApplicationContext())
.setDownsampleEnabled(true)
.setBitmapMemoryCacheParamsSupplier(new FrescoCacheParams(activityManager))
.build();
Fresco.initialize(getApplicationContext(), imagePipelineConfig);
هذه هي الطريقة التي يتم بها تعريف الفئة FrescoCacheParams .
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;
}
}
}
}
هذه هي الطريقة التي يتم بها تحميل جميع الصور ، حيث يمثل width و height الحجم الفعلي للعرض الذي سيعرض الصور المحملة.
ImageRequest request = ImageRequestBuilder.newBuilderWithSource(uri)
.setResizeOptions(new ResizeOptions(width, height))
.build();
DraweeController controller = Fresco.newDraweeControllerBuilder()
.setOldController(getController())
.setImageRequest(request)
.build();
setController(controller);
فيما يلي مقتطف من منطق إعادة التدوير لدينا ، نظرًا لأن لدينا تنفيذًا مخصصًا AdapterView فنحن نعتني بإصدار الموارد.
// 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);
""
نحن نستدعي الكود أعلاه على جميع Drawee's والتي تُستخدم لعرض الصور داخل البطاقات الخارجية ، بمجرد خروجها من المنطقة القابلة للعرض على AdapterView
nucleartip
ال 15 كومينتر
مرحبًا nucleartip ، شكرًا
هل حاولت التقاط تفريغ الذاكرة قبل حدوث OOM لمعرفة ما الذي يستخدم كل الذاكرة؟
بالمناسبة ، بالنسبة لـ Lollipop وما فوق ، فأنت تستخدم maxCacheEntrySize = 1 ، هل هذه محاولة لتعطيل ذاكرة التخزين المؤقت تمامًا أو مجرد تقييدها على عنصر واحد؟
erikandre
في ١٥ مارس ٢٠١٧
erikandre حجم قائمة الانتظار الكبيرة كان يرمي OOM بمعدل أكثر تواترا ، لذلك ذهبت مع إدخال ذاكرة تخزين مؤقت منخفضة فقط لتعطيل ذاكرة التخزين المؤقت عمليا.
اسمحوا لي أن أحصل على تفريغ لك ، ولكن على أي حال ، هل يمكنك اقتراح بعض الحلول لذلك ، حيث تحدث OOM في أجهزة الأجيال الجديدة مثل Samsung S7 ، وأحدث هواتف سلسلة Nexus وما إلى ذلك.
nucleartip
في ١٦ مارس ٢٠١٧
erikandre هنا لقطة لتفريغ الذاكرة ، مأخوذة مباشرة قبل تعطل التطبيق بسبب OOM.
nucleartip
في ١٦ مارس ٢٠١٧
nucleartip ، هل سيكون من الممكن بالنسبة لك أن تشارك تفريغ الذاكرة معي؟
erikandre
في ١٧ مارس ٢٠١٧
يبلغ حجم تفريغ كومة الذاكرة
nucleartip
في ٢٠ مارس ٢٠١٧
nucleartip كلاهما سيعمل بشكل جيد :)
erikandre
في ٢٠ مارس ٢٠١٧
هل تم حل هذا بعد؟ لدي نفس المشكلة.
hackjedi
في ٣ مايو ٢٠١٧
لقد تحققت من تفريغ الذاكرة بواسطة محلل ذاكرة Eclipse.
رأيت الكثير من البايت [] أيضًا.
ولكن عندما أستخدم المسار إلى GC ، لا توجد مراجع.
يبدو أنه تمت الإشارة إلى هؤلاء من اللغة الأصلية ، مثل NativePooledByteBuffer أو NativeMemoryChunk.
اعتقدت أن هؤلاء موجودون في com.facebook.common.references.SharedReference.sLiveObjects ، لكن ليس لدي دليل.
ولا أدري لماذا لم يتم الإفراج عن هؤلاء ...
لم أستطع حل هذه المشكلة.
cattaka
في ٢ يونيو ٢٠١٧
لقد واجهت أيضًا نفس المشكلة ، فيما يلي معلومات الاستثناء:
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)
هذه هي جميع معلومات GC قبل حدوث OOM:
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 قبل التعطل ، افتح صفحة Viewpager + RecyclerView في الصفحة الأولى:
هناك حوالي 20 صورة.
2 قبل التعطل ، افتح صفحة Viewpager + RecyclerView في أول اثنين:
هناك حوالي 40 صورة ، Viewpager على جانبي جهاز النداء يحتوي كل منها على 30 صورة.
3 بعد الانهيار:
yanzhenjie
في ٨ يونيو ٢٠١٧
ما زلت أرى هذا أكثر فأكثر ، خاصة على الأجهزة الأحدث ذات ذاكرة الوصول العشوائي المتوفرة. يبدو الأمر وكأن المزيد من ذاكرة RAM Fresco التي يجب أن تلعبها مع OOM's بشكل متكرر.
التكوين الخاص بي هو الإعداد الافتراضي (لم أحاول تنفيذ الموردين الخاصين بي حتى الآن) ، لكنني أشك بشدة في أن ذلك سيكون مفيدًا للغاية (إلا إذا قمت بتعيين الحد الأقصى لإدخالات ذاكرة التخزين المؤقت على 0 ، وبالتالي تعطيل ذاكرة التخزين المؤقت تمامًا).
أي فكرة كيف يمكننا معالجة هذا؟
mradzinski
في ٧ يوليو ٢٠١٧
mradzinski انتهى بي الأمر Glide ، وبالتالي أعلن أن تطبيقنا خالٍ من OOM.
nucleartip
في ٧ يوليو ٢٠١٧
الحقيقة المضحكة لـ nucleartip هي أنني أتيت من نقل كل شيء من Glide إلى Fresco نظرًا
mradzinski
في ٧ يوليو ٢٠١٧
إغلاق هذا لأننا لا نملك معلومات كافية لمواصلة التحقيق.
بالنسبة لأي مشكلة أخرى تتعلق بنفاد الذاكرة ، يرجى إنشاء مهمة جديدة ويفضل تضمين تفريغ ذاكرة HPROF.
erikandre
في ١١ يوليو ٢٠١٧
تضمين التغريدة
أعلم أنه ليس لديك معلومات كافية لحل مشاكل OOM. أقترح فقط نشر حدث خطأ مع رد الاتصال بدلاً من مجرد إلقاء خطأ OOM. حتى نتمكن من معالجة حدث OOM بأنفسنا.
AlexCJW
في ٧ نوفمبر ٢٠١٧
AlexCJW لا أعتقد أن هناك طريقة للتعامل مع استثناء يثيره النظام مثل OOM ، علاوة على ذلك لا يمكنني التفكير في سيناريو حيث سيكون تطبيقك قادرًا على الرد على رد اتصال بعد تلقي OOM منذ رد الاتصال هذا نفسها يجب أن تستهلك ذاكرة غير متوفرة بعد كل شيء.
mradzinski
في ٨ نوفمبر ٢٠١٧
القضايا ذات الصلة
stevenmtang
·
3تعليقات
rafaelekol
·
4تعليقات
satyarths
·
3تعليقات
stephen-workpop
·
4تعليقات
cococool
·
4تعليقات
التعليق الأكثر فائدة
الحقيقة المضحكة لـ nucleartip هي أنني أتيت من نقل كل شيء من Glide إلى Fresco نظرًا