Android WebView异步请求队列的正确实现及异常处理问询

这个问题在Android WebView的JavaScript环境里其实挺常见的，我来分享几个实用的解决方案，帮你彻底解决队列卡住的问题：

先搞清楚为什么Promise会「静默挂起」 #

你遇到的情况，大概率是两种原因：

1. WebView后台节流：Android系统会在应用进入后台后限制JS线程的执行优先级，甚至暂停JS线程，导致Promise的回调（不管成功还是失败）都无法触发，processNext()自然也得不到执行。
2. 网络请求无响应：部分网络请求可能因为底层网络栈的问题（比如TCP连接挂起、代理异常等），既不返回成功也不抛出错误，直接导致Promise一直处于pending状态。

针对性解决方案 #

1. 用Promise.race()加超时兜底，同时适配后台状态 #

超时机制是解决Promise挂起的直接手段，但要结合应用的前后台状态做优化，避免在后台做无效的重试：

第一步：给API请求加超时包装

// 包装带超时的API调用
function callAPITimeout(params, timeoutMs = 12000) { // 设12秒超时，可按需调整
  const apiPromise = callAPI(params);
  const timeoutPromise = new Promise((_, reject) => {
    setTimeout(() => {
      reject(new Error('REQUEST_TIMEOUT'));
    }, timeoutMs);
  });
  // 谁先触发就用谁的结果
  return Promise.race([apiPromise, timeoutPromise]);
}

第二步：结合Native的前后台通知控制队列

通过Android的JavascriptInterface让Native层通知JS应用的前后台状态，在后台时暂停队列调度，前台恢复时重启：

// 假设Native通过这个方法通知前后台状态
window.AppLifecycle = {
  onEnterBackground: function() {
    // 清除所有等待中的定时器，暂停队列
    clearTimeout(window.queueNextTimeout);
  },
  onEnterForeground: function() {
    // 前台恢复时，立即触发下一个任务
    processNext();
  }
};

这样既避免了后台时系统节流导致的定时器延迟，也能减少不必要的资源消耗。

2. 给队列加「心跳监控」作为兜底 #

你考虑的定期检查思路是对的，但不要用固定的setInterval，而是基于任务推进的时间戳来判断，更高效：

let lastProcessTimestamp = Date.now();
const STUCK_THRESHOLD = 2 * 60 * 1000; // 2分钟阈值
const MONITOR_CHECK_INTERVAL = 60 * 1000; // 每1分钟检查一次

function monitorQueueHealth() {
  const now = Date.now();
  // 只有队列有任务，且超过阈值未推进时才触发重启
  if (_queue.hasPendingJobs() && (now - lastProcessTimestamp) > STUCK_THRESHOLD) {
    console.warn('Queue detected as stuck, restarting...');
    // 先清除可能存在的定时器，避免重复触发
    clearTimeout(window.queueNextTimeout);
    // 重置卡住的任务状态（比如把标记为processing的任务改回pending）
    _queue.resetStuckJobs();
    // 重新启动队列
    processNext();
  }
  // 继续下一次监控
  setTimeout(monitorQueueHealth, MONITOR_CHECK_INTERVAL);
}

// 初始化队列时启动监控
monitorQueueHealth();

// 每次执行processNext时更新时间戳
function processNext() {
  lastProcessTimestamp = Date.now();
  // 原有的processNext逻辑...
  const nextJob = _queue.getNextJob();
  if (!nextJob) return;
  callAPITimeout(nextJob.parameters)
    .then(result => {
      _queue.completeJob(nextJob.id);
      processNext();
    })
    .catch(e => {
      if (isNetworkError(e)) {
        // 网络错误，重新加入队列（可放在队尾或队首，按需调整）
        _queue.reEnqueueJob(nextJob);
        window.queueNextTimeout = setTimeout(processNext, 5000);
      } else {
        Logger.log('API error', e);
        _queue.failJob(nextJob.id);
        processNext();
      }
    });
}

这里的_queue.hasPendingJobs()和_queue.resetStuckJobs()需要你根据自己的队列实现补充，核心是识别出卡住的任务并重置状态，避免一直占用队列。

3. 优化错误判断逻辑，避免分支遗漏 #

一定要确保能准确区分网络错误和API业务错误，避免把应该重试的错误当成普通错误处理：

// 示例：判断是否为网络错误
function isNetworkError(error) {
  // 根据WebView中实际的错误信息调整，比如常见的网络错误关键词
  const networkErrorMessages = ['Failed to fetch', 'NETWORK_ERROR', 'REQUEST_TIMEOUT'];
  return networkErrorMessages.includes(error.message) || 
         (error.code && error.code >= 500 && error.code < 600); // 部分5xx也可归为网络/服务器异常
}

4. 可选：给队列加持久化（提升极端场景下的稳定性） #

如果你的应用可能被系统回收进程，建议把队列持久化到IndexedDB中，每次任务状态变化时更新存储。这样即使应用重启，也能恢复之前的队列，同时可以通过存储中的任务状态（比如processing状态超过阈值的任务）来自动重试，进一步提升可靠性。

总结 #

推荐的实现顺序是：

1. 给API请求加上Promise.race()超时包装；
2. 结合Native的前后台通知控制队列调度；
3. 加上心跳监控作为最后兜底；
4. 按需添加队列持久化。

这样基本能覆盖99.9%的场景，解决队列卡住的问题。

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