应用发布后频繁出现Input dispatching timed out类型ANR求助

问题本质 #

Input dispatching timed out类型的ANR，核心原因是主线程被阻塞超过5秒，无法及时响应用户的触摸/滑动等操作，报错指向的MainNavigationActivity就是阻塞发生的核心页面。

结合你提供的Play Store日志（显示ANR触发时主线程的调用栈）和代码截图（涉及Navigation相关逻辑），大概率是以下几种情况导致：

• Activity或Fragment的生命周期方法（如onCreate、onResume）中执行了耗时操作：同步网络请求、大文件读写、复杂数据计算全堆在主线程
• Navigation页面切换时，Fragment初始化包含heavy操作：比如一次性加载大量数据、同步解码大图
• 未正确使用异步线程：数据库操作、本地IO直接在主线程执行，抢占了UI响应资源

排查&修复步骤 #

• 定位阻塞代码：Play Store的ANR日志信息有限，建议开发阶段用Android Studio的Profile工具录制主线程调用栈，或集成BlockCanary这类ANR监控库，精准定位到具体阻塞的代码行
• 将耗时操作移至异步线程：
  • 网络请求必须通过Coroutines、RxJava等异步框架实现，禁止在主线程同步发起请求
  • 数据库、文件读写使用Room异步API，或手动开启子线程执行，完成后再通知主线程更新UI
  • 列表数据预处理、大图解码等操作，放到后台线程执行完毕后再交付UI层
• 优化Navigation页面初始化：
  • 避免在Fragment的onCreateView/onViewCreated中执行初始化逻辑，改用懒加载——比如借助viewLifecycleOwner.lifecycleScope.launchWhenResumed，等页面可见后再加载数据
  • 检查是否存在Fragment重复创建、过度渲染的情况，确认导航组件配置是否合理
• 开启StrictMode检测违规操作：开发阶段开启StrictMode，可直接将主线程的违规操作输出到日志：

  if (BuildConfig.DEBUG) {
      StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
          .detectAll()
          .penaltyLog()
          .build())
      StrictMode.setVmPolicy(StrictMode.VmPolicy.Builder()
          .detectAll()
          .penaltyLog()
          .build())
  }
  

• 临时应急方案（非长期解决办法）：若暂时无法定位阻塞点，可给MainNavigationActivity添加android:windowSoftInputMode="adjustNothing"（若为软键盘触发的ANR），或关闭页面过渡动画，但这仅为缓兵之计，核心阻塞点仍需解决

验证方式 #

修复后用CPU Profiler录制应用启动、页面切换的主线程耗时，确保所有操作耗时控制在500ms以内；同时在弱网、后台多应用运行的高负载场景下测试，验证ANR是否消失。

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