1. 先搞清楚Android 内存泄露到底是怎么发生的Android 内存泄露排查这件事说穿了就一句话本该被 GC 回收的对象被一条看不见的引用链死死拽住。Android 给每个应用分配的堆空间有限早期 Dalvik 只有 16M现在虽然大了不少但也不是无限的一旦 Activity、Fragment、Bitmap 这类大块头对象被泄露堆就会越吃越满最后直接抛OutOfMemoryError。我在实际项目里遇到的泄露八成集中在这么几个场景静态变量持有 Context、非静态内部类Handler、Thread、AsyncTask隐式持有外部 Activity、单例把 Activity 当参数存下来、监听器/广播注册了没反注册、Cursor 和 IO 流忘了 close。这些问题的共同点是——代码看起来完全正常跑起来也不报错只有内存曲线在悄悄往上爬。这篇就按定位 → 分析 → 修复 → 验证的完整链路走一遍前半段讲怎么用 Logcat 和 Memory Profiler 把泄露点揪出来后半段给你一套可复制的排查清单以及用 TaoToken 统一 Key 配置把 AI 辅助排查接进工作流的骨架settings.json / config.toml。适合已经写过 Android、但被 OOM 和内存曲线折磨过的同学。2. 用 Logcat Memory Profiler 定位泄露点2.1 先让 Logcat 帮你抓 GC 的求救信号很多人不知道Logcat 里其实一直有 GC 的日志只是被淹没了。在 Android Studio 的 Logcat 过滤框里输入tag:art | tag:dalvikvm你会看到类似这样的行I/art: Background sticky concurrent mark sweep GC freed 24576(1024KB) AllocSpace objects, 12(384KB) LOS objects, 18% free, 12MB/24MB, paused 1.2ms total 45ms重点看两个数字freed后面的对象数和% free。如果% free长期低于 20%而且每次 GC 释放的量越来越少基本可以判定有对象在持续累积。这时候别急着上 Profiler先在可疑页面反复进出 510 次观察% free是不是阶梯式下降——是的话泄露实锤。2.2 Memory Profiler 抓 Heap Dump 的正确姿势打开 Android Studio 底部的 Profiler → Memory操作顺序很关键进入可疑 Activity等界面稳定点Force garbage collection那个垃圾桶图标触发一次 GC点Capture heap dump等 dump 完成在 dump 结果里按类名搜索你的 Activity比如MainActivity。如果 GC 之后MainActivity的实例数还大于 0说明它没被回收。点开这个实例看References面板从下往上找引用链通常能看到类似这样的路径MainActivity ← MyHandler.this$0 ← MessageQueue.mMessages ← Looper.mQueue ← ThreadLocal (主线程)这条链一眼就能看出是 Handler 泄露。同理如果是静态变量你会看到ClassName.mContext直接指向 Activity。2.3 一个真实案例静态 Drawable 的引用链官方文档里那个经典例子值得再提一次因为它揭示了隐式引用的坑private static Drawable sBackground; Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label new TextView(this); label.setText(Leaks are bad); if (sBackground null) { sBackground getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); }代码里根本没写sBackground this但引用链是Drawable → TextView → Context。在 Android 3.0 之前Drawable.setCallback()存的是强引用所以这个 static Drawable 一直拽着 TextViewTextView 又拽着 Activity。3.0 之后官方把setCallback改成了WeakReference这个问题才被根治。但你自己写的 static 变量可没人帮你改成弱引用这就是为什么排查时一定要看引用链而不是只看代码表面。3. TaoToken 前置把统一 Key 配置接进排查工作流排查内存泄露时我经常需要让 AI 帮忙分析 heap dump 里的引用链、解释某段源码为什么会导致泄露、或者生成修复后的对比代码。如果每次都要手动贴 Key、切模型效率很低。TaoToken 的作用就是把这些 AI 能力收敛到一个统一的 Key 上配置一次编辑器、命令行、脚本都能复用。先拿到 Key访问 TaoToken API Keys 管理页创建一个 Key 并复制。注意这个 Key 只在创建时完整显示一次记得存到安全的地方。TaoToken 的 API 入口是https://taotoken.net/api兼容 OpenAI 风格的调用格式所以大部分支持自定义 base_url 的工具都能直接接。下面给出两种配置骨架你可以按自己用的工具选。4. 可复制配置settings.json 与 config.toml 骨架4.1 VS Code / Cursor 类编辑器的 settings.json如果你用 VS Code 配合 Continue、Cline 这类插件配置通常写在settings.json里。骨架如下{ taotoken.baseUrl: https://taotoken.net/api, taotoken.apiKey: sk-你的TaoTokenKey, taotoken.defaultModel: claude-sonnet-4-20250514, taotoken.timeout: 60000, taotoken.maxTokens: 8192, taotoken.contextWindow: 200000 }几个参数说明baseUrl固定填https://taotoken.net/api不要加多余的路径timeout建议给到 60 秒因为分析 heap dump 文本时响应会比较长maxTokens按你实际需要调分析引用链一般 8K 够用。4.2 命令行工具的 config.toml如果你用 Claude Code 或者类似的 CLI 工具配置一般放在~/.config/下的config.toml[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoTokenKey [model] default claude-sonnet-4-20250514 max_tokens 8192 temperature 0.3 [request] timeout_seconds 60 retry_times 2temperature设低一点0.3 左右因为分析代码和引用链需要的是准确而不是发散。retry_times给 2 次网络抖动时能自动重试。配置完成后你可以直接在命令行里把 heap dump 的文本片段喂给 AI让它帮你梳理引用链。比如cat heap_refs.txt | claude -p 分析这段引用链指出哪个对象导致了 Activity 无法回收5. 验证请求确认配置生效并跑通一次分析配置写完后先做一次最小验证确认 Key 和 base_url 都对。用 curl 发一个最简单的请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoTokenKey \ -d { model: claude-sonnet-4-20250514, messages: [ {role: user, content: 用一句话解释 Android 中非静态内部类为什么会持有外部类引用} ], max_tokens: 200 }如果返回里能看到正常的choices[0].message.content说明配置通了。返回 401 就是 Key 错了返回 404 大概率是 base_url 多写了/v1或者少了/v1检查一下。验证通过后就可以把真实的排查场景接进来。比如把 Memory Profiler 导出的引用链文本整理成一段让 AI 帮你判断泄露类型引用链 com.example.MyActivity - com.example.MyActivity$1.this$0 (匿名 Handler) - android.os.MessageQueue.mMessages - android.os.Looper.mQueue - java.lang.ThreadLocal (main thread)把这段贴给模型它会告诉你这是典型的 Handler 匿名内部类泄露并给出改成静态内部类 WeakReference 的修复方案。这一步能省掉大量翻源码的时间。6. 本篇常见错排查6.1 改了静态内部类还是泄露很多人把 Handler 改成静态内部类后发现 Activity 还是没被回收。原因通常是静态内部类里又持有了 Activity 的强引用。正确写法是用 WeakReferenceprivate static class SafeHandler extends Handler { private final WeakReferenceMainActivity activityRef; SafeHandler(MainActivity activity) { this.activityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity activity activityRef.get(); if (activity null || activity.isFinishing()) { return; } // 安全地操作 activity } }注意activityRef.get()之后一定要判空否则 Activity 已销毁时会 NPE。6.2 onDestroy 里 removeCallbacks 了还是泄露检查你是不是只 remove 了当前 Handler 的消息但 Handler 本身还被别的地方引用。另外removeCallbacksAndMessages(null)要传null才能清空所有消息传具体 token 只会清对应的那条。6.3 广播/监听器注册了没反注册registerReceiver一定要配对unregisterReceiver而且反注册要放在 try-catch 里因为注册失败时反注册会抛异常Override protected void onDestroy() { try { unregisterReceiver(myReceiver); } catch (IllegalArgumentException e) { // 未注册成功忽略 } super.onDestroy(); }同理ContentObserver、Timer、TimerTask、Cursor、IO 流都要在onDestroy里清理。我习惯在onDestroy里列一个清理清单逐项打勾比事后排查省事得多。6.4 单例持有 Context 导致泄露单例的生命周期和应用一样长如果它持有 Activity 的 ContextActivity 就永远回收不了。修复方式是单例里只存applicationContextpublic class AppManager { private static volatile AppManager instance; private final Context appContext; private AppManager(Context context) { this.appContext context.getApplicationContext(); } public static AppManager getInstance(Context context) { if (instance null) { synchronized (AppManager.class) { if (instance null) { instance new AppManager(context); } } } return instance; } }另外getSystemService也尽量用applicationContext去调某些厂商改了底层实现用 Activity 的 Context 调会导致系统服务无法释放。6.5 验证泄露是否真的消除修复后别急着提交按这个流程验证一遍反复进出可疑页面 10 次 → 手动触发 GC → 抓 heap dump → 搜索 Activity 类名。如果实例数稳定在 1当前显示的或者 0已退出说明修复生效。如果还是多个实例回到引用链面板继续找。7. 把 AI 辅助排查固化进日常流程排查内存泄露最耗时的不是修复而是定位。Logcat 看 GC 趋势、Profiler 抓引用链、AI 帮你解读引用链这三步串起来能把定位时间从半天压缩到十几分钟。TaoToken 在这里的价值是让你不用在多个工具之间来回切 Key——编辑器里配一次settings.json命令行里配一次config.toml两边共用同一个 Key 和 base_url。如果你还没配好可以从 TaoToken 模型对话 先试一次引用链分析确认效果后再落到本地配置。长期做 Android 开发、经常需要 AI 辅助读代码的同学可以看看 Coding Plan把日常的代码分析和排查都接进去。配置细节和参数说明都在 接入文档 里遇到 401/404 这类报错先翻文档比瞎试快。最后留一个我自己的习惯每次修完一个泄露把引用链和修复代码存到一个memory-leak-notes.md里下次遇到类似结构直接搜。内存泄露的花样就那么几种攒够案例之后看引用链基本能条件反射出问题在哪。
