Android问卷应用Fragment创建是否规范？内存崩溃问题排查

Fragment创建方式的正确性 #

你当前用replace()切换Fragment的写法本身是合法的，但这种每次创建新实例的方式会埋下内存隐患——尤其是当Fragment持有未释放的资源时，旧实例可能无法被GC回收，积累到一定数量就会触发内存溢出。

可能的编程逻辑问题 #

1. 未释放Fragment内的资源：如果QuestionFragment里持有Bitmap（比如题目配图）、未取消的网络请求、注册的广播接收器/EventBus监听等，在onDestroyView或onDestroy里没做释放操作，旧Fragment实例会被这些资源“拽住”无法回收，内存越积越多。
2. 误加回退栈：如果代码里不小心加了fragmentTransaction.addToBackStack(null)，FragmentManager会把所有旧Fragment都存在回退栈里，100个实例堆在一起必然炸内存。你当前的代码里没加，但要确认有没有其他地方加过。
3. 大对象引用未释放：你传递给Fragment的nvoReac如果是个大对象（比如包含大量图片数据、历史问卷记录），且旧Fragment还持有它的引用，会导致这个大对象也无法被回收，加剧内存压力。
4. 无限制创建新实例：每次切换都new一个QuestionFragment，100题就会生成100个实例，哪怕旧的被移除，只要有引用残留，就会持续占用内存。

排查思路与优化方向 #

• 先看崩溃日志：直接定位异常类型，如果是OutOfMemoryError，重点查内存泄漏；如果是恢复相关异常（比如IllegalStateException），看是否是Fragment状态保存/恢复时的问题。
• 用Android Studio内存分析工具：打开Profiler的Memory面板，操作到第50题左右时dump内存快照，搜索QuestionFragment的实例数量——如果远大于1，说明存在内存泄漏。再看实例的引用链，找到是谁在持有旧Fragment的引用（比如Activity的静态变量、未取消的回调）。
• 清理Fragment资源：在QuestionFragment的onDestroyView里做彻底的资源释放：
  • 清空ImageView的Bitmap：imageView.setImageBitmap(null)，如果是Glide/Picasso加载的，调用clear()方法。
  • 取消所有异步任务/网络请求：比如用OkHttp的Call.cancel()，或者Coroutine的Job.cancel()。
  • 解绑广播接收器、EventBus、RxJava订阅等。
• 避免回退栈堆积：确保没有调用addToBackStack()，除非有必须的返回需求（问卷场景下一般不需要返回上一题的话就别加）。
• 复用Fragment实例：不要每次都new新的，而是创建一个QuestionFragment实例，每次切换时通过setArguments()或者自定义方法更新题目数据，减少实例数量。
• 优化数据传递：如果nvoReac是大对象，不要直接传递整个对象，改成传递题目ID，Fragment内部再根据ID从数据源（比如数据库、全局缓存）获取数据，避免持有大对象引用。

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