22、Launcher的内存优化：Bitmap内存管理、对象池与复用、LeakCanary检测内存泄漏

Launcher 这东西，说白了就是 Android 系统的门面。用户每天解锁手机，第一眼看到的就是它。如果 Launcher 卡顿、闪退、或者内存占用越来越高，那体验感直接归零。

我在做 Launcher 开发的时候，遇到过最头疼的问题就是内存泄漏。明明只是滑了几下桌面，内存却蹭蹭往上涨，最后被系统杀掉。嗯，今天我们就来聊聊 Launcher 内存优化的三个核心方向：Bitmap 管理、对象池复用、以及如何用 LeakCanary 揪出内存泄漏。

一、Bitmap 内存管理：Launcher 的吃内存大户

Launcher 里什么最占内存？毫无疑问是图标和壁纸。一张高清壁纸可能就占 10MB+，再加上几十个应用图标，内存压力非常大。

我个人习惯把 Bitmap 管理分成三个层面：加载、缓存、释放。

1.1 加载：按需加载，别一股脑全塞进去

Launcher 启动时，不要把所有图标都加载到内存里。你想想看，用户可能装了 200 个应用，但当前屏幕只显示 20 个。剩下的 180 个图标，等用户滑到那一屏再加载也不迟。

// 示例：按需加载图标
public class IconLoader {
    private LruCache<String, Bitmap> iconCache;
    
    public Bitmap loadIcon(String packageName, int targetSize) {
        // 先从缓存取
        Bitmap cached = iconCache.get(packageName);
        if (cached != null) return cached;
        
        // 没有缓存，再加载
        Bitmap original = getAppIcon(packageName);
        Bitmap scaled = Bitmap.createScaledBitmap(original, targetSize, targetSize, true);
        
        // 记得回收原图
        if (original != scaled) {
            original.recycle();
        }
        
        iconCache.put(packageName, scaled);
        return scaled;
    }
}

1.2 缓存：LruCache 的正确用法

缓存不是越大越好。我见过有人把 LruCache 设成 100MB，结果 Launcher 一启动就被系统杀了。为什么？因为系统给每个 App 的内存上限是有限的，你一个人吃太多，别人就没得吃了。

我建议这样算缓存大小：

设备类型	建议缓存大小	说明
低端机（1GB RAM）	8MB - 12MB	只缓存当前屏和相邻屏的图标
中端机（2-3GB RAM）	16MB - 24MB	可缓存 3-5 屏的图标
高端机（4GB+ RAM）	32MB - 48MB	基本覆盖所有图标

1.3 释放：及时回收，别等 GC

我曾经踩过一个坑：壁纸切换时，旧的 Bitmap 没有及时回收，导致内存瞬间飙升。后来我加了一个监听器，在壁纸切换完成后立即回收旧图。

// 壁纸切换时的内存管理
public void onWallpaperChanged(Bitmap newWallpaper) {
    // 先保存新壁纸
    Bitmap oldWallpaper = this.currentWallpaper;
    this.currentWallpaper = newWallpaper;
    
    // 再回收旧壁纸
    if (oldWallpaper != null && !oldWallpaper.isRecycled()) {
        oldWallpaper.recycle();
        oldWallpaper = null;
    }
    
    // 触发一次 GC 提示（不是强制 GC）
    System.gc();
}

二、对象池与复用：减少创建就是减少 GC

Launcher 里有很多频繁创建的对象，比如触摸事件、动画插值器、布局参数等。每次创建新对象都会触发 GC，GC 一多，界面就卡顿。

我建议用对象池来解决这个问题。说白了，就是创建一个「对象仓库」，用完了还回去，下次再用直接从仓库取，不用 new。

2.1 实现一个简单的对象池

public class ObjectPool<T> {
    private final Stack<T> pool = new Stack<>();
    private final Factory<T> factory;
    private final int maxSize;
    
    public ObjectPool(Factory<T> factory, int maxSize) {
        this.factory = factory;
        this.maxSize = maxSize;
    }
    
    public T obtain() {
        if (pool.isEmpty()) {
            return factory.create();
        }
        return pool.pop();
    }
    
    public void recycle(T object) {
        if (pool.size() < maxSize) {
            pool.push(object);
        }
    }
    
    public interface Factory<T> {
        T create();
    }
}

2.2 在 Launcher 中的应用场景

我举个实际例子：Launcher 的拖拽操作。用户长按图标然后拖动，这个过程中会创建大量的 DragView 和动画对象。如果不复用，每拖一次就 new 一堆对象，内存和性能都扛不住。

// 拖拽视图的对象池
public class DragViewPool {
    private static final int MAX_POOL_SIZE = 5;
    private final ObjectPool<DragView> pool;
    
    public DragViewPool() {
        pool = new ObjectPool<>(() -> new DragView(getContext()), MAX_POOL_SIZE);
    }
    
    public DragView obtainDragView() {
        DragView view = pool.obtain();
        // 重置状态
        view.reset();
        return view;
    }
    
    public void recycleDragView(DragView view) {
        // 清理资源
        view.clearAnimation();
        view.setImageDrawable(null);
        pool.recycle(view);
    }
}

三、LeakCanary 检测内存泄漏：让问题无处遁形

内存泄漏是 Launcher 的隐形杀手。它不会立刻 Crash，但会慢慢吃掉你的内存，直到系统忍无可忍把你杀掉。

我强烈推荐使用 LeakCanary 来检测内存泄漏。这工具就像个侦探，能帮你找到谁在「霸占」着本该释放的对象不放。

3.1 集成 LeakCanary

// 在 Application 中初始化
public class LauncherApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // 如果当前进程是 LeakCanary 的分析进程，直接返回
            return;
        }
        
        LeakCanary.config()
            .watchDurationMillis(5000)  // 观察 5 秒
            .maxStoredHeapDumps(3)      // 最多保存 3 个堆转储
            .install();
    }
}

3.2 Launcher 中常见的内存泄漏场景

我整理了几个在 Launcher 开发中经常遇到的泄漏场景：

• 静态变量持有 Activity 引用：比如把 Launcher 的 Context 赋值给一个静态变量，Activity 销毁后无法被 GC。
• 内部类隐式持有外部类引用：匿名内部类或非静态内部类，会隐式持有外部类的引用。如果内部类生命周期比外部类长，就会泄漏。
• Handler 未移除：发送了延迟消息，但 Activity 已经销毁了。Handler 里的 Message 持有 Handler 引用，Handler 又持有 Activity 引用，形成泄漏链。
• 注册的监听器未注销：比如注册了 ContentObserver、BroadcastReceiver，但忘记在 onDestroy 中注销。

3.3 实战：用 LeakCanary 定位泄漏

我记得有一次，Launcher 在横竖屏切换时内存一直涨。用 LeakCanary 一查，发现是 IconCache 里的一个静态 HashMap 泄漏了。原来是在横竖屏切换时，旧的 Activity 被缓存中的某个对象持有了引用，导致无法释放。

// 泄漏的代码（错误示例）
public class IconCache {
    private static Map<String, Bitmap> sCache = new HashMap<>();
    private Context mContext;  // 这里泄漏了！
    
    public IconCache(Context context) {
        this.mContext = context;
    }
}

// 修复后的代码
public class IconCache {
    private static Map<String, Bitmap> sCache = new HashMap<>();
    private WeakReference<Context> mContextRef;  // 使用弱引用
    
    public IconCache(Context context) {
        this.mContextRef = new WeakReference<>(context);
    }
}

四、知识体系总览

下面这张图总结了 Launcher 内存优化的核心逻辑，你可以把它当作一个检查清单：

你看，这三个方向其实是环环相扣的。Bitmap 管理解决的是「大对象」的内存问题，对象池解决的是「小对象」频繁创建的问题，而 LeakCanary 则是帮你查漏补缺，确保没有「僵尸对象」霸占内存。

在实际项目中，我建议你先把 LeakCanary 集成进去，跑一遍看看有没有泄漏。然后再逐步优化 Bitmap 和对象池。别想着一步到位，内存优化是个持续的过程。