案例分享：在 initState 时注册来监听器，在 didChangeAppLifecycleState 回调方法中打印来当前的 App 状态，最后在 dispose 时把监听器移除：

class _MyHomePageState extends State<MyHomePage> with WidgetsBindingObserver { ... @override @mustCallSuper void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); // 注册监听器 } @override @mustCallSuper void dispose() { super.dispose(); WidgetsBinding.instance.removeObserver(this); // 移除监听器 } @override void didChangeAppLifecycleState(AppLifecycleState state) async { print("$state"); if (state == AppLifecycleState.resumed) { // do sth } } } 

尝试这切换一下前、后台，观察控制台输出的 App 状态，可以发现：

• 从后台切入前台，控制台打印的 App 生命周期变化如下：AppLifecycleState.paused -> AppLifecycleState.inactive -> AppLifecycleState.resumed;
• 从前台退回后台，控制台打印的 App 生命周期变化则变成了：AppLifecycleState.resumed -> AppLifecycleState.inactive -> AppLifecycleState.paused

帧绘制回调

除了需要监听 App 的生命周期回调做相应的处理之外，有时候还需要在组件渲染之后做一些与显示安全相关的操作。

在 iOS 开发中，可以通过 dispatch_async(dispatch_get_main_queue(),^{...}) 方法，让操作在下一个 RunLoop 执行；在 Android 开发中，可以通过 View.post() 插入消息队列，来保证在组件渲染后进行相关操作。

在 Flutter 中实现同样的需求会更简单： 依然使用万能的 WidgetsBinding 来实现。

WidgetsBinding 提供了单次 Frame 绘制回调，以及实时 Frame 绘制回调两种机制，来分别满足不同的需求：

• 单次 Frame 绘制回调，通过 addPostFrameCallback 实现。它会在当前 Frame 绘制完成后进行回调，并只会回调一次，如果要再次监听则需要再设置一次。

WidgetsBinding.instance.addPostFrameCallback((_){ print(" 单次 Frame 绘制回调"); // 只回调一次 }); 

• 实时 Frame 绘制回调，则通过 addPersistentFrameCallback 实现。这个函数会在每次绘制 Frame 结束后进行回调，可以用作 FPS 检测。

WidgetsBinding.instance.addPersistentFrameCallback((_){ print(" 实时 Frame 绘制回调"); // 每帧都回调 });