1. 初识Android Profiler内存泄漏的CT扫描仪每次遇到应用卡顿、闪退十有八九是内存泄漏在作祟。Android Profiler就像给应用做CT扫描的仪器能清晰看到内存里的病灶。我刚开始用的时候总把它当成高级版的任务管理器后来才发现它的强大之处远超想象。内存泄漏的典型症状就像家里漏水的水龙头——应用退出后本该释放的内存却顽固地留在那里。最头疼的是第三方库的泄漏去年我用过一个沉浸式状态栏库就因为静态Map持有Activity引用导致每次打开新页面内存就涨10MB用户来回切换几次应用就直接OOM崩溃。打开Profiler很简单点击Android Studio右下角的Profile图标长得像心电图那个选择你的设备和应用进程。第一次看到内存曲线时我有点懵后来发现关键看三个点Java Heap应用对象的主战场Native HeapBitmap等原生内存GraphicsGPU相关内存// 典型的内存泄漏代码示例Handler持有Activity引用 public class LeakyActivity extends Activity { private Handler mHandler new Handler() { Override public void handleMessage(Message msg) { // 即使Activity销毁这个Handler仍然存活 } }; }2. 实战演练揪出四大典型内存泄漏2.1 Handler引发的血案上周排查过一个电商应用的首页泄漏退出页面后内存居高不下。用Profiler抓取堆转储后按照包名过滤发现十几个Activity实例。点开引用链一看果然又是Handler的老套路。解决方法其实很简单用静态内部类弱引用就能破局private static class SafeHandler extends Handler { private WeakReferenceActivity mActivityRef; SafeHandler(Activity activity) { mActivityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { Activity activity mActivityRef.get(); if (activity null || activity.isFinishing()) return; // 处理消息 } }2.2 静态变量的陷阱有个天气应用在后台运行时内存暴涨Profiler显示是单例类持有了Context。这种问题最隐蔽因为静态变量的生命周期和应用进程一样长。我见过最夸张的情况是一个静态工具类缓存了Bitmap导致200多张图片常驻内存。正确做法应该是用ApplicationContext代替ActivityContext及时清理缓存对大数据集使用WeakReferenceobject ImageLoader { private val weakCache mutableMapOfString, WeakReferenceBitmap() fun load(url: String): Bitmap? { return weakCache[url]?.get() ?: run { // 网络加载逻辑 val bitmap loadFromNetwork(url) weakCache[url] WeakReference(bitmap) bitmap } } }2.3 第三方库的暗坑去年接入某广告SDK时发现每次展示广告后就有4MB内存无法回收。用Profiler的Show activity/fragment leaks过滤后发现是他们的NativeAdView没有正确释放。这种问题最难搞因为源码不可控。我的解决方案是升级到最新版SDK在Activity的onDestroy中手动调用SDK的释放方法用包装类隔离风险public class SafeAdWrapper { private NativeAd nativeAd; void bind(Activity activity) { // 初始化广告 } void destroy() { if (nativeAd ! null) { nativeAd.destroy(); nativeAd null; } } }2.4 Fragment的幽灵引用在ViewPager中使用Fragment时经常因为View被持有导致Fragment无法释放。有个阅读应用就因为这个泄漏了所有浏览历史页面。通过Profiler的引用树可以看到是某个TextView被静态工具类间接引用。解决方法包括避免在Fragment中使用非静态内部类在onDestroyView中清空View引用使用FragmentStatePagerAdapter3. Profiler高级排查技巧3.1 堆转储分析三板斧强制GC后抓取先点垃圾桶图标等内存曲线稳定再抓堆转储按包名过滤在Arrange by选择Package快速定位自家代码查看Retained Size这个指标表示对象实际占用的内存大小我发现很多开发者只看Shallow Size对象自身大小其实Retained Size更重要。比如一个只有几十字节的Listener如果持有Activity引用它的Retained Size可能是几MB。3.2 内存增长对比法操作前抓一次堆转储基准线执行可疑操作如打开/关闭页面操作后抓第二次堆转储用Android Studio的对比功能分析差异这个方法特别适合排查列表滑动时的内存增长问题。有次我发现RecyclerView每滑动一屏就泄漏2MB对比后发现是图片加载库的缓存策略有问题。3.3 追踪临时对象分配点击Profiler内存面板的Record allocations按钮可以实时监控对象创建查看哪些方法分配了大量对象发现意外的字符串拼接定位重复创建的临时对象// 优化前每次调用都new StringBuilder void log(String msg) { StringBuilder sb new StringBuilder(); sb.append([TAG]).append(msg); Log.d(sb.toString()); } // 优化后复用静态StringBuilder private static StringBuilder sBuilder new StringBuilder(); void log(String msg) { synchronized (sBuilder) { sBuilder.setLength(0); sBuilder.append([TAG]).append(msg); Log.d(sBuilder.toString()); } }4. 构建内存安全防线4.1 代码审查清单我团队现在强制要求CR时检查这些点[ ] 非静态内部类持有外部类引用[ ] 静态集合未清理[ ] 未取消注册的监听器[ ] 未关闭的Cursor/Stream[ ] 单例持有Context4.2 自动化检测方案LeakCanary集成后自动检测Activity/Fragment泄漏单元测试模拟Activity生命周期验证对象释放CI流水线设置内存阈值超标即失败// build.gradle配置LeakCanary dependencies { debugImplementation com.squareup.leakcanary:leakcanary-android:2.12 }4.3 性能监控体系我们在生产环境搭建了这样的监控关键页面退出时的内存快照OOM异常自动上报堆信息定期统计各机型内存使用百分位有次线上出现OOM率飙升通过分析上报的堆转储数据发现是某个新机型上的WebView存在内存泄漏及时回滚了相关改动。