前端热更新初步了解

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u014465934/article/details/85088605

前端页面热更新

了解过前端性能优化的同学应该清楚,给页面加载提速的终极方案就是CDN,这是BS架构本身的特点决定的,无论什么前端提速手段,最终都会回到客户端文件的传输上来;与之相对的CS架构则不存在加载压力,但CS架构的问题是更新不灵活,那么有没有一种方法能结合这两种架构的优点,在加载速度和更新灵活性之间找到一个平衡点呢?这就是本文要探讨的一种方案:前端热更新。

方案概述

“前端”和“热更新”这两个词通常很少一起出现,提到热更新一般都是指APP的一种静默更新方式,这种方式会在用户使用时悄悄检测并下载增量更新包,当用户下次打开APP时自动应用更新,从而将APP“更新”这个破坏连贯性的动作隐藏于无形;前端页面的加载则相当于每次都是“全量更新”,如果能让前端页面也能用上“本地模板”,那将极大缩短前端加载时间,而且以此为前提,我们也可以实现一个前端的模板热更新机制,做到不影响页面更新的实时性。

应用场景

场景一:APP内嵌页面。

比如电商类APP的首页,经常需要改版或者做活动皮肤,如何减少更新成本就成了一个大问题。使用了热更新方案我们就可以用HTML实现APP首页,页面内容以模板的形式存进localStorage,后台静默更新模板,下次启动自动生效;针对具有一定时效性的活动皮肤,我们以补丁的形式发布,补丁文件叠加在模板上产生最终的活动模板效果,对于补丁包我们可以提前加载并预存在本地,补丁包应该包含自身的生效时段信息,前端检测到时间处于活动周期内时应用补丁。最终可以做到热更新页面无论改版还是做活动,只需要前端发版就可以,完全不需要APP端参与。

场景二:追求加载速度的web页面。

对于web页面来说更新不是问题,加载才是最大的问题,如果个别页面希望极致提升页面展现速度,那么也可以使用该方案作为提速手段,但因为页面的所有代码都将存进localStorage,所以不适合大范围使用。

需求细化

综合以上场景和需求,最终我们要做的东西是一个“壳”页面,该页面没有具体业务内容,只实现热更新功能,每次加载都先检查localStorage中是否存在模板,如果有则立即应用模板,此时页面展现出来,如果没有则进入下一步;下一步页面会请求模板管理接口获取最新模板信息,拿到模板信息后如果本地已有模板,则与本地模板比对版本信息,如果版本一致说明缓存命中,流程结束;如果本地版本不是最新,则获取最新模板并存进本地,下次页面加载时将应用最新的模板,流程结束;另一种情况是首次加载本地没有任何模板,那么将获取最新模板,保存到本地,然后应用模板,流程结束。

前面说的是稳定模板的更新流程,稳定模板流程结束后会进入补丁模板更新流程。首先仍然是检查本地是否存在补丁模板,如果已存在则检测当前时间是否匹配补丁的生效时段,匹配则应用补丁,不匹配将进入下一步;下一步将获取最新补丁模板并存到本地,然后检测当前时间是否匹配最新补丁的生效时段,如果匹配则应用模板,不匹配流程结束。

完整流程图如图所示:

在这里插入图片描述

详细介绍可以参考文章:
https://refined-x.com/2018/02/07/前端页面热更新实现方案/
https://github.com/tower1229/WEB-OTA


还可以参考文章:
https://www.zhihu.com/question/53386694
https://segmentfault.com/a/1190000004151580
https://juejin.im/post/5a0004966fb9a045167c93f1#comment
https://www.jianshu.com/p/f4c7254f4e24
https://blog.csdn.net/yusirxiaer/article/details/73182262

摘抄下上面尤雨溪的回答,感觉换了个思路。

问题:要做一个设备监控的系统,一个设备可能会有上百个的监控数据,一个页面可能会有上百台设备。页面需要做大量的频繁的热数据更新。请问这种需求,Vue或者angular2.0可以满足要求么?

回答:单讲性能,几百个数据的更新对于目前的主流框架来说,应该都不会构成什么瓶颈(桌面端而言)。但是这其实不仅仅是个技术问题:产品 / UX 层面,你要考虑一个『用户信息接收量』的问题。首先即使是实时数据,对于用户来说更新频率也不是越快越好的。不仅仅是框架更新速度可能有瓶颈,人类接收信息的速度也有瓶颈。举例来说,除非是图像,否则 60fps 的实时更新在大多数时候是信息量过剩的。从这个思路出发,最简单的保证性能的做法就是对更新进行 buffer/batch:不要新数据一来就立刻刷新,而是推到一个队列里面,定时一次性刷新出去。其次,页面上一次性展示的数据也不是越多越好。想象一下几百个单元格/图表不停地刷新(比如 dbmon benchmark),你觉得你能从里面获取多少有效信息?倒不如从设计的角度去思考一下如何切分页面,精简单个页面上的信息从而让它们更容易被用户接收。移动端更是如此:几寸大的屏幕上,信息展示量非常有限,更多的时候要考虑的是『信息量』的优化。而当你从信息量的角度重新思考过后,可能会发现一些所谓的『性能问题』也不复存在了。

最后,我们还可以利用webpack和gulp实现热更新,暂时了解这些,等进一步了解。

猜你喜欢

转载自blog.csdn.net/u014465934/article/details/85088605