深圳宝安区最新通告,长沙做网站seo,我做网站编辑写文章很慢怎么办,wordpress底部漂浮原文发表于 2018.05.25#xff0c;搬运自个人博客。引子回顾这半年#xff0c;扛需求能力越来越强#xff0c;业务代码也是越写越多。但稍一认真看看这些当时为了满足快速上线所码的东西#xff0c;问题其实还是不少。这次就从一个简单的计时器说起。现状问题很明显倒计时器…原文发表于 2018.05.25搬运自个人博客。引子回顾这半年扛需求能力越来越强业务代码也是越写越多。但稍一认真看看这些当时为了满足快速上线所码的东西问题其实还是不少。这次就从一个简单的计时器说起。现状问题很明显倒计时器组件在一个活动列表页面里被使用列表中每一项都是一个促销活动入口。倒计时器位于每个活动区块的左上方提醒用户该活动还有多久结束如下动图所示测试设备 SONY E5663后同。当页面滑动时可以明显看到计时器停止这意味着页面并没有刷新。直到松手后一两秒才恢复计时且不稳定又卡顿了一到两秒。如此明显的问题吓得笔者赶紧去后台查阅了该页面 PV 和 UV 数据虽说不多但还是有一批忠实用户每天访问这可怎么对得起我们的衣食父母…即便测试用的设备性能羸弱更换 Chrome 模拟器以及 17 年的安卓旗舰机再次测试并未出现如此卡顿现象但我们无法挑选客户使用的设备只能从技术角度解决问题尽量提升用户体验。BTW这台 SONY 测试机就是由东南亚的业务方同学提供应该是当地用户的常用机型之一。打脸与自我打脸倒计时器组件的更新逻辑抽象如下简单概括就是使用 setInterval 定时更新 React 组件的状态以实现倒数时间的更新不得不说贴出这么一段槽点满满的代码是极其需要勇气的这… 居然是我写的那么开始分tu析cao吧让我们自上而下依次盘点这段逻辑代码放在 componentWillMount 生命周期钩子里执行并不合适其因有二在 componentWillMount 阶段还未加载真实的 DOM 节点此时就开始更新数据没有什么意义React 的 Reconciliation 算法以及目前最新的 Fiber 调度器算法会对渲染的开始或停止过程进行优化例如合并几次渲染过程为一次这可能会导致 componentWillMount 被频繁调用。每次更新数据后都将触发一次渲染 SOP这无疑加大了性能开销。当动画刷新遇上大量运算一首《凉凉》送给低端手机。这样计时方式真的准吗例如 setInterval 的精准性又例如 setState 方法的使用。顺着这个思路赶紧来改代码吧提升更新效率更新速度有多慢首先花几秒钟把这段代码挪到 componentDidMount() 钩子里。接下来既然页面在 MBP 的 Chrome 模拟器上访问没有问题那么可以做个简单的对比实验看看手机与笔记本模拟器的性能差距。使用 performance.now 测量更新一次所花费的时间示例代码如下从下方两张截图可以看到测试机与模拟器的性能相差十倍左右且测试机的运算时间波动较大下方上图为模拟器数据下图为测试机数据其实上面的埋点代码添加在 setState 的回调函数里就明显能说明一个问题setState 方法并不保证同步渲染更新尽管截图中的时序看上去是同步的。重点是整个更新渲染的周期非常长即使降低至 30Hz 的流畅画面要求一帧可用的渲染时间也只有不到 34 毫秒还不是业务代码独享 之所以渲染速度慢是因为调用一次 setState 方法会依次执行 React 生命周期中的 4 个函数shouldComponentUpdate、componentWillUpdate、render 和 componentDidUpdate 如下图所示。Source: https://bit.ly/2Pb6sn5直接撸 DOM要啥 jQuery为了性能这里采用最为简单粗暴的方法直接更新 DOM 节点的 HTML 值让我们来看看效果如何模拟器上的更新时间缩短至 0.3 毫秒比之前快了十几到二十几倍测试机的数据也漂亮多了如下图再滑几下试试… 美滋滋更好的更新策略定时器最重要的功能就是确保时间准确如果时间都不准了那也就该洗洗睡了。除去与服务端同步校时之类的方案还是继续讨论如何在 Web 前端领域力求计时准确。并不精准的 setInterval在修复前文提到的 setState 缺陷之后最明显的问题莫过于 setInterval 的使用。写一个定时任务不少小伙伴第一反应想到的也是 setTimeout 和 setInterval 函数但是它们真的足够精确吗这就要从 JS 的任务队列及微任务队列也有称 macrotask queue 和 microtask queue说起了…咳咳我们言简意赅总结下JS 主线程执行时有一个栈存储运行时的函数相关变量遇到函数时会先入栈执行完后再出栈废话。当遇到 setTimeout setInterval requestAnimationFrame 以及 I/O 操作时这些函数会立刻返回一个值如 setInterval 返回一个 intervalID 保证主线程继续执行而异步操作则由浏览器的其它线程维护。当异步操作完成时浏览器会将其回调函数插入主线程的任务队列中当主线程执行完当前栈的逻辑后才会依次执行任务队列中的任务。但是在每个任务之间还有一个微任务队列的存在。在当前任务执行完后将先执行微任务队列中的所有任务例如 Promise process.nextTick 等操作。也就是说当 setInterval(fn, 1000) 等待 1 秒钟后fn 函数会被插入任务队列中但并不一定会立刻执行还需要等待当前任务以及微任务队列中的所有任务执行完。长此以往使用 setInterval 的计时器超时将越来越严重。如果有毅力的朋友推荐看看权威的 HTML 标准文档没耐心的就看看这个动图简单感受一下原理吧。所以回归正题不用 setInterval 那用啥天王盖地虎我有 rAF解铃还须系铃人既然我们的代码执行时间在主线程中无法得到保证那么还是要从更高抽象层级的浏览器中寻求办法。好在目前主流浏览器都已提供一个在重绘前执行动画相关函数的接口 requestAnimationFrame用来更新计时器再合适不过。改造如下那么这样实现足够精准了吗打印出每次更新的时间戳瞅瞅上图为模拟器数据下图为测试机数据。可以看到模拟器上已经相当精准每秒的误差在 0.15 毫秒左右也就是运行将近 2 小时会有 1 秒的误差笔者觉得完全可以接受。不过测试机上的误差就有点大了每秒的误差在 10 毫秒左右虽然笔者觉得也可以接受很少有人会在活动页停留很久但本着工tai匠gang精神想想是否还能优化呢正向反馈拯救采样频率好奇心使笔者打印出了测试机调用 rAF 的时间间隔绝大多数间隔在 16.6 毫秒左右意味着手机 webview 也是 60Hz 的刷新频率不过也存在少数间隔时间远超正常刷新时间达到了 30 ~ 70 毫秒如果触发滑动操作可能会超过 100 毫秒。不得不说测试机就要挑这么烂的 Orz…仔细想想测试机上的计时误差本质是采样频率并未一直满足 60Hz当某一次采样时间超过 16.6 毫秒且刚好需要刷新动画时就会产生误差。同时每次误差都是超时而非提前这样就在延时的道路上越走越远了。那么反向思考每当触发更新事件时超时时段超过 1 秒的时间是已知的。如果将其补偿到下一次计时中应该能减缓误差的扩大速度。代码如下观察测试手机打印的时间发现此法完全是可行的。每当超时间隔超过正常的刷新频率 16.6 毫秒时相当于赶上了下一次采样窗口的伊始因此会被校正。相比手机上每隔两三秒校正一次PC 模拟器的采样时间变化显得尤为明显。ReferenceTasks, microtasks, queues and schedulesHow does a single thread handle asynchronous code in JavaScript?HTML Living Standard — Last Updated 25 May 2018Window.requestAnimationFrame()本文作者 John Chou本文链接 https://blog.joouis.com/2018/05/25/optimization-road-of-count-down-timer/版权声明 本博客所有文章除特别声明外均采用 BY-ND 许可协议。转载请注明出处相关文章Javascript 简洁之道如何使用类重构JavaScript 性能优化概观Weex Android 发车指南已弃车十分钟带你了解国产自制开源插件 structure-view小议 Javascript 数组去重
