该停。iOS/Android后台会冻结WebView或限制定时器，导致swiper自动播放卡顿、跳帧、内存占用；应监听uni.onAppHide/onAppShow手动暂停/恢复，并缓存current值防错位。

uni-app 里用 swiper 轮播图片，但切到后台就该停吗？

该停。iOS 和 Android 系统在 App 进入后台后会冻结 WebView 或限制定时器执行，swiper 的自动播放（autoplay）若依赖 setInterval 或页面生命周期外的逻辑，大概率失效或错乱——不是“轮播没停”，而是“轮播卡住+恢复时跳帧+内存持续占用”。真正要做的，是主动监听前后台状态，手动控制播放开关。

怎么监听 uni-app 页面是否在前台？

别靠 onShow/onHide ——它们只管页面级显隐，不反映整个 App 是否在后台。必须用 plus.navigator.getState()（仅 5+ App）或更通用的 uni.onAppHide/uni.onAppShow。

• uni.onAppHide 触发时，立即调用 swiperRef.pause()（如果用了 ref）或设置 autoplay: false 并记录当前索引
• uni.onAppShow 触发时，再恢复 autoplay: true，并用 this.$nextTick(() => swiperRef.resume()) 避免 DOM 未就绪
• H5 端用 document.addEventListener('visibilitychange') 补充监听，document.hidden 为 true 时同样暂停

swiper 组件的 autoplay 参数有哪些坑？

autoplay 看似开关，实则受多个条件制约：

• 必须同时设置 interval（毫秒），默认 5000，设成 0 不代表关闭，而是“立即切换”，容易卡死
• Android 真机上，若 duration（滑动动画时长） > interval，会导致轮播“粘连”——上一帧还没动完，下一帧已触发
• 微信小程序平台不支持 autoplay 动态修改，改了也不会生效；得用 current + 定时器手动控制，再配合 change 事件防抖
• 开启 disableProgrammaticAnimation 可避免手动 current 切换时与自动轮播冲突，但会丢失过渡动画

后台停止后如何省电又不丢体验？

单纯停掉 autoplay 不够。轮播组件内部可能还挂着定时器、图片预加载、懒加载回调等。

• 在 onAppHide 中，除了暂停 swiper，还要 clearInterval(this.timer)（如果你自己写了轮播逻辑）
• 用 lazy-load 属性控制图片加载，避免后台时仍请求未显示项的 src
• 轮播图数量超过 5 张时，建议用 virtualList 模式（需自定义实现或用插件），否则 DOM 节点和内存占用随图片数线性增长
• iOS 上，backgroundAudioManager 类似的机制不存在，所以不要试图用音频 hack 唤醒定时器——无效且被系统 kill

最常被忽略的是：App 切后台时，swiper 的 current 值不会自动同步到 data，恢复前台后直接开播，可能从错误位置开始。务必在暂停前缓存 current，恢复时先设值再开播。