第5章内存抖动与卡顿

课程目录第5章内存抖动与卡顿

内存抖动与卡顿：从原理到实战

内存抖动，说白了就是你的App在短时间内频繁地创建和回收对象。嗯，这听起来好像没什么大不了的？但如果你经历过用户滑动列表时一卡一卡的，或者打开某个页面突然掉帧，那八成就是内存抖动在搞鬼。

我个人习惯把内存抖动比作「厨房里反复开关冰箱门」——每次开关都会消耗能量，频繁操作就会让整个系统不堪重负。在Android世界里，这个「冰箱」就是GC（垃圾回收器）。

内存抖动的产生原理

为什么会发生内存抖动？核心原因只有一个：频繁创建短生命周期对象。

你想想看，每次创建一个对象，JVM就要在堆上分配一块内存。当这些对象很快变成垃圾，GC就要来回收。如果这个频率太高——比如在onDraw()里new Paint()，或者在getView()里new ArrayList()——GC就会被频繁触发。

我在项目中遇到过这样一个案例：一个列表页，滑动时每秒创建上千个临时对象。结果GC被触发了十几次，每次GC都会暂停UI线程几十毫秒。用户滑一下卡一下，体验极差。

  核心结论：内存抖动的本质是「分配速度 > 回收速度」，导致GC频繁执行，进而引发UI卡顿。

Allocation Tracker与Profile分析

怎么定位内存抖动？工具是关键。我个人最常用的是Android Studio自带的Memory Profiler和Allocation Tracker。

Memory Profiler使用技巧

打开Profiler，选择Memory标签
录制一段操作（比如滑动列表）
观察内存曲线——如果出现「锯齿状」波动，说明有内存抖动
点击「Dump Java Heap」查看对象分布

这里有个小技巧：不要只看总内存，要看分配速率。如果每秒分配超过10MB，基本可以断定有内存抖动问题。

Allocation Tracker实战

Allocation Tracker能精确记录每个对象的创建位置。我曾经用它定位到一个隐藏很深的问题：一个第三方图片库在decode时频繁创建Bitmap.Config对象，导致列表滑动卡顿。

// 典型的内存抖动代码
public View getView(int position, View convertView, ViewGroup parent) {
    // 错误：每次调用都创建新对象
    Paint paint = new Paint();
    Rect rect = new Rect();
    // ... 使用paint和rect
    return view;
}

// 优化后：复用对象
private Paint mPaint = new Paint();
private Rect mRect = new Rect();

public View getView(int position, View convertView, ViewGroup parent) {
    // 复用已有对象
    mPaint.reset();
    mRect.set(0, 0, 100, 100);
    // ... 使用mPaint和mRect
    return view;
}

避坑指南：我曾经在优化时犯过一个错误——只关注了对象数量，没关注对象大小。有时候一个大的Bitmap对象比一百个小对象更致命。所以分析时一定要看「分配大小」和「分配次数」两个维度。

对象池与享元模式优化

解决内存抖动，最有效的两个武器就是对象池和享元模式。说白了，就是让对象「活得更久」，避免频繁创建和销毁。

对象池模式

对象池的核心思想：用空间换时间。预先创建一批对象，用完了不销毁，放回池子里下次再用。

public class MessagePool {
    private static final int MAX_POOL_SIZE = 50;
    private final Queue<Message> pool = new ArrayDeque<>(MAX_POOL_SIZE);
    
    public Message obtain() {
        Message msg = pool.poll();
        if (msg == null) {
            msg = new Message();
        }
        return msg;
    }
    
    public void recycle(Message msg) {
        if (pool.size() < MAX_POOL_SIZE) {
            msg.clear(); // 重置状态
            pool.offer(msg);
        }
    }
}

Android系统本身就有很多对象池的例子，比如Handler的Message.obtain()。我建议你在以下场景优先考虑对象池：

频繁创建和销毁的对象（比如列表中的ViewHolder）
创建成本高的对象（比如线程、数据库连接）
短生命周期但数量巨大的对象（比如网络请求的Response）

享元模式

享元模式和对象池有点像，但侧重点不同。享元模式强调的是共享不可变状态，减少重复对象的创建。

举个例子：一个聊天App里，每条消息都有发送时间。如果每条消息都创建一个SimpleDateFormat对象，那内存抖动会很严重。正确的做法是把SimpleDateFormat做成享元，全局共享。

public class DateFormatFactory {
    private static final Map<String, SimpleDateFormat> CACHE = new HashMap<>();
    
    public static SimpleDateFormat getDateFormat(String pattern) {
        SimpleDateFormat sdf = CACHE.get(pattern);
        if (sdf == null) {
            sdf = new SimpleDateFormat(pattern, Locale.getDefault());
            CACHE.put(pattern, sdf);
        }
        return sdf;
    }
}

个人经验：使用享元模式时要注意线程安全问题。SimpleDateFormat本身不是线程安全的，所以要么加锁，要么用ThreadLocal包装。我一般用ThreadLocal，性能更好。

知识体系总览

下面这张图总结了内存抖动的完整知识体系，从问题定位到优化方案，一目了然：

实战建议

最后，我总结几条实战中验证过的建议：

先定位，再优化——不要凭感觉改代码，用Profiler数据说话
关注热点路径——列表滑动、动画回调、触摸事件这些高频调用点最容易出问题
对象池不是万能的——如果对象本身很小（比如Integer），创建成本很低，用对象池反而增加复杂度
注意内存泄漏——对象池里的对象如果没清理干净，可能变成内存泄漏

  一句话总结：内存抖动的本质是「频繁创建+频繁回收」的恶性循环。用对象池和享元模式打破这个循环，你的App就能告别卡顿。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

内存抖动与卡顿：从原理到实战

内存抖动的产生原理

Allocation Tracker与Profile分析

Memory Profiler使用技巧

Allocation Tracker实战

对象池与享元模式优化

对象池模式

享元模式

知识体系总览

实战建议