在 Android 应用开发中，内存泄漏（Memory Leak）是指那些不再被使用的对象由于被其他长生命周期对象错误地持有引用，导致垃圾回收器（GC）无法将其回收。这会逐渐耗尽系统的可用堆内存，最终引发 OutOfMemoryError (OOM) 并导致应用崩溃。由于内存泄漏通常具有隐蔽性，掌握其底层原理并熟练使用排查工具是每位 Android 工程师的必修课。

JVM 运行时内存模型

要理解内存泄漏，首先需要了解 Java 虚拟机（JVM）在执行程序时如何划分和管理内存。JVM 运行时数据区域主要包含以下几个部分：

1. 线程私有区域

• 程序计数器：记录当前线程执行的字节码行号。它是唯一不会发生 OOM 的区域。
• 虚拟机栈：描述 Java 方法执行的内存模型。每个方法执行时会创建一个栈帧，用于存储局部变量表、操作数栈等。若栈深度超限或无法扩展，会抛出 StackOverflowError 或 OutOfMemoryError。
• 本地方法栈：与虚拟机栈类似，但专为 Native 方法服务。

2. 线程共享区域

• Java 堆：JVM 中最大的一块内存，用于存放几乎所有的对象实例和数组。它是 GC 管理的主要区域（分为新生代和老年代）。当堆无法分配新对象且无法扩展时，会抛出 OOM。
• 方法区：存储已被加载的类信息、常量、静态变量以及 JIT 编译后的代码。当方法区无法满足内存分配需求时，同样会抛出 OOM。
• 运行时常量池：方法区的一部分，用于存放编译期生成的字面量和符号引用。

Java 引用类型与垃圾回收

Java 堆中的对象存活与否取决于其引用状态。JDK 提供了四种引用类型，允许开发者更细粒度地控制对象的生命周期，协助 GC 进行内存回收。

强引用 (Strong Reference)

最常见的引用类型。只要强引用存在，GC 绝不会回收该对象，即使内存不足也会直接抛出 OOM。

public class UserProfile {
    private String userId;
}
// currentUser 是一个强引用
UserProfile currentUser = new UserProfile();

软引用 (Soft Reference)

用于描述有用但非必须的对象。当系统内存充足时，GC 不会回收软引用对象；只有在即将发生 OOM 时，才会将其回收。常用于实现内存敏感的缓存机制。

Bitmap cachedBanner = BitmapFactory.decodeResource(getResources(), R.drawable.banner);
SoftReference<Bitmap> bannerCache = new SoftReference<>(cachedBanner);

// 解除强引用，仅保留软引用
cachedBanner = null;

// 尝试获取对象
Bitmap retrievedBanner = bannerCache.get();
if (retrievedBanner != null) {
    // 缓存命中，使用图片
} else {
    // 缓存已被 GC 回收，需重新加载
}

配合 ReferenceQueue 使用，可以及时清理那些指向已被回收对象的 SoftReference 实例，避免引用对象本身的堆积。

弱引用 (Weak Reference)

弱引用的生命周期比软引用更短。无论当前内存是否充足，只要 GC 扫描到只具有弱引用的对象，就会立即回收它。

Context appContext = getApplicationContext();
WeakReference<Context> contextRef = new WeakReference<>(appContext);
appContext = null;

// 下次 GC 运行时，contextRef.get() 将返回 null

虚引用 (Phantom Reference)

最弱的引用类型，完全不影响对象的生命周期。它不能通过 get() 方法获取对象实例，唯一的作用是在对象被 GC 回收时收到系统通知，主要用于跟踪对象的回收活动，且必须与 ReferenceQueue 联合使用。

Android 典型内存泄漏场景剖析

在 Android 开发中，绝大多数的内存泄漏都发生在 Java 堆中。其核心原因通常是：长生命周期的对象持有了短生命周期对象的强引用，导致短生命周期对象（如 Activity、Fragment）在理应被销毁时无法被 GC 回收。

Handler 与匿名内部类引发的泄漏

以下是一个典型的错误示例：

public class OrderDetailActivity extends AppCompatActivity {
    private static final int MSG_UPDATE_STATUS = 1;

    // 匿名内部类隐式持有外部类 (OrderDetailActivity) 的强引用
    private final Handler uiHandler = new Handler(Looper.getMainLooper()) {
        @Override
        public void handleMessage(@NonNull Message msg) {
            if (msg.what == MSG_UPDATE_STATUS) {
                updateOrderStatus((String) msg.obj);
            }
        }
    };

    private void fetchOrderData() {
        new Thread(() -> {
            // 模拟耗时网络请求
            SystemClock.sleep(5000);
            String status = "Delivered";
            uiHandler.sendMessage(uiHandler.obtainMessage(MSG_UPDATE_STATUS, status));
        }).start();
    }
}

泄漏原理：当用户在网络请求完成前退出 OrderDetailActivity 时，Activity 本应被销毁。但由于子线程尚未结束，它持有 uiHandler 的引用，而 uiHandler 作为非静态匿名内部类，又隐式持有了 OrderDetailActivity 的强引用。这条引用链（Thread -> Handler -> Activity）导致 Activity 无法被回收。同理，使用 postDelayed 会将 Message 放入 MessageQueue，Message 持有 Handler，同样会引发泄漏。

内存泄漏的检测与排查

1. 使用 LeakCanary

LeakCanary 是 Android 领域最流行的内存泄漏检测库。只需在 build.gradle 中引入依赖，它会在应用运行时自动监控 Activity、Fragment 等组件的销毁状态。一旦发现对象在预期时间内未被 GC 回收，它会 dump 堆内存并分析引用链，直接在通知栏展示泄漏路径。

2. 使用 Android Studio Profiler

对于复杂的内存问题或需要分析特定时间段的内存分配，Android Profiler 是官方提供的强大工具。

Profiler 的核心功能包括：

• 触发 GC：手动执行垃圾回收，观察内存是否下降。
• Heap Dump：捕获当前堆内存快照，分析具体哪些对象占用了大量内存。
• Record Allocations：记录特定时间段内的内存分配情况，精确定位代码中频繁创建对象或发生泄漏的位置。

在捕获 Heap Dump 后，可以通过 Instance View 查看特定类的实例数量。如果某个 Activity 的实例数异常增加，通常意味着发生了泄漏。

选中可疑实例后，查看其 Call Stack 和 Reference 链，即可顺藤摸瓜找到持有该对象的外部引用。

修复方案与最佳实践

1. 使用静态内部类与弱引用修复 Handler

将 Handler 声明为静态内部类可以切断其对外部类的隐式强引用。若需在 Handler 中操作外部类，可结合弱引用实现：

private static class SafeUiHandler extends Handler {
    private final WeakReference<OrderDetailActivity> activityRef;

    public SafeUiHandler(OrderDetailActivity activity) {
        super(Looper.getMainLooper());
        this.activityRef = new WeakReference<>(activity);
    }

    @Override
    public void handleMessage(@NonNull Message msg) {
        OrderDetailActivity activity = activityRef.get();
        // 确保 Activity 未被回收且未处于 Finishing 状态
        if (activity == null || activity.isFinishing()) {
            return;
        }
        
        if (msg.what == MSG_UPDATE_STATUS) {
            activity.updateOrderStatus((String) msg.obj);
        }
    }
}

// 在 Activity 中初始化
private SafeUiHandler safeHandler;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    safeHandler = new SafeUiHandler(this);
}

2. 生命周期内的资源清理

即使使用了弱引用，为了避免不必要的消息处理和潜在的逻辑错误，应当在组件销毁时主动清理 MessageQueue 中的消息：

@Override
protected void onDestroy() {
    super.onDestroy();
    if (safeHandler != null) {
        // 移除所有待处理的 Callbacks 和 Messages
        safeHandler.removeCallbacksAndMessages(null);
    }
}

3. 图片缓存的优化

在处理大量图片加载时，避免将所有 Bitmap 直接存入内存。可以使用 LruCache 结合软引用或直接依赖成熟的图片加载库（如 Glide、Coil），这些库内部已经实现了完善的内存管理与 Bitmap 复用机制，从根本上杜绝了因图片加载导致的 OOM 问题。