前端热更新初步了解

﹏ヽ暗。殇╰゛Y 2022-04-08 16:54 334阅读 0赞

**前端页面热更新**

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

**方案概述**

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

**应用场景**

场景一：APP内嵌页面。

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

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

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

**需求细化**

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

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

完整流程图如图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]

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

--------------------

还可以参考文章：  
[https://www.zhihu.com/question/53386694][https_www.zhihu.com_question_53386694]  
[https://segmentfault.com/a/1190000004151580][https_segmentfault.com_a_1190000004151580]  
[https://juejin.im/post/5a0004966fb9a045167c93f1\#comment][https_juejin.im_post_5a0004966fb9a045167c93f1_comment]  
[https://www.jianshu.com/p/f4c7254f4e24][https_www.jianshu.com_p_f4c7254f4e24]  
[https://blog.csdn.net/yusirxiaer/article/details/73182262][https_blog.csdn.net_yusirxiaer_article_details_73182262]

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

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

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

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]: /images/20220404/94d6d25604e44a66ad4a529254d5dea9.png
[https_refined-x.com_2018_02_07]: https://refined-x.com/2018/02/07/%E5%89%8D%E7%AB%AF%E9%A1%B5%E9%9D%A2%E7%83%AD%E6%9B%B4%E6%96%B0%E5%AE%9E%E7%8E%B0%E6%96%B9%E6%A1%88/
[https_github.com_tower1229_WEB-OTA]: https://github.com/tower1229/WEB-OTA
[https_www.zhihu.com_question_53386694]: https://www.zhihu.com/question/53386694
[https_segmentfault.com_a_1190000004151580]: https://segmentfault.com/a/1190000004151580
[https_juejin.im_post_5a0004966fb9a045167c93f1_comment]: https://juejin.im/post/5a0004966fb9a045167c93f1#comment
[https_www.jianshu.com_p_f4c7254f4e24]: https://www.jianshu.com/p/f4c7254f4e24
[https_blog.csdn.net_yusirxiaer_article_details_73182262]: https://blog.csdn.net/yusirxiaer/article/details/73182262