Android 浏览器（包括 Chrome、Firefox 等）在页面进入后台或屏幕关闭后会暂停 JavaScript 执行，导致 setInterval + AJAX 轮询失效；这不是浏览器 Bug，而是系统级资源管控机制，强行绕过既不可靠也不符合最佳实践。
android 浏览器（包括 chrome、firefox 等）在页面进入后台或屏幕关闭后会暂停 javascript 执行，导致 `setinterval` + ajax 轮询失效；这不是浏览器 bug，而是系统级资源管控机制，强行绕过既不可靠也不符合最佳实践。
在 Web 开发中，常有人尝试通过如下代码实现实时数据更新：
var tid = setInterval(mycode, 2000);
function mycode() {
$.ajax({
url: '/ajx.php',
type: 'GET',
success: function(data) {
console.log('Received:', data);
// 处理响应逻辑
},
error: function(xhr, status) {
console.warn('Polling failed:', status);
}
});
}
但该方案在 Android 移动端浏览器中注定失败——原因并非代码有误，而是 Android 系统与浏览器引擎的协同设计原则：
- ✅ 前台活跃时：页面可见且处于 Activity 前台 → 定时器正常触发，AJAX 可执行；
- ❌ 切到后台（如按 Home 键、切换应用）：Chrome/Firefox 等 WebView 或 Tab 进入冻结状态，JavaScript 引擎被暂停，setInterval 停摆，AJAX 请求不会发出；
- ❌ 屏幕熄灭或进入 Doze 模式：系统进一步限制 CPU、网络和定时器，即使使用 requestIdleCallback 或 Page Visibility API 也无法唤醒；
- ❌ 非 Chrome 浏览器亦无例外：Samsung Internet、Edge、Firefox for Android 等均遵循 Android 的后台生命周期策略，不存在“某款浏览器能持续轮询”的特例。
⚠️ 注意：试图用 navigator.sendBeacon()、Service Worker fetch 或 background-fetch API 替代轮询，在纯浏览器环境（非 PWA 安装态）下同样受限。Android 12+ 对未激活标签页的定时器精度已降至最大 1 分钟间隔，且不保证执行。
正确解法：放弃轮询，拥抱事件驱动
持续轮询（Polling）本质是低效反模式：它浪费电量（客户端频繁唤醒）、增加服务器负载（无效请求占比高）、加剧网络延迟与带宽消耗。现代移动端 Web 应采用以下替代方案：
✅ 推荐方案 1：WebSocket 长连接（适用于 Web 页面）
服务端维持全双工通道，仅在有新数据时主动推送，客户端无需轮询：
const socket = new WebSocket('wss://your-api.com/ws');
socket.onopen = () => console.log('Connected to real-time server');
socket.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log('New update:', data);
// 更新 UI 或触发业务逻辑
};
socket.onerror = (err) => console.error('WS error:', err);
✅ 优势：实时性高、省电、降低服务器压力；
⚠️ 注意：需服务端支持 WebSocket（如 Node.js + Socket.IO、Spring WebFlux、Nginx 反向代理配置）；PWA 场景下可配合 Service Worker 缓存离线消息。
✅ 推荐方案 2：Web Push + Notification Click（需 PWA）
若用户已将网站添加至主屏幕（即安装为 PWA），可通过 Web Push API 接收高优先级消息：
- 后台服务（如 Firebase Cloud Messaging）发送加密推送；
- 即使 App/Tab 关闭，系统级通知仍可送达；
- 用户点击通知 → 唤醒页面并拉取最新数据（此时再发起一次 AJAX 即可）。
✅ 优势：完全绕过 Doze 限制，功耗最低；
? 要求：HTTPS 站点、用户授权通知权限、实现 push 和 notificationclick 事件监听。
❌ 不推荐方案（常见误区）
- 使用 setTimeout 递归替代 setInterval → 同样被冻结；
- 监听 visibilitychange 并尝试恢复定时器 → 后台页面无执行权；
- 依赖 Background Sync API → 当前仅 Chromium 实验性支持，且需 PWA 安装 + 用户交互触发，不适用于自动轮询。
总结：面向平台约束的设计哲学
Android 的后台限制不是缺陷，而是对电池寿命、内存效率与用户体验的深度优化。作为 Web 开发者，应主动适配而非对抗这一机制：
| 场景 | 可行方案 | 关键前提 |
|---|---|---|
| 普通网页（未安装） | WebSocket（前台有效） | 服务端支持、页面保持可见 |
| 已安装 PWA | Web Push + Service Worker | HTTPS、用户授权、首次交互触发订阅 |
| 原生 App 替代方案 | Foreground Service + FCM 高优先级消息 | 需开发独立 APK，可突破 Doze 限制 |
最终建议：若业务强依赖后台数据同步，请评估是否转向 PWA 或轻量级原生壳（如 Capacitor/Cordova），并彻底弃用轮询思维——真正的实时性，永远来自“被通知”，而非“去询问”。
