本文主要是介绍亿级流量高并发春晚互动前端技术揭秘 - 学习笔记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
主要学习到在面对大规模、高并发的场景下，确保系统的稳定性和性能，为用户提供稳定流畅的互动体验。前端都用到那些技术，做了哪些努力和创新。
文章链接：https://my.oschina.net/u/4090830/blog/11032956
一、静态资源优化
1.首屏资源加载策略
为了降低页面打开时的请求次数和资源体积，根据页面交互，将所需资源分为三类：首屏、次屏以及操作后。
首屏资源主要包括：HTML 文档、JavaScript、CSS 以及样式图片。由于这是单页面应用，可以通过常规技术将 JS 和 CSS 进行打包。对于样式图片，通过按需加载的方式，显著减小首屏资源体积。
下面将进一步讲解具体的优化方法
1-1.动画图片低损压缩
设计团队将3D 动画转化为精灵图，并将不变部分（如鼓架）单独抽离。精灵图仅包含运动部分（如鼓面敲击动画），有效降低资源消耗。
精灵图进行进一步优化，通过抽帧方式将击鼓精灵图从 24 帧降至 4 帧，结合降质参数和WebP格式，精灵图下降了 93%。此外，将主光效换成放大一倍的一倍图，并通过 CSS 属性 scale 实现放大，进一步节省资源。
1-2.标题雪碧图方案的演进
元素背景图使用雪碧图模式，是前端基本优化手段，可以显著降低请求次数。相较于常规方案，春晚红包还扩展了 2 个功能：
1、css 雪碧图在运行时为图片 URL 添加CDN降质参数和 webp 格式转换参数（someimage.png!q70.webp）
极限降低 CDN 带宽。因为并不是所有环境都支持webp，所以还需要通过运行时检测 webp 支持特性，切换 HTML 标签上的 class 名，来使对应的后代选择器的background-image属性生效。
关于特性检测，有两种技术方案：
a、通过版本判断，从 caniuse 看，可以按照只有 iOS14 以下不支持 webp 来作为判断依据。这个方案的优势是：通过 UA 判断系统版本是同步执行的，可以在调用渲染页面前的任意地方执行并修改 HTML 标签的 class 属性。确保内容渲染后有正确的背景图 css 生效。不会对原有渲染逻辑产生入侵性修改。
b、通过创建一个 Image 对象，其 src 为一个基于 base64 的 webp 图片，根据 load 是否成功来判断是否支持 webp。优势是经过大规模实践，判断逻辑的可靠性较高，缺点是异步逻辑的，需要修改原来的渲染逻辑。
2、动态雪碧图
有些图片需要通过接口调取后再获取。所以无法使用编译时雪碧图方案。为了将图片请求次数减少到 1 次，设计同学根据产品提前确认图片位置将多张图片拼到一张雪碧图上，通过固定的background-position属性，动态设置className和背景图，可实现动态背景图。
二、 降低服务器成本及风险
1.流量削峰
找到流量最大的接口，进行削峰
1-1. 初始化接口
在页面加载之前，即资源位入口，配置一个 “加载中” 页面链接。这个页面随机加载 1-3 秒后跳转到活动页面。当流量超过系统承载能力时，开启灰度开关，部分用户进入此页面，然后等待几秒后进入活动页面。
1-2. 击鼓抽奖接口
本次活动的核心玩法接口。如果仅仅是简单地随机延时几秒请求，会极大地影响用户体验。我们采用更精细化的处理方式。已知击鼓交互在用户敲击满次数或倒计时结束时触发抽奖接口，因此，随机设定敲鼓次数，将原本集中在 1-2 秒内的请求打散至 10 秒区间，用户几乎无感知。
2.即时状态的本地存储
前端可以通过本地存储一些状态，提升性能和优化用户体验，前端本地存储机制的优缺点：
- cookie存储空间较小（4K），且在与服务端通信时会占用请求头部，可能导致请求头过大，超过服务端设置的最大值，进而引发报错，并增加不必要的网络消耗。
- sessionStorage生命周期较短，仅适用于会话期间。
- localStorage具有较长的生命周期和较大的储存空间（2.5M-4M），能满足业务需求。
采用localStorage缓存数据，不仅可以简化调用链路、降低风险和节约成本，还能直接从本地读取券的领取状态，避免网络延迟导致的响应时间过长，提升用户体验。
这篇关于亿级流量高并发春晚互动前端技术揭秘 - 学习笔记的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
