如何避免Android因GC导致主线程挂起引发的ANR问题？

看了你的ANR日志，主线程在执行LinearLayout.measureHorizon...时被GC挂起——这种情况本质是GC抢占了主线程的执行时间，叠加布局测量本身的耗时，最终触发了ANR。下面分享几个实战性的优化方向，帮你解决这个问题：

• 减少临时对象创建，降低GC触发频率
  千万别在onMeasure、onDraw这类会频繁调用的UI方法里创建临时对象，比如循环里的字符串拼接、匿名内部类、临时集合等，这些对象会快速填满年轻代，触发Young GC，一旦GC发生在主线程就会阻塞UI渲染。

  • 复用对象：比如用对象池缓存常用对象（参考RecyclerView.ViewHolder的复用逻辑），避免重复创建销毁；字符串拼接优先用StringBuilder代替+，尤其是循环场景。
  • 集合初始化时指定容量：比如new ArrayList<>(10)，避免集合扩容时产生额外的对象分配。

• 优化内存占用，降低Full GC概率
  Full GC的耗时远高于Young GC，更容易导致主线程长时间阻塞，所以要从根源减少Full GC的触发：

  • 及时释放无用引用：别让静态变量持有Activity/Fragment的强引用，必要时用WeakReference或SoftReference；注销广播接收器、移除监听器，避免内存泄漏导致大量对象无法回收。
  • 优化Bitmap内存：加载图片时根据控件尺寸用BitmapFactory.Options.inSampleSize缩放，避免加载超大Bitmap；用Glide/Coil这类库自动管理Bitmap的回收，不用手动调用recycle()也能高效利用内存。
  • 清理IO资源：用完文件流、数据库连接后及时关闭，避免资源持有导致内存泄漏。

• 主线程只做UI相关操作，把耗时任务丢去子线程
  主线程的核心职责是UI渲染，别让它干额外的活：

  • 把数据计算、解析、数据库查询这类操作放到子线程，用Coroutine、ThreadPoolExecutor或者RxJava来处理，避免主线程同时处理UI和耗时任务，减少GC与UI渲染的冲突。
  • 绝对不要在主线程做网络请求，这类IO操作不仅本身耗时，还会产生大量临时对象，双重增加ANR风险。

• 用工具分析GC行为，精准调优
  别盲目优化，用Android Studio的Memory Profiler定位问题：

  • 查看GC的频率和耗时，区分是Young GC还是Full GC导致的阻塞：如果Young GC频繁，说明临时对象太多；如果Full GC频繁，大概率是内存泄漏或者大对象过多。
  • 对于Android 8.0+，可以临时开启android:largeHeap="true"缓解内存压力，但这只是权宜之计，核心还是要做内存优化。

• 优化布局渲染，减少measure/layout的工作量
  你的日志显示主线程卡在measure阶段，说明布局本身的耗时也很高，叠加GC就更容易触发ANR：

  • 用ConstraintLayout代替嵌套的LinearLayout/RelativeLayout，减少布局层级，降低measure的计算量。
  • 用Layout Inspector检查过度绘制，移除不必要的背景色、重叠的View，减少渲染压力。
  • 用ViewStub延迟加载不常用的布局，减少初始布局测量的工作量。

内容的提问来源于stack exchange，提问作者Hong