应用暂停时Choreographer.FrameDisplayEventReceiver.run频繁调用是否正常？性能影响如何？

是否属于正常现象？ #

这得分具体场景来看：

• 多数情况下是不正常的：当你的应用处于后台暂停状态（比如Activity执行onPause()后），正常来说所有与前台UI相关的动画都应该停止。如果此时Choreographer.FrameDisplayEventReceiver.run还频繁调用并指向LottieDrawable.onAnimationUpdate，大概率是因为你没有正确暂停Lottie动画——比如忘记在生命周期回调里调用lottieDrawable.pauseAnimation()，或者存在内存泄漏导致Lottie实例没有被正确回收，仍在后台持续播放动画。
• 少数特殊场景是正常的：如果你的Lottie动画是绑定在前台通知的UI组件上（比如带有动画的通知图标），或者应用在后台运行着前台服务且需要持续展示动画，那Choreographer的频繁调用就是合理的——因为这些UI元素需要保持刷新，系统允许前台相关的UI任务继续运行。

对性能（功耗）的影响？ #

如果是不必要的后台动画触发，肯定会有负面影响：

• 功耗增加：Choreographer每一次调用都会唤醒主线程处理帧更新，即使应用在后台，CPU也会频繁被占用，导致电池消耗加快。
• 主线程负载：后台持续的帧更新会让主线程处于活跃状态，可能影响其他后台任务的执行，极端情况下甚至可能触发系统的ANR（应用无响应）检测，或者被系统判定为异常行为而限制资源。
• 内存占用：如果伴随内存泄漏，Lottie实例持续运行还会占用额外的内存资源，进一步影响应用稳定性。

修复建议 #

• 绑定生命周期：在Activity/Fragment的onPause()回调中调用lottieDrawable.pauseAnimation()，在onResume()中调用resumeAnimation()，确保动画随页面状态同步暂停/恢复。
• 检查内存泄漏：使用内存检测工具排查是否存在LottieDrawable被意外持有（比如静态引用、未取消的监听器）的情况，避免实例在页面销毁后仍持续运行。
• 前台通知动画优化：如果是通知中的Lottie，确保只有在通知处于前台展示状态时才启动动画，当通知被关闭或应用进入后台非前台状态时，及时暂停动画。

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