Android 浏览器如何实现 AJAX 轮询？真相是：不可靠

Android浏览器（如Chrome、Firefox等）在页面进入后台或屏幕关闭时会主动暂停JavaScript执行，导致传统的setInterval+AJAX轮询完全失效——这不是Bug，而是系统级资源管控的必然结果；文章揭示了该方案在移动端的彻底不可靠性，并明确指出强行绕过既危险又低效，转而推荐WebSocket长连接（适用于前台实时场景）和Web Push+PWA（适用于后台消息触达）两大现代替代方案，强调开发者应尊重平台约束，从“主动询问”转向“被动通知”，以真正实现省电、低负载、高实时性的移动端数据同步。

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 开发者，应主动适配而非对抗这一机制：

最终建议：若业务强依赖后台数据同步，请评估是否转向 PWA 或轻量级原生壳（如 Capacitor/Cordova），并彻底弃用轮询思维——真正的实时性，永远来自“被通知”，而非“去询问”。

到这里，我们也就讲完了《Android 浏览器如何实现 AJAX 轮询？真相是：不可靠》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！