告别卡顿：Android 内存优化实战指南

为什么你的 App 会卡顿？

在 Android 开发中，内存管理是性能优化的核心。当系统内存不足时，会触发 垃圾回收（GC），GC 会暂停所有线程（包括 UI 线程），导致丢帧、卡顿甚至 ANR。更严重的内存泄漏会让可用堆内存持续萎缩，最终引发 OutOfMemoryError (OOM)。据 Google 统计，超过 30% 的 ANR 与内存问题直接相关。

本文不堆砌理论，而是直接给出 6 个可落地的优化策略，配合工具使用，让内存优化不再是玄学。

一、精准定位内存问题：工具链实战

1. Android Profiler：实时监控

打开 Android Studio 的 View > Tool Windows > Profiler，选择你的进程。重点关注 Memory 面板：

• Java Heap：查看各类对象的数量与大小。
• Allocations：跟踪对象的分配堆栈，找出频繁创建大对象的代码段。
• GC 事件：观察 GC 频率，如果每 2-3 秒发生一次，说明内存压力很大。

2. LeakCanary：傻瓜式泄漏检测

集成 com.squareup.leakcanary:leakcanary-android 后，一旦发生泄漏，通知栏会自动弹出提示。点击即可看到完整的引用链，比如：

静态变量持有的 Activity -> 未取消注册的 BroadcastReceiver -> 匿名内部类的 Activity 引用

这种“谁引用了谁”的路径，能帮助你快速修复。

二、六大内存优化策略

1. 严防静态变量持有 Activity

问题场景：在 Activity 中定义一个 static Context 或 static View，导致 Activity 无法被回收。

解决方案：

• 使用 Application Context 代替 Activity Context 的场景（如 Toast、SharedPreferences）。
• 对于需要频繁使用的 View，使用 WeakReference 包装。
• LeakCanary 中常见的 View.onAttachedToWindow 泄漏，往往是因为 View 被静态引用。

2. 及时注销监听器与回调

动态注册的 BroadcastReceiver、ContentObserver、SensorEventListener 等，如果未在 onDestroy 中注销，会导致 Activity 被间接持有。

最佳实践：总是在 onPause 或 onStop 中反注册，或者在 onDestroy 中统一清理。推荐使用 RxLifecycle 等自动管理生命周期的库。

3. Handler 与内部类的陷阱

匿名内部类或非静态内部类默认持有外部类（如 Activity）的引用。如果 Handler 中的 Message 被延迟处理，Activity 销毁后仍被引用，造成泄漏。

修复方法：

• 将 Handler 定义为 静态 内部类，并使用 WeakReference 持有 Activity。
• 在 onDestroy 中调用 Handler.removeCallbacksAndMessages(null) 清除所有 Message。

public static class SafeHandler extends Handler {
    private WeakReference ref;
    public SafeHandler(Activity activity) { ref = new WeakReference(activity); }
    @Override public void handleMessage(Message msg) {
        Activity act = ref.get();
        if (act != null) { /* 正常处理 */ }
    }
}

4. Bitmap 优化：内存大户的瘦身

一张 1920×1080 的图片使用 ARGB_8888 格式会占用 1920×1080×4 ≈ 7.9 MB 内存。如果不做缩放，加载多张图就会 OOM。

• 采样压缩：使用 BitmapFactory.Options.inSampleSize 按比例缩小图片。
• 使用 RGB_565：对于不需要透明通道的图片，改为此格式（每个像素 2 字节）。
• 复用 inBitmap：Android 3.0+ 支持重用已有 Bitmap 的内存块，减少分配。
• 三级缓存：配合 Glide 或 Coil，利用内存缓存 + 磁盘缓存 + 网络加载。

5. 使用 SparseArray 替代 HashMap<Integer, Object>

HashMap<Integer, V> 会创建大量的 Integer 对象（自动装箱），而 SparseArray 使用原始 int 作为键，避免了装箱开销，内存占用降低约 30%。类似地，ArrayMap 适合少量数据的映射场景。

6. 避免 String 拼接导致的隐式内存浪费

在循环中使用 + 拼接字符串会生成大量临时 String 对象，触发频繁 GC。应使用 StringBuilder 或 StringBuffer：

StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append("item ").append(i);
}
String result = sb.toString();

三、进阶：利用系统 API 减少内存占用

1. 使用 ViewStub 延迟加载

对于不常显示的布局（如列表项的展开详情），用 ViewStub 占位，仅在需要时 inflate，避免从一开始就占用内存。

2. 使用 onTrimMemory 主动释放

在 Activity 或 Fragment 中重写 onTrimMemory(int level)，根据 level（如 TRIM_MEMORY_UI_HIDDEN）释放缓存、图片等资源。

3. 合理使用 Android 架构组件

ViewModel 会自动在 Activity 重建时保留数据，但要注意不要持有大量 Bitmap 或大集合。可以将数据存储在 SavedStateHandle 中，让系统自动序列化。

四、优化效果验证

完成优化后，再次用 Profiler 观察：

• GC 频率应降至每 10-15 秒一次以下。
• 内存抖动（Allocation 峰值）减少。
• LeakCanary 不再弹出泄漏报告。

使用 adb shell dumpsys meminfo your.package.name 对比优化前后的 Native Heap 和 Dalvik Heap 数值，一般可减少 20%~40% 的内存占用。

总结

内存优化不是一次性的工作，而应贯穿开发全流程。从编码规范（避免静态泄漏、及时注销）到工具检测（Profiler + LeakCanary），再到专项优化（Bitmap、SparseArray），每一点都能为 App 的流畅度加分。建议建立团队的 内存检查清单，在 code review 中逐条对照，从源头扼杀卡顿。