找回密码
 加入怎通
查看: 196|回复: 1

前端技术分享:页面性能优化问题复盘(页面的性能优化)

[复制链接]
我来看看 发表于 2023-03-15 15:44:04 | 显示全部楼层 |阅读模式
?, l$ f3 l( Q" r0 a9 k

项目背景在 code_pc 项目中,前端需要使用 rrweb 对老师教学内容进行录制,学员可以进行录制回放为减小录制文件体积,当前的录制策略是先录制一次全量快照,后续录制增量快照,录制阶段实际就是通过 MutationObserver 监听 DOM 元素变化,然后将一个个事件 push 到数组中。

; l8 u C: ?3 [$ b

为了进行持久化存储,可以将录制数据压缩后序列化为 JSON 文件老师会将 JSON 文件放入课件包中,打成压缩包上传到教务系统中学员回放时,前端会先下载压缩包,通过 JSZip 解压,取到 JSON 文件后,反序列化再解压后,得到原始的录制数据,再传入 rrwebPlayer 实现录制回放。

" s% L! T* s' a3 ?1 e# O

发现问题在项目开发阶段,测试录制都不会太长,因此录制文件体积不大(在几百 kb),回放比较流畅但随着项目进入测试阶段,模拟长时间上课场景的录制之后,发现录制文件变得很大,达到 10-20 M,QA 同学反映打开学员回放页面的时候,页面明显卡顿,卡顿时间在 20s 以上,在这段时间内,页面交互事件没有任何响应。

. U/ r; L3 A% r8 x7 _

页面性能是影响用户体验的主要因素,对于如此长时间的页面卡顿,用户显然是无法接受的问题排查经过组内沟通后得知,可能导致页面卡顿的主要有两方面因素:前端解压 zip 包,和录制回放文件加载同事怀疑主要是 zip 包解压的问题,同时希望我尝试将解压过程放到 worker 线程中进行。

& E5 h* x. ^) H

那么是否确实如同事所说,前端解压 zip 包导致页面卡顿呢?3.1 解决 Vue 递归复杂对象引起的耗时问题对于页面卡顿问题,首先想到肯定是线程阻塞引起的,这就需要排查哪里出现长任务所谓长任务是指执行耗时在 50ms 以上的任务,大家知道 Chrome 浏览器页面渲染和 V8 引擎用的是一个线程,如果 JS 脚本执行耗时太长,就会阻塞渲染线程,进而导致页面卡顿。

( t. b; F; V/ ^7 M$ c3 N$ x

对于 JS 执行耗时分析,这块大家应该都知道使用 performance 面板在 performance 面板中,通过看火焰图分析 call stack 和执行耗时火焰图中每一个方块的宽度代表执行耗时,方块叠加的高度代表调用栈的深度。

& j8 n6 r" U; r6 w

按照这个思路,我们来看下分析的结果:

2 D* A; g: K" P8 k5 n

可以看到,replayRRweb 显然是一个长任务,耗时接近 18s ,严重阻塞了主线程而 replayRRweb 耗时过长又是因为内部两个调用引起的,分别是左边浅绿色部分和右边深绿色部分我们来看下调用栈,看看哪里哪里耗时比较严重:。

9 Q3 q- ]% \8 R" m9 }* [ B

熟悉 Vue 源码的同学可能已经看出来了,上面这些耗时比较严重的方法,都是 Vue 内部递归响应式的方法(右边显示这些方法来自 vue.runtime.esm.js)为什么这些方法会长时间占用主线程呢?在 Vue 性能优化中有一条:。

8 L& `2 B1 _! F2 |

不要将复杂对象丢到 data 里面,否则会 Vue 会深度遍历对象中的属性添加 getter、setter(即使这些数据不需要用于视图渲染),进而导致性能问题那么在业务代码中是否有这样的问题呢?我们找到了一段。

3 X* Q2 v% s$ c1 D- ]

非常可疑的代码:exportdefault{data(){return{rrWebplayer:null}},mounted(){bus.$on("setRrwebEvents",(eventPromise

" R! R1 z. C( r& r8 t* U+ h4 @

)=>{eventPromise.then((res)=>{this.replayRRweb(JSON.parse(res));})})},methods:{replayRRweb(eventsRes)

" ?: f ]( Z8 n8 N: A

{this.rrWebplayer=newrrwebPlayer({target:document.getElementById(replayer),props:{events:eventsRes,unpackFn

. _; w2 Y, L6 _: d A

:unpack,// ...+ Q+ J1 o2 [* K: h$ U0 _/ T1 }' \ }})}}}在上面的代码中,创建了一个 rrwebPlayer 实例,并赋值给 rrWebplayer 的响应式数据在创建实例的时候,还接受了一个 eventsRes 数组,这个数组非常大,包含几万条数据。

- z _5 ^8 z6 j: {7 J

这种情况下,如果 Vue 对 rrWebplayer 进行递归响应式,想必非常耗时因此,我们需要将 rrWebplayer 变为 Non-reactive data(避免 Vue 递归响应式)转为 Non-reactive data,。

9 v0 `+ R7 m& s' B- d1 _. O

主要有三种方法:数据没有预先定义在 data 选项中,而是在组件实例 created 之后再动态定义 this.rrwebPlayer (没有事先进行依赖收集,不会递归响应式);数据预先定义在 data 选项中,但是后续修改状态的时候,对象经过 Object.freeze 处理(让 Vue 忽略该对象的响应式处理);

( h% r0 I/ K' @8 R6 \: K

数据定义在组件实例之外,以模块私有变量形式定义(这种方式要注意内存泄漏问题,Vue 不会在组件卸载的时候销毁状态);这里我们使用第三种方法,将 rrWebplayer 改成 Non-reactive data 试一下:

% p p4 u/ Q9 n: d2 L' m1 t

letrrWebplayer=null;exportdefault{//.../ B: C2 f' g0 }5 N methods:{replayRRweb(eventsRes){rrWebplayer=newrrwebPlayer({target

+ t. F8 }+ @9 Y V# i. u3 e

:document.getElementById(replayer),props:{events:eventsRes,unpackFn:unpack,// ...6 C8 B$ G7 s, F! t+ l }})}}}重新加载页面,可以看到这时候页面虽然还卡顿,但是卡顿时间明显缩短到5秒内了。

: E& t( s. I' T

观察火焰图可知,replayRRweb 调用栈下,递归响应式的调用栈已经消失不见了:

0 S' y( E7 j. y9 e7 h4 d8 p

3.2 使用时间分片解决回放文件加载耗时问题但是对于用户来说,这样仍然是不可接受的,我们继续看一下哪里耗时严重:

) l. e5 K, w7 p0 m7 S4 I

可以看到问题还是出在 replayRRweb 这个函数里面,到底是哪一步呢:

( }! ?% |) Z2 C( V+ F& ]7 s

那么 unpack 耗时的问题怎么解决呢?由于 rrweb 录制回放 需要进行 dom 操作,必须在主线程运行,不能使用 worker 线程(获取不到 dom API)对于主线程中的长任务,很容易想到的就是通过 时间分片,将长任务分割成一个个小任务,通过事件循环进行任务调度,在主线程空闲且当前帧有空闲时间的时候,执行任务,否则就渲染下一帧。

& M3 [- j' f$ Z9 \- g' O& y, {

方案确定了,下面就是选择哪个 API 和怎么分割任务的问题这里有同学可能会提出疑问,为什么 unpack 过程不能放到 worker 线程执行,worker线程中对数据解压之后返回给主线程加载并回放,这样不就可以实现非阻塞了吗?

. ]3 l8 v& ?! z/ S1 @

如果仔细想一想,当 worker 线程中进行 unpack,主线程必须等待,直到数据解压完成才能进行回放,这跟直接在主线程中 unpack没有本质区别worker 线程只有在有若干并行任务需要执行的时候,才具有性能优势。

; V; W5 p$ t, r5 S) v

提到时间分片,很多同学可能都会想到 requestIdleCallback 这个 APIrequestIdleCallback 可以在浏览器渲染一帧的空闲时间执行任务,从而不阻塞页面渲染、UI 交互事件等。

9 F/ `+ c5 \ M% ~! U. W

目的是为了解决当任务需要长时间占用主进程,导致更高优先级任务(如动画或事件任务),无法及时响应,而带来的页面丢帧(卡死)情况因此,requestIdleCallback 的定位是处理不重要且不紧急的任务。

9 g7 }6 f( z& h! E4 } x

requestIdleCallback 不是每一帧结束都会执行,只有在一帧的 16.6ms中渲染任务结束且还有剩余时间,才会执行这种情况下,下一帧需要在 requestIdleCallback 执行结束才能继续渲染,所以。

! B* o( n9 t! @0 e6 p& W8 ]2 I. N

requestIdleCallback 每个 Tick 执行不要超过30ms,如果长时间不将控制权交还给浏览器,会影响下一帧的渲染,导致页面出现卡顿和事件响应不及时requestIdleCallback 参数说明:。

: Y- v5 k; S2 l

// 接受回调任务 % c7 a8 s, F, y. S typeRequestIdleCallback=(cbdeadlineeadline)=>void,options?:Options)=>number// 回调函数接受的参数+ W& [$ o/ ~% F2 i! t

+ r( I. `; d1 {8 `

typeDeadline={timeRemaining)=>number// 当前剩余的可用时间即该帧剩余时间 # U: P( E& M U$ S) s, n. e+ d! r; U; J didTimeout:boolean// 是否超时 0 s0 d$ a% I- Q7 Q% _/ t1 b }我们可以用 requestIdleCallback 写个简单的 demo:。

, j/ C; m0 m9 g1 q& i" z

// 一万个任务,这里使用 ES2021 数值分隔符7 E5 t/ H& P8 J4 }2 d8 P) ]9 w0 ? constunit=10_000;// 单个任务需要处理如下) y' i% ^6 A! F$ I constonOneUnit=()=>{for(leti=0;i<=500_000;

9 K3 @3 v( I% K: O0 n

i++){}}// 每个任务预留执行时间 8 d6 x& @( l0 r6 N6 J 1msconstFREE_TIME=1;// 执行到第几个任务 let _u = 0; ! S( Y" G2 z+ a o, r9 N functioncb(deadline){// 当任务还没有被处理完 & 一帧还有的空闲时间 > 1ms% S% L: H9 H: w2 n

9 I- k8 N$ E5 Q) p# c

while(_uFREE_TIME){onOneUnit();_u++;}// 任务干完 , g1 t5 p7 {+ ?, R if(_u>=unit)return;// 任务没完成, 继续等空闲执行 / J# j Q! }2 Q3 L$ M6 P! x

: ?4 H3 }" r' ^4 y5 ^) C, X/ R

window.requestIdleCallback(cb)}window.requestIdleCallback(cb)这样看来 requestIdleCallback 似乎很完美,能否直接用在实际业务场景中呢?答案是不行。

. ]$ R, p$ K# J9 L+ u: Q

我们查阅 MDN 文档就可以发现,requestIdleCallback 还只是一个实验性 API,浏览器兼容性一般:

( ]6 u7 G% F5 Y

查阅 caniuse 也得到类似的结论,所有 IE 浏览器不支持,safari 默认情况下不启用:

# z% _; R4 A; C3 P+ ]

而且还有一个问题,requestIdleCallback 触发频率不稳定,受很多因素影响经过实际测试,FPS 只有 20ms 左右,正常情况下渲染一帧时长控制在16.67ms 为了解决上述问题,在 React Fiber 架构中,内部自行实现了一套 requestIdleCallback 机制:。

& y6 b: Z/ m- c$ r% p8 b, k& w

使用 requestAnimationFrame 获取渲染某一帧的开始时间,进而计算出当前帧到期时间点;使用 performance.now() 实现微秒级高精度时间戳,用于计算当前帧剩余时间;使用 MessageChannel 零延迟宏任务实现任务调度,如使用 setTimeout() 则有一个最小的时间阈值,一般是 4ms;

& |* N3 R- T# n

按照上述思路,我们可以简单实现一个 requestIdleCallback 如下:// 当前帧到期时间点 % q7 O5 ]5 J) Q/ [7 I letdeadlineTime;// 回调任务 7 m8 p& X" x8 t+ l letcallback;// 使用宏任务进行任务调度 8 r8 h, l* r8 o

- } ]" k0 d. f, C/ y' o

constchannel=newMessageChannel();constport1=channel.port1;constport2=channel.port2;// 接收并执行宏任务 . H( a$ Z/ g. J0 L! |/ j port2.

( n$ R8 O$ E! i& S; U8 Y3 j

onmessage=()=>{// 判断当前帧是否还有空闲,即返回的是剩下的时间 3 @0 R. }, m: M2 B! f- D% T9 [- Y consttimeRemaining=()=>deadlineTime-performance.now();const_timeRemain

7 S' o! t* a/ R

=timeRemaining();// 有空闲时间 且 有回调任务 " w( Z: U7 v1 l if(_timeRemain>0&&callback){constdeadline={timeRemaining,didTimeout

$ E! d$ G4 {1 K& d

:_timeRemain<0,};// 执行回调# K6 {# h. r; b9 W callback(deadline);}};window.requestIdleCallback=function(cb){requestAnimationFrame

8 k' O, W1 F0 M& @) F

((rafTime)=>{// 结束时间点 = 开始时间点 + 一帧用时16.667ms , Y+ M; Q2 C" i7 o6 q deadlineTime=rafTime+16.667;// 保存任务 : z* T+ t; Y& M5 S callback=cb;// 发送个宏任务 . M6 P1 O3 R4 O1 n# {. m7 I9 l

) d p' V7 e7 U+ U

port1.postMessage(null);});};在项目中,考虑到 api fallback 方案、以及支持取消任务功能(上面的代码比较简单,仅仅只有添加任务功能,无法取消任务),最终选用 React 官方源码实现。

4 x$ m9 K ?0 O, ]3 v$ L+ n

那么 API 的问题解决了,剩下就是怎么分割任务的问题查阅 rrweb 文档得知,rrWebplayer 实例上提供一个 addEvent 方法,用于动态添加回放数据,可用于实时直播等场景按照这个思路,我们可以将录制回放数据进行分片,分多次调用 addEvent 添加。

% x a2 C8 i0 s# x4 B, B

import{requestHostCallback,cancelHostCallback,}from"@/utils/SchedulerHostConfig";exportdefault{// ... - \2 v# D9 B1 P! \8 T

; s9 [7 p! X. W) K4 U3 e

methods:{replayRRweb(eventsRes=[]){constPACKAGE_SIZE=100;// 分片大小 6 W2 U& q, `$ t$ |4 y constLEN=eventsRes.length;// 录制回放数据总条数8 A$ w, n( h7 @; O* _ a3 `* ~

6 K: {+ e' i0 i: m/ ^+ ?

constSLICE_NUM=Math.ceil(LEN/PACKAGE_SIZE);// 分片数量" v6 v. h/ k. {& d6 |5 D* v rrWebplayer=newrrwebPlayer({target:document.getElementById

" F# W1 p- c! {7 E6 v

("replayer"),props:{// 预加载分片) E, _& N# O( n: g, E o events:eventsRes.slice(0,PACKAGE_SIZE),unpackFn:unpack,},});// 如有任务先取消之前的任务% v8 M$ k8 }- L8 i: s9 ?( {# Q9 b

! e2 X4 K; {9 |/ k9 h! ?

cancelHostCallback();constcb=()=>{// 执行到第几个任务4 v9 g& ?2 X X+ ] let_u=1;return()=>{// 每一次执行的任务 ; e- h' W/ {& M5 l% O1 a# q _ // 注意数组的 forEach 没办法从中间某个位置开始遍历4 N' E8 `# d6 ?4 P8 v) `

( u( }3 O: s* I, e }% [+ _; T

for(letj=_u*PACKAGE_SIZE;j=LEN)break;rrWebplayer.addEvent(eventsRes[j]);

g3 @. B- f( u1 Q$ a/ m

}_u++;// 返回任务是否完成 5 \7 R5 k( Q$ i% S9 U# B+ E' A5 K return_u{// 加载完毕回调 5 ]/ X# K( e3 V });},},};注意最后加载完毕回调,源码中不提供这个功能,是本人自行修改源码加上的。

& Q$ v$ z6 b% R8 {

按照上面的方案,我们重新加载学员回放页面看看,现在已经基本察觉不到卡顿了我们找一个 20M 大文件加载,观察下火焰图可知,录制文件加载任务已经被分割为一条条很细的小任务,每个任务执行的时间在 10-20ms 左右,已经不会明显阻塞主线程了:。

# c& L) p1 Z' W! S4 g$ W9 v

优化后,页面仍有卡顿,这是因为我们拆分任务的粒度是 100 条,这种情况下加载录制回放仍有压力,我们观察 fps 只有十几,会有卡顿感我们继续将粒度调整到 10 条,这时候页面加载明显流畅了,基本上 fps 能达到 50 以上,但录制回放加载的总时间略微变长了。

6 P' O3 I7 Q( O

使用时间分片方式可以避免页面卡死,但是录制回放的加载平均还需要几秒钟时间,部分大文件可能需要十秒左右,我们在这种耗时任务处理的时候加一个 loading 效果,以防用户在录制文件加载完成之前就开始播放有同学可能会问,既然都加 loading 了,为什么还要时间分片呢?假如不进行时间分片,由于 JS 脚本一直占用主线程,阻塞 UI 线程,这个 loading 动画是不会展示的,只有通过时间分片的方式,把主线程让出来,才能让一些优先级更高的任务(例如 UI 渲染、页面交互事件)执行,这样 loading 动画就有机会展示了。

5 Z( Z8 i" n" p8 t" k) v0 e

进一步优化使用时间分片并不是没有缺点,正如上面提到的,录制回放加载的总时间略微变长了但是好在 10-20M 录制文件只出现在测试场景中,老师实际上课录制的文件都在 10M 以下,经过测试录制回放可以在 2s 左右就加载完毕,学员不会等待很久。

1 O* f/ N* z7 F5 Z1 [# |

假如后续录制文件很大,需要怎么优化呢?之前提到的 unpack 过程,我们没有放到 worker 线程执行,这是因为考虑到放在 worker 线程,主线程还得等待 worker 线程执行完毕,跟放在主线程执行没有区别。

' P! C& o! `. V1 B+ g' V

但是受到时间分片启发,我们可以将 unpack 的任务也进行分片处理,然后根据 navigator.hardwareConcurrency 这个 API,开启多线程(线程数等于用户 CPU 逻辑内核数),以并行的方式执行 unpack ,由于利用多核 CPU 性能,应该能够显著提升录制文件加载速率。

! m8 E0 C' W$ h+ i

总结这篇文章中,我们通过 performance 面板的火焰图分析了调用栈和执行耗时,进而排查出两个引起性能问题的因素:Vue 复杂对象递归响应式,和录制回放文件加载对于 Vue 复杂对象递归响应式引起的耗时问题,本文提出的解决方案是,将该对象转为非响应式数据。

, P1 f4 F2 N# L

对于录制回放文件加载引起的耗时问题,本文提出的方案是使用时间分片由于 requestIdleCallback API 的兼容性及触发频率不稳定问题,本文参考了 React 17 源码分析了如何实现 requestIdleCallback 调度,并最终采用 React 源码实现了时间分片。

& s0 ~0 f& R9 {6 D: h% P

经过实际测试,优化前页面卡顿 20s 左右,优化后已经察觉不到卡顿,fps 能达到 50 以上但是使用时间分片之后,录制文件加载时间略微变长了后续的优化方向是将 unpack 过程进行分片,开启多线程,以并行方式执行 unpack,充分利用多核 CPU 性能。

1 [9 [- M) m& ?& T+ t

参考· vue-9-perf-secrets· React Fiber很难?六个问题助你理解· requestIdleCallback - MDN· requestIdleCallback - caniuse

5 L/ h2 e# L8 @: f8 S- F

· 实现React requestIdleCallback调度能力详情可点击这里查看

, b- l3 T4 s: U3 { + a& m, Y% x! ]1 r; A5 Q$ m, P& R* d i; C# s/ P8 o! I% U! J- q5 j - w W8 q. Y8 f8 S # u+ j" O: f% ]. u
回复

使用道具 举报

2268030878 发表于 2026-07-08 18:34:05 | 显示全部楼层
完全赞同,我也是这么认为的,英雄所见略同~
回复

使用道具 举报

    您需要登录后才可以回帖 登录 | 加入怎通

    本版积分规则

    QQ|手机版|小黑屋|网站地图|真牛社区 ( 苏ICP备2023040716号-2 )

    GMT+8, 2026-7-8 22:33 , Processed in 0.046461 second(s), 24 queries , Gzip On.

    免责声明:本站信息来自互联网,本站不对其内容真实性负责,如有侵权等情况请联系420897364#qq.com(把#换成@)删除。

    Powered by Discuz! X3.5

    快速回复 返回顶部 返回列表