Android में java.lang.OutOfMemory त्रुटि को हल करने के लिए कैसे करें




bitmap out-of-memory (3)

Altough मेरे पास खींचने योग्य फ़ोल्डर में बहुत छोटी आकार की छवि है, मुझे यह त्रुटि उपयोगकर्ताओं से मिल रही है। और मैं कोड में किसी भी बिटमैप फ़ंक्शन का उपयोग नहीं कर रहा हूं। कम से कम जानबूझकर :)

java.lang.OutOfMemoryError
    at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
    at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:683)
    at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:513)
    at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:889)
    at android.content.res.Resources.loadDrawable(Resources.java:3436)
    at android.content.res.Resources.getDrawable(Resources.java:1909)
    at android.view.View.setBackgroundResource(View.java:16251)
    at com.autkusoytas.bilbakalim.SoruEkrani.cevapSecimi(SoruEkrani.java:666)
    at com.autkusoytas.bilbakalim.SoruEkrani$9$1.run(SoruEkrani.java:862)
    at android.os.Handler.handleCallback(Handler.java:733)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:146)
    at android.app.ActivityThread.main(ActivityThread.java:5602)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:515)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
    at dalvik.system.NativeStart.main(Native Method)

इस स्टैकट्रेस के अनुसार मैं इस त्रुटि पर इस त्रुटि को प्राप्त कर रहा हूं ('टीवी' एक टेक्स्ट व्यू है):

tv.setBackgroundResource(R.drawable.yanlis);

समस्या क्या है? अगर आपको कोड के बारे में कुछ अन्य जानकारी चाहिए, तो मैं इसे जोड़ सकता हूं। धन्यवाद!


Android ऐप्स के लिए ऐसी त्रुटि / अपवाद को संभालने के लिए कुछ संकेत:

  1. क्रियाकलापों और अनुप्रयोगों में विधियां हैं:

    • onLowMemory
    • onTrimMemory स्मृति उपयोग पर देखने के लिए इन तरीकों को संभाल लें।
  2. मेनिफेस्ट में टैग में 'bigHeap' विशेषता को TRUE पर सेट किया जा सकता है, जो ऐप सैंडबॉक्स के लिए अधिक ढेर का अनुरोध करता है।

  3. इन-मेमोरी कैशिंग और डिस्क कैशिंग का प्रबंधन:

    • ऐप चलते समय छवियों और अन्य डेटा को स्मृति में कैश किया जा सकता था, (स्थानीय रूप से गतिविधियों / खंड और वैश्विक स्तर पर); प्रबंधित या हटाया जाना चाहिए।
  4. विशेष रूप से फ़ाइलों के लिए, जावा इंस्टेंस निर्माण की सॉफ़्ट रेफरेंस, वीक रेफरेंस का उपयोग।

  5. यदि इतनी सारी छवियां हैं, तो उचित लाइब्रेरी / डेटा संरचना का उपयोग करें जो स्मृति का प्रबंधन कर सकते हैं, लोड की गई छवियों के नमूने का उपयोग करें, डिस्क-कैशिंग को संभाल लें।

  6. आउटऑफमेमरी अपवाद को संभालें

  7. कोडिंग के लिए सर्वोत्तम प्रथाओं का पालन करें

    • स्मृति की लीक (मजबूत संदर्भ के साथ सब कुछ पकड़ो मत)
  8. गतिविधि स्टैक को कम करें जैसे स्टैक में गतिविधियों की संख्या (संदर्भ / सक्रियता पर सबकुछ न रखें)

    • संदर्भ समझ में आता है, उन आंकड़ों / उदाहरणों को दायरे (गतिविधि और टुकड़े) से बाहर की आवश्यकता नहीं है, उन्हें वैश्विक संदर्भ-धारण के बजाय उपयुक्त संदर्भ में रखें।
  9. सांख्यिकी, कई और सिंगलेट्स के उपयोग को कम करें।

  10. ओएस मूल मेमोरी फंडमैटल्स का ख्याल रखना

    • मेमोरी विखंडन मुद्दे
  11. Involk GC.Collect () मैन्युअल रूप से कभी-कभी जब आप सुनिश्चित होते हैं कि मेमोरी कैशिंग में और आवश्यकता नहीं है।


आप ढेर आकार में गतिशील रूप से वृद्धि नहीं कर सकते हैं लेकिन आप उपयोग करके अधिक उपयोग करने का अनुरोध कर सकते हैं।

एंड्रॉयड: largeHeap = "true"

manifest.xml , आप इन पंक्तियों में अपनी उपस्थिति में जोड़ सकते हैं यह कुछ स्थितियों के लिए काम कर रहा है।

<application
    android:allowBackup="true"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:largeHeap="true"
    android:supportsRtl="true"
    android:theme="@style/AppTheme">

चाहे आपके आवेदन की प्रक्रियाओं को बड़े दलविक ढेर के साथ बनाया जाना चाहिए। यह एप्लिकेशन के लिए बनाई गई सभी प्रक्रियाओं पर लागू होता है। यह केवल एक प्रक्रिया में लोड किए गए पहले आवेदन पर लागू होता है; यदि आप एक साझा उपयोगकर्ता आईडी का उपयोग कर रहे हैं ताकि एकाधिक अनुप्रयोगों को किसी प्रक्रिया का उपयोग करने की अनुमति मिल सके, तो उन्हें सभी को लगातार इस विकल्प का उपयोग करना होगा या उनके पास अप्रत्याशित परिणाम होंगे। अधिकांश ऐप्स को इसकी आवश्यकता नहीं होनी चाहिए और इसके बजाय बेहतर प्रदर्शन के लिए अपने समग्र स्मृति उपयोग को कम करने पर ध्यान देना चाहिए। इसे सक्षम करने से उपलब्ध स्मृति में निश्चित वृद्धि की गारंटी नहीं है, क्योंकि कुछ डिवाइस उनकी कुल उपलब्ध स्मृति से बाधित हैं।

रनटाइम पर उपलब्ध मेमोरी आकार से getMemoryClass() लिए, getMemoryClass() या getLargeMemoryClass() विधियों का उपयोग करें।

यदि अभी भी समस्या का सामना करना पड़ रहा है तो यह भी काम करना चाहिए

 BitmapFactory.Options options = new BitmapFactory.Options();
 options.inSampleSize = 8;
 mBitmapInsurance = BitmapFactory.decodeFile(mCurrentPhotoPath,options);

यदि मान> 1 पर सेट किया गया है, तो डीकोडर को मूल छवि को कम करने के लिए अनुरोध करें, स्मृति को सहेजने के लिए एक छोटी छवि लौटाएं।

यह छवि प्रदर्शित करने की गति के संबंध में BitmapFactory.Options.inSampleSize का इष्टतम उपयोग है। दस्तावेज उन मानों का उपयोग करता है जो 2 की शक्ति हैं, इसलिए मैं 2, 4, 8, 16 आदि के साथ काम कर रहा हूं।

चलिए छवि नमूनाकरण के लिए और अधिक गहराई से मिलता है:

उदाहरण के लिए, 1024x768 पिक्सेल छवि को स्मृति में लोड करने के लायक नहीं है अगर यह अंततः एक ImageView में 128x128 पिक्सेल थंबनेल में प्रदर्शित किया जाएगा।

डीकोडर को छवि को कम करने के लिए, स्मृति में एक छोटा संस्करण लोड करने के लिए, अपने BitmapFactory.Options ऑब्जेक्ट में inSampleSize में true में सेट करें। उदाहरण के लिए, संकल्प 2100 x 1500 पिक्सल वाली एक छवि जिसे 4 में inSampleSize के साथ डीकोड किया गया है, लगभग inSampleSize का बिटमैप उत्पन्न करता है। इसे मेमोरी में लोड करना पूरी छवि के लिए 12 एमबी की बजाय 0.75 एमबी का उपयोग करता है ( ARGB_8888 की बिटमैप कॉन्फ़िगरेशन मानते हुए)। नमूना आकार मान की गणना करने के लिए यहां एक विधि है जो लक्ष्य चौड़ाई और ऊंचाई के आधार पर दो की शक्ति है:

public static int calculateInSampleSize(
        BitmapFactory.Options options, int reqWidth, int reqHeight) {
    // Raw height and width of image
    final int height = options.outHeight;
    final int width = options.outWidth;
    int inSampleSize = 1;

    if (height > reqHeight || width > reqWidth) {

        final int halfHeight = height / 2;
        final int halfWidth = width / 2;

        // Calculate the largest inSampleSize value that is a power of 2 and keeps both
        // height and width larger than the requested height and width.
        while ((halfHeight / inSampleSize) > reqHeight
                && (halfWidth / inSampleSize) > reqWidth) {
            inSampleSize *= 2;
        }
    }

    return inSampleSize;
}

नोट : दो मानों की एक शक्ति की गणना की जाती है क्योंकि inSampleSize दस्तावेज़ों के अनुसार, inSampleSize दो की नजदीक शक्ति को गोल करके अंतिम मान का उपयोग करता है।

इस विधि का उपयोग करने के लिए, पहले inJustDecodeBounds को true सेट करने के साथ डीकोड करें, विकल्प को पास करें और फिर नए inSampleSize मान का उपयोग करके फिर से डीकोड करें और inJustDecodeBounds को false सेट करें:

public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
    int reqWidth, int reqHeight) {

    // First decode with inJustDecodeBounds=true to check dimensions
    final BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res, resId, options);

    // Calculate inSampleSize
    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);

    // Decode bitmap with inSampleSize set
    options.inJustDecodeBounds = false;
    return BitmapFactory.decodeResource(res, resId, options);
}

यह विधि एक ImageView में मनमाने ढंग से बड़े आकार के बिटमैप को लोड करना आसान बनाता है जो 100x100 पिक्सेल थंबनेल प्रदर्शित करता है, जैसा कि निम्न उदाहरण कोड में दिखाया गया है:

mImageView.setImageBitmap(decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));

आप आवश्यकतानुसार उचित BitmapFactory.decode* विधि को प्रतिस्थापित करके, अन्य स्रोतों से बिटमैप्स को डीकोड करने के लिए एक समान प्रक्रिया का पालन कर सकते हैं।

मैंने यह कोड भी दिलचस्प पाया:

private Bitmap getBitmap(String path) {

Uri uri = getImageUri(path);
InputStream in = null;
try {
    final int IMAGE_MAX_SIZE = 1200000; // 1.2MP
    in = mContentResolver.openInputStream(uri);

    // Decode image size
    BitmapFactory.Options o = new BitmapFactory.Options();
    o.inJustDecodeBounds = true;
    BitmapFactory.decodeStream(in, null, o);
    in.close();

    int scale = 1;
    while ((o.outWidth * o.outHeight) * (1 / Math.pow(scale, 2)) > 
          IMAGE_MAX_SIZE) {
       scale++;
    }
    Log.d(TAG, "scale = " + scale + ", orig-width: " + o.outWidth + ", 
       orig-height: " + o.outHeight);

    Bitmap bitmap = null;
    in = mContentResolver.openInputStream(uri);
    if (scale > 1) {
        scale--;
        // scale to max possible inSampleSize that still yields an image
        // larger than target
        o = new BitmapFactory.Options();
        o.inSampleSize = scale;
        bitmap = BitmapFactory.decodeStream(in, null, o);

        // resize to desired dimensions
        int height = bitmap.getHeight();
        int width = bitmap.getWidth();
        Log.d(TAG, "1th scale operation dimenions - width: " + width + ",
           height: " + height);

        double y = Math.sqrt(IMAGE_MAX_SIZE
                / (((double) width) / height));
        double x = (y / height) * width;

        Bitmap scaledBitmap = Bitmap.createScaledBitmap(bitmap, (int) x, 
           (int) y, true);
        bitmap.recycle();
        bitmap = scaledBitmap;

        System.gc();
    } else {
        bitmap = BitmapFactory.decodeStream(in);
    }
    in.close();

    Log.d(TAG, "bitmap size - width: " +bitmap.getWidth() + ", height: " + 
       bitmap.getHeight());
    return bitmap;
} catch (IOException e) {
    Log.e(TAG, e.getMessage(),e);
    return null;
}

अपनी ऐप की मेमोरी कैसे प्रबंधित करें: link

android:largeHeap="true" का उपयोग करना अच्छा नहीं है android:largeHeap="true" यहां Google से निकाला गया है जो इसे समझाता है,

हालांकि, एक बड़े ढेर का अनुरोध करने की क्षमता केवल ऐप के एक छोटे से सेट के लिए है जो अधिक रैम (जैसे एक बड़ा फोटो संपादन ऐप) उपभोग करने की आवश्यकता को उचित ठहरा सकती है। कभी भी एक बड़ी ढेर का अनुरोध न करें क्योंकि आपने स्मृति से बाहर हो गया है और आपको त्वरित सुधार की आवश्यकता है-आपको केवल तभी इसका उपयोग करना चाहिए जब आप जानते हों कि आपकी सभी मेमोरी आवंटित की जा रही है और इसे क्यों बनाए रखा जाना चाहिए। फिर भी, जब भी आपको विश्वास होता है कि आपका ऐप बड़े ढेर को औचित्य साबित कर सकता है, तो आपको इसे यथासंभव अनुरोध करने से बचना चाहिए। अतिरिक्त मेमोरी का उपयोग तेजी से समग्र उपयोगकर्ता अनुभव के नुकसान के लिए होगा क्योंकि कचरा संग्रह अधिक समय लेगा और कार्य स्विचिंग या अन्य सामान्य संचालन करने पर सिस्टम प्रदर्शन धीमा हो सकता है।

out of memory errors बाद मैं कहूंगा कि ओम मुद्दे से बचने के लिए मैनिफेस्ट में इसे जोड़ना पाप नहीं है

एंड्रॉइड रनटाइम (एआरटी) पर ऐप व्यवहार की पुष्टि

एंड्रॉइड रनटाइम (एआरटी) एंड्रॉइड 5.0 (एपीआई लेवल 21) और उच्चतर वाले डिवाइसों के लिए डिफ़ॉल्ट रनटाइम है। यह रनटाइम कई सुविधाएं प्रदान करता है जो एंड्रॉइड प्लेटफॉर्म और ऐप्स के प्रदर्शन और चिकनीता में सुधार करते हैं। आप एआरटी पेश करने में एआरटी की नई सुविधाओं के बारे में अधिक जानकारी प्राप्त कर सकते हैं।

हालांकि, डाल्विक पर काम करने वाली कुछ तकनीकें एआरटी पर काम नहीं करती हैं। यह दस्तावेज़ आपको एआरटी के साथ संगत होने के लिए मौजूदा ऐप माइग्रेट करते समय देखने के लिए चीजों के बारे में बताता है। एआरटी के साथ चलते समय अधिकांश ऐप्स बस काम करना चाहिए।

कचरा संग्रह (जीसी) मुद्दों को संबोधित करना

डाल्विक के तहत, ऐप्स को अक्सर कचरा संग्रहण (जीसी) संकेत देने के लिए System.gc () को स्पष्ट रूप से कॉल करने में उपयोगी लगता है। यह एआरटी के साथ बहुत कम आवश्यक होना चाहिए, विशेष रूप से यदि आप GC_FOR_ALLOC- प्रकार की घटनाओं को रोकने या विखंडन को कम करने के लिए कचरा संग्रह का आह्वान कर रहे हैं। आप System.getProperty ("java.vm.version") को कॉल करके किस रनटाइम का उपयोग कर सकते हैं, यह सत्यापित कर सकते हैं। यदि एआरटी उपयोग में है, तो संपत्ति का मूल्य "2.0.0" या उच्चतर है।

इसके अलावा, स्मृति प्रबंधन में सुधार के लिए एंड्रॉइड ओपन-सोर्स प्रोजेक्ट (एओएसपी) में एक कॉम्पैक्टिंग कचरा कलेक्टर विकास में है। इस वजह से, आपको उन तकनीकों का उपयोग करने से बचना चाहिए जो जीसी कॉम्पैक्टिंग के साथ असंगत हैं (जैसे पॉइंटर्स को ऑब्जेक्ट डेटा ऑब्जेक्ट करना)। यह उन ऐप्स के लिए विशेष रूप से महत्वपूर्ण है जो जावा मूल इंटरफ़ेस (जेएनआई) का उपयोग करते हैं। अधिक जानकारी के लिए, जेएनआई मुद्दों को रोकना देखें।

जेएनआई मुद्दों को रोकना

एआरटी का जेएनआई दलविक की तुलना में कुछ हद तक कठोर है। आम समस्याओं को पकड़ने के लिए चेकजेएनआई मोड का उपयोग करना एक विशेष रूप से अच्छा विचार है। यदि आपका ऐप सी / सी ++ कोड का उपयोग करता है, तो आपको निम्न आलेख की समीक्षा करनी चाहिए:

इसके अलावा, आप मूल स्मृति ( NDK और JNI ) का उपयोग कर सकते हैं, इसलिए आप वास्तव में ढेर आकार सीमा को बाईपास करते हैं।

इसके बारे में कुछ पोस्ट यहां दी गई हैं:

और यहां इसके लिए बनाई गई लाइब्रेरी है:


मैं केवल दो विकल्प देखता हूं:

  1. आपके आवेदन में मेमोरी लीक है।
  2. आपके आवेदन को चलाने पर डिवाइस में पर्याप्त स्मृति नहीं है।




setbackground