多次点击切换Activity后应用崩溃问题排查求助

我来帮你拆解下这个问题——从你提供的GC日志来看，你的应用明显是内存耗尽引发的Activity意外停止。日志里的关键信息已经把问题点得很清楚：95MB/96MB，应用的堆内存已经快被完全占满了，GC一直在拼命回收但只释放了几十KB的内存，根本杯水车薪，最后系统拒绝了堆内存扩容请求（Clamp target GC heap from 99MB to 96MB），直接导致后续内存分配失败，Activity崩溃。

下面是具体的排查和解决步骤：

• 优先排查Activity内存泄漏
  这是最常见的原因，每次跳转Activity后，旧的Activity实例没有被GC回收，内存越积越多：

  • 检查是否有静态变量、单例类持有Activity的上下文引用，比如单例里存了this或者非getApplicationContext()的上下文。
  • 检查Handler的使用：匿名内部类的Handler会默认持有外部Activity的引用，如果Handler里有未执行完的延迟任务，Activity就无法被回收。
  • 用Android Studio自带的Memory Profiler：记录连续跳转Activity的过程，观察内存曲线是否只升不降，然后通过堆转储（Heap Dump）定位到未被回收的Activity实例，查看引用链找到泄漏点。
  • 可以用LeakCanary工具，它能自动检测内存泄漏并生成详细的引用链报告，帮你快速定位问题。

• 优化Activity的内存占用
  即使没有泄漏，内存占用过高也会触发这个问题：

  • 检查图片资源：如果Activity里加载了高分辨率图片，一定要进行压缩后再加载，推荐用Glide或Picasso这类图片库，它们会自动处理图片的内存缓存和压缩。
  • 及时释放资源：在onDestroy()方法里，取消未完成的网络请求、回收Bitmap、注销广播接收器、移除Handler的所有回调和消息，避免资源长期占用内存。
  • 减少不必要的全局对象：避免在Activity中创建大对象的全局引用，不用的时候及时把引用置为null，让GC可以回收。

• 临时缓解方案（不推荐作为最终解决）
  如果你的应用确实需要更大的内存空间，可以在AndroidManifest.xml的<application>标签中添加android:largeHeap="true"，让系统分配更大的堆内存。但这只是治标不治本，不能解决内存泄漏或内存优化的核心问题，而且不同设备的大堆大小差异很大，依赖这个可能在低配置设备上依然崩溃。

再补充下日志的细节分析：

I/art: Alloc sticky concurrent mark sweep GC freed 907(64KB) AllocSpace objects, 1(16KB) LOS objects, 0% free, 95MB/96MB, paused 701us total 8.300ms
I/art: Clamp target GC heap from 99MB to 96MB
I/art: Alloc partial concurrent mark sweep GC freed 248(18KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 95MB/96MB, paused 762us total 24.932ms

这段日志显示，GC尝试了两种回收策略，但总共只释放了不到100KB的内存，堆内存依然维持在95MB/96MB的高位，说明大部分内存被无法回收的对象占用，也就是内存泄漏。系统尝试把堆内存上限从99MB降到96MB，进一步压缩了可用空间，最终导致后续的内存分配失败，Activity崩溃。

内容的提问来源于stack exchange，提问作者Darwin Cris Prepose