在之前博客中，我曾经写过「PC 上的 Firefox、Chrome 和 Safari 等浏览器，都会自动把未激活页面中的 JavaScript 定时器（setTimeout、setInterval）间隔最小值改为 1 秒以上；而移动设备上的浏览器往往会直接冻结未激活页面上的所有定时器」。今天继续聊一聊 JavaScript 定时器与移动 Web 这个话题。
最简单的计时器只需要一个时间变量和固定间隔运行的函数就可以了，定期把上一次时间（默认为系统初始时间）加上运行间隔就是当前时间了。在 PC 上，这样实现的计时器只要运行间隔没有小于 1s，多半没什么大问题。但移动端不一样，只要页面不在前台显示，计时器就彻底不走了。
这个问题很容易解决，只要把定时器函数里的时间累加逻辑，换成每次都从系统时间获取就可以了。那如果系统时间不准怎么办？实际上大部分智能手机，默认都会开启网络校时 ，而且很多人有拿手机当手表的习惯，所以移动 Web 里获取到的系统时间，相比 PC 端，要准确得多。
更严谨的做法是服务端输出页面时带上服务器时间，JS 计时器先算出这个时间与系统时间之差 Δt，之后每次都用当前系统时间 + Δt 来还原服务器时间。逻辑很简单不多介绍了，说两个问题：
1）如果定时器运行时，用户改了系统时间怎么办？这个问题有很多解决方案，但是在移动设备上却有个偷懒的办法，由于移动设备上修改系统时间几乎一定会让页面进入后台， 所以我们只需要在页面「从后台切回」时刷新下页面就好了。
2）移动设备在 2G 等网络环境下，接收响应需要更长时间，很有可能 JS 从页面上拿到服务器时间，已经是几十秒之后的事情了，丧失了准确性。如果一定要解决这个问题，使用 HTML5 新增的 Navigation Timing API 来修正是一种思路。美中不足的是 Android 4.0+ 才支持，Safari 系列则从未支持过这个 API。
要判断移动端页面是否从后台切回有很多方案，但利用后台页面定时器被冻结这个特性，有个简便且通用的做法：
var lastTime = +new Date;
setInterval(function() {
if(Math.abs(+new Date - lastTime) > 3000) {
alert('从后台切回！');
}
lastTime = +new Date;
}, 1000);
原理很简单，每隔一段时间（如 1s）更新页面上某个变量，如果下次这个变量与当前系统时间之差大于某个阈值（如 3s），说明页面定时器肯定被冻结过，也就是说页面是从后台切回来。代码中加上 Math.abs 是因为用户可能把系统时间往回改（当然极端情况下还是会检测不出来，忽略就好了）。
我曾写过一篇「不会被 iOS 停掉的网页定时器」，原理是利用不会被 iOS 冻结的 <meta> 标签 refresh 功能模拟 JS
定时器，有兴趣的同学可以点这里了解下。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8