软键盘显隐触发窗口Resize时卡顿问题求助
我来帮你拆解这个问题的核心根源——既然你已经排除了严重内存泄漏的可能，那问题几乎肯定出在多Fragment堆积回退栈时，系统处理布局遍历的开销暴增，再加上Google Map这个重量级视图的叠加，最终导致Resize卡顿。下面是几个最关键的根本原因：
1. 回退栈Fragment的视图未销毁，导致视图树冗余
当你用add而非replace方式添加Fragment并放入回退栈时，这些Fragment的视图并没有被销毁，只是被设置为GONE状态隐藏起来。虽然用户看不到，但它们依然属于Activity的完整视图树的一部分。
窗口Resize时，系统会从根View开始遍历整个视图树，重新计算每个View的尺寸和位置。回退栈里的4-5个Fragment各自带着自己的子视图（比如你的Fragment A有EditText、按钮，其他Fragment可能也有复杂布局），再加上Google Map的庞大视图节点，整个视图树的节点数量会大幅膨胀，布局遍历的时间会随节点数线性增长，最终超过1秒的流畅阈值。
验证方法：打开Android Studio的「Layout Inspector」，查看当前Activity的视图树结构，你会清晰看到回退栈里的Fragment视图依然存在，没有被移除。
2. Google Map视图的重绘/布局开销叠加
Google Map本身是一个极其复杂的视图组件，内部包含瓦片加载、图层渲染、坐标计算等大量重型逻辑。当窗口Resize时，Map会触发强制重布局和重绘，这个过程本身就比普通视图耗时得多。
当回退栈里堆积多个Fragment时，视图树遍历的开销+Map的重绘开销会形成“双重负担”，两者叠加后就会出现明显的卡顿。哪怕Map所在的Fragment被隐藏，只要它的视图还在视图树中，系统依然会执行布局计算的步骤（哪怕最终因为GONE跳过绘制，但计算过程无法避免）。
3. Fragment生命周期的未优化处理
虽然你说没有严重内存泄漏，但回退栈里的Fragment可能没有正确处理隐藏后的资源释放逻辑。比如：
- 某些Fragment在隐藏后仍然持有活跃的动画、回调监听或后台任务；
- 没有在
onHiddenChanged或onPause中暂停不必要的逻辑（比如数据刷新、动画播放）。
这些后台运行的逻辑会在布局遍历过程中额外消耗CPU资源，进一步拖慢Resize的速度。
4. 布局层级过深或过度绘制的放大效应
如果每个Fragment的布局存在层级过深（比如嵌套多层LinearLayout/RelativeLayout）或过度绘制（比如多层重叠的背景、未优化的自定义View）问题，单个Fragment的布局遍历开销就已经不小。当多个这样的Fragment堆积在视图树里，问题会被成倍放大，最终导致Resize卡顿。
验证方法：用Android Studio的「Profile GPU Rendering」工具查看绘制耗时，或用「Overdraw Inspector」检查过度绘制情况。
定位问题的验证建议
- 临时移除Google Map：先把Map视图从布局中去掉，测试软键盘Resize是否还卡顿。如果卡顿消失，说明Map是核心开销来源；如果依然卡顿，那就是多Fragment的视图树冗余问题。
- 测试视图销毁的情况：尝试用
replace而非add添加Fragment（会销毁前一个Fragment的视图），看Resize是否流畅。如果流畅，就确认是回退栈Fragment未销毁视图导致的问题。 - CPU Profiler追踪：用Android Studio的「CPU Profiler」录制软键盘弹出/隐藏的过程，查看哪个方法耗时最长——通常会是
View.measure、View.layout或Google Map相关的渲染方法。
根本解决方向的思路
核心解决方向就是减少视图树的冗余节点，降低布局遍历的开销：
- 优化Fragment的视图管理：在Fragment被隐藏时，主动销毁其视图（比如在
onDestroyView中清理视图引用，下次显示时重新创建）； - 优化Google Map的Resize行为：在软键盘弹出/隐藏时，暂时暂停Map的渲染或禁用其布局重计算，完成Resize后再恢复；
- 简化Fragment布局：减少布局层级，优化过度绘制，降低单个Fragment的布局开销。
内容的提问来源于stack exchange，提问作者TomJouin
