Flutter WidgetsBindingObserver页面导航AppLifecycleState触发差异解析

问题背景 #

• 两个页面的生命周期监听实现完全对齐：
  • 均通过with WidgetsBindingObserver混入生命周期监听能力
  • 统一在initState阶段调用WidgetsBinding.instance.addObserver(this)完成监听器注册
  • 统一在dispose阶段调用WidgetsBinding.instance.removeObserver(this)完成监听器注销
  • 均按相同逻辑重写didChangeAppLifecycleState方法，对不同生命周期分支做业务处理
• 两个页面的跳转入口存在位置差异：
  • 第一页：入口在首页第一个Tab栏内，导航进入该页面时，在应用本身没有发生前后台切换的前提下，会自动触发AppLifecycleState.resumed回调，开发者最初将设备广播业务逻辑放在该回调中执行
  • 第二页：入口在首页第二个Tab栏内，导航进入该页面时，完全不会触发AppLifecycleState.resumed回调，目前只能将设备发现逻辑放在initState方法中才能正常运行

行为差异的核心原因 #

• 首先要明确核心规则：AppLifecycleState系列回调是应用全局层级的状态广播，只在APP整体状态发生实际变化时才会由系统发出，和单个页面的导航入栈、Tab切换动作本身没有直接触发关系
• 第一个Tab对应页面能收到resumed回调的真实触发链路：
  目前绝大多数带Tab的首页都会采用BottomNavigationBar + IndexedStack的结构实现，默认选中的第一个Tab页会在应用启动时就完成初始化，初始化过程中大概率会主动拉起系统级交互弹窗（比如蓝牙、定位权限申请），此时应用会从原本的resumed状态切换为inactive状态；等用户完成弹窗操作、应用重新回到可交互的前台状态时，系统就会广播resumed事件，而由于页面的监听器已经在initState阶段完成注册，自然就能接收到这个回调，开发者会误以为“进入这个Tab页就会自动触发resumed”
• 第二个Tab对应页面收不到resumed回调的真实原因：
  当用户从第一个Tab切到第二个Tab时，整个应用全程都处于前台可交互的resumed状态，加载第二个Tab页面的过程没有触发任何系统级弹窗、前后台切换的状态变化，系统自然不会重复推送当前已经处于的相同状态的事件，因此不会触发resumed回调

常见认知误区澄清 #

• 不存在“导航进入某个页面就必须自动触发一次resumed回调”的内置逻辑：应用级生命周期事件是全局广播性质，不会为单个页面的路由动作单独触发
• 两个页面的监听器注册、注销逻辑本身没有缺陷，回调表现不一致的根源，是两个页面的加载流程对应用整体生命周期的影响不同，而非监听代码的实现差异

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