Android内存不足：切换带ImageView的Activity内存只增不减求助

Hey there! Let's dive into your OutOfMemory problem—this is a super common pain point when dealing with images in Android, so let's break down what might be going wrong and how to fix it without relying on finishAffinity().

Possible Mistakes You Might Be Making #

• Not cleaning up ImageView resources properly: If you're loading bitmaps directly (without a library) and don't explicitly release them when the Activity is destroyed, those bitmaps can hang around in memory, preventing the Activity from being garbage-collected (GC'd).
• Loading uncompressed large images: Using setImageResource() directly on large drawables forces the system to load the full-size bitmap into memory, even if your ImageView is much smaller. This eats up memory fast, especially when switching between Activities.
• Memory leaks from unintended references: Things like anonymous inner classes (e.g., a Runnable or Handler inside your Activity), static references to the Activity, or even not unregistering listeners can keep your Activity instance alive long after it should be destroyed.
• Unnecessary Activity instances: If you're using non-standard launch modes (like singleInstance or singleTask incorrectly), you might be creating multiple instances of your Activities instead of reusing or destroying old ones.

Fixes to Try (No finishAffinity() Needed) #

1. Explicitly Clean Up ImageView Resources in onDestroy() #

When an Activity is destroyed, make sure you're releasing the bitmap held by your ImageView to let GC do its job. Add this to each of your Activities:

@Override
protected void onDestroy() {
    super.onDestroy();
    // Clear the ImageView's reference to the drawable/bitmap
    if (yourImageView != null) {
        yourImageView.setImageDrawable(null);
        yourImageView.setImageBitmap(null);
    }
    // If you're holding a direct reference to a Bitmap, recycle it too
    if (yourBitmap != null && !yourBitmap.isRecycled()) {
        yourBitmap.recycle();
        yourBitmap = null;
    }
}

2. Use an Image Loading Library (Glide/Picasso) #

These libraries handle image compression, memory caching, and automatic resource cleanup out of the box—they're designed to prevent exactly this kind of memory issue. For example, with Glide:

Glide.with(this)
     .load(R.drawable.your_image) // Or a URL, file, etc.
     .centerCrop() // Or fitCenter(), adjust to your needs
     .into(yourImageView);

Glide automatically scales the image to match your ImageView's size and releases resources when the Activity is destroyed.

3. Check for Memory Leaks with Android Profiler #

Fire up Android Studio's Memory Profiler to take a heap dump after switching between Activities. Look for instances of your Activities that shouldn't exist—this will tell you if something is holding a reference to them. Common culprits:

• Handler with pending messages: Make sure to call handler.removeCallbacksAndMessages(null) in onDestroy().
• Static variables referencing the Activity: Replace static references with weak references if you need to keep one.
• Unregistered broadcast receivers/listeners: Always unregister these in onDestroy().

4. Compress Images Manually (If You Don't Want to Use a Library) #

If you need to load bitmaps without a library, resize them to match your ImageView's dimensions first. Here's a helper method to do that:

private Bitmap decodeSampledBitmap(Resources res, int resId, int targetWidth, int targetHeight) {
    // First decode with inJustDecodeBounds=true to get image dimensions
    final BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res, resId, options);

    // Calculate inSampleSize
    options.inSampleSize = calculateSampleSize(options, targetWidth, targetHeight);

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

private int calculateSampleSize(BitmapFactory.Options options, int targetWidth, int targetHeight) {
    final int height = options.outHeight;
    final int width = options.outWidth;
    int sampleSize = 1;

    if (height > targetHeight || width > targetWidth) {
        final int halfHeight = height / 2;
        final int halfWidth = width / 2;
        // Find the largest sample size that is a power of 2 and keeps both
        // height and width larger than the requested height and width.
        while ((halfHeight / sampleSize) >= targetHeight
               && (halfWidth / sampleSize) >= targetWidth) {
            sampleSize *= 2;
        }
    }
    return sampleSize;
}

Then load the bitmap like this:

int imageViewWidth = yourImageView.getWidth();
int imageViewHeight = yourImageView.getHeight();
Bitmap compressedBitmap = decodeSampledBitmap(getResources(), R.drawable.your_image, imageViewWidth, imageViewHeight);
yourImageView.setImageBitmap(compressedBitmap);

5. Verify Your Activity Launch Modes #

Double-check your AndroidManifest.xml to make sure you're using appropriate launch modes. For most cases, the default standard mode is fine—avoid singleInstance unless you specifically need it, as it can keep Activities alive in a separate task stack.

Why finishAffinity() Causes Lag on Your Tablet #

finishAffinity() destroys all Activities in your app's task stack, which means when you open a new Activity later, the system has to recreate all the previous ones (if needed) from scratch. On lower-performance tablets, this reinitialization and resource loading can cause noticeable lag—so avoiding it is definitely the right call.

内容的提问来源于stack exchange，提问作者Dim