安卓4.2.2平板自动化UI屏保两小时后卡顿（疑似内存泄漏）

针对你在老旧安卓4.2.2平板上运行家庭自动化屏保遇到的两小时后完全冻结（时钟、脚本停止，甚至无法ping通）的问题，结合你提供的代码，我整理了几个关键排查方向，帮你定位根因：

1. 定时器递归调用的内存累积隐患 #

你的代码里用了setTimeout('runScreenSaver()','3500')这种字符串形式的定时器调用，同时date_time.js里也有多个每秒/每半秒的递归setTimeout。在安卓4.2.2对应的老旧WebView引擎（基于Chrome 30左右）中，字符串形式的定时器会创建额外的执行上下文，加上无终止条件的递归调用，很容易导致调用栈累积和内存无法被垃圾回收（GC）。

• 可以试试这么改：把字符串形式的定时器换成函数引用，避免每次创建新的执行上下文：

  setTimeout(runScreenSaver, 3500); // 去掉引号和括号，直接传函数
  

• 另外，递归定时器可以考虑用setInterval替代（同样用函数引用），比如getTimeDate函数可以改成初始化一次定时器，避免重复创建实例：

  function getTimeDate(id) {
    // ... 原有日期时间处理逻辑 ...
  }
  // 初始化一次，每秒执行
  setInterval(() => getTimeDate('date'), 1000);
  

2. AJAX请求的未回收资源问题 #

在getAlarmDataFromDatabase函数中，你每3.5秒就发起一次数据库请求，但老旧WebView中，XMLHttpRequest实例如果绑定了onreadystatechange回调，即使你最后把ajax = null，如果请求失败（比如网络波动、数据库超时），readyState可能永远到不了4，导致回调函数一直持有实例引用，无法被GC回收，长期运行会累积大量未完成的请求实例。

• 你可以这么做来排查和修复：
  • 给AJAX添加超时处理，避免请求挂起：

    ajax.timeout = 5000; // 设置5秒超时
    ajax.ontimeout = function() {
      console.log("Alarm data request timed out");
      ajax.onreadystatechange = null; // 先清空回调
      ajax = null; // 再释放实例
    };
    

  • 无论请求成功还是失败，都要主动清理回调和实例：

    ajax.onreadystatechange = function() {
      if (this.readyState == 4) {
        // ... 原有解析数据的逻辑 ...
        // 清理资源
        ajax.onreadystatechange = null;
        ajax = null;
      }
    };
    

  • 降低请求频率：每3.5秒一次数据库请求对老旧设备和网络压力太大，改成每30秒或1分钟请求一次，足够满足报警状态更新的需求。

3. DOM操作的重复开销与引用泄漏 #

每次runScreenSaver都调用getElementById获取DOM元素，虽然你最后把变量设为null，但老旧引擎的DOM元素引用回收可能不及时。另外，频繁修改元素的left和top属性会触发页面重绘，长期运行也会累积性能开销。

• 优化建议：把常用DOM元素缓存起来，避免重复查询：

  // 在函数外缓存元素，只查询一次
  const randomImage = document.getElementById("randomPlacement");
  const dateElement = document.getElementById("date");
  const alarmImg = document.getElementById("img_alarm");
  
  function runScreenSaver() {
    // ... 原有计算坐标的逻辑 ...
    randomImage.style.left = xCoordStr;
    randomImage.style.top = yCoordStr;
    dateElement.innerHTML = getTimeDate('date');
    // ...
  }
  

4. 轻量内存排查方法（适配老旧设备） #

由于平板调试能力有限，你可以试试这些简单方法定位问题：

• 简化测试：先注释掉getAlarmDataFromDatabase()，只运行时钟和随机图片定位，看两小时后是否还会冻结。如果不会，说明问题出在AJAX部分；如果还是冻结，再排查定时器和DOM操作。
• 单功能测试：先只运行时钟功能，确认两小时正常后，再加入随机图片，再加入AJAX，逐步定位哪个模块导致泄漏。
• 日志记录：如果WebView支持，可以在核心函数中添加内存日志（虽然安卓4.2.2可能不支持performance.memory，但可以试试）：

  if (window.performance && window.performance.memory) {
    console.log("Used heap: " + performance.memory.usedJSHeapSize);
  }
  

5. 安卓WebView固有问题的规避 #

安卓4.2.2的WebView本身存在一些内存泄漏的固有bug，尤其是长期运行JS的场景：

• 简化DOM结构：比如把SVG线条换成CSS边框，减少页面重绘开销。
• 强制GC（不推荐但可尝试）：在runScreenSaver末尾调用window.gc()（部分设备需要在WebView设置中开启调试GC），手动触发垃圾回收。

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