设计有关的网站,九江百度公司,创意合肥网站建设,做门户网站最重要的是什么意思问题背景
在上个月#xff0c;由于客户反馈客户端卡死现象但我们远程却难以复现此现象#xff0c;于是我们组织了一次现场上门故障排查#xff0c;并希望基于此次观察与优化#xff0c;为客户端开发提供一些整体的优化升级。当然#xff0c;在尝试过程中#xff0c;也发…问题背景
在上个月由于客户反馈客户端卡死现象但我们远程却难以复现此现象于是我们组织了一次现场上门故障排查并希望基于此次观察与优化为客户端开发提供一些整体的优化升级。当然在尝试过程中也发现了不少适用于通用前端项目开发的一些故障排查与性能评估的手段于是总结此文希望可以对读者有所帮助。
需要注意在本文中所指的客户端均指通过 electron 开发出来的客户端应用所以本质上还是属于前端应用开发范畴关于 electron 框架的介绍可以参考 https://www.electronjs.org/
现象复现
在客户那边反馈过来的现象表现为“系统 CPU 资源未被占满但客户端在操作一段时间后便卡死无法响应”。起初我们根据用户的描述尝试在本地复现但却没有收获此外由于客户的网络限制也不方便频繁的远程连接以方便我们查看现场现象。
考虑到可能是机器部分配置较差比如显卡或者网络、机器自身运行软件过多等原因而我们的开发机器由于要支持本地编译与调试一般都是顶配机器于是我们尝试让本机变慢以模拟复现其现象简单来看存在如下几个思路
卡死/卡顿复现最好在虚拟机中操作虚拟机本身分配资源相对主机较少再加上 chrome devtools 配置增加延时 throttle 时长比如500ms电脑中再开启几个占用 CPU 性能的软件比如 vscodefirefox 等等可以一定程度上模拟卡顿现象不一定稳定复现卡死现象操作卡顿复现通过频繁的交互操作制造同时多个请求并发发出的现象加上 performance 录制可以一定程度加重渲染进程的负担以模拟操作卡顿现象
定位问题
来到客户现场作为首要尝试当然是通过 top 、netstat 或者 cat /proc/cpuinfo 等命令来查看系统的 CPU、内存与网络的运行状态但不出所料这些信息在当前看来并没有太大异常。
由于从系统本身的一些状态上没能找到突破口我们将目光转向客户端本身希望在更小的范围内定位问题所在。通过 devtools 查看 netowork、performance 以及 DOM 渲染状态我们只能发现貌似有些响应耗时过长的接口调用以及较长时长的 long task 任务这当然需要我们进一步排查。
说到调试排查首推的当然是 console.log 大法为了让 log 打印复用一个简单的技巧是写一个 HOC以节省在每个地方都写一遍 debug log 的代码
export const debugRender Tany(BaseComponent: FCT) (props:any) {console.log(Rendering ${BaseComponent.name} at ${performance.now()});return BaseComponent {...props} /;
}通过添加一些基于经验的断点信息打印我们发现一些 Modal/Drawer 的显示/隐藏会较为明显的加重页面卡顿甚至到卡死现象上通过排查代码实现以及查看对应 UI 库的 API 实现会发现其中 Modal/Drawer 等组件上在隐藏时触发了其对应 DOM 节点的卸载而在显示时又会重新渲染与插入由于这些任务都需要在浏览器的渲染进程执行而当 DOM 节点过多时频繁的节点装载与卸载便会对页面渲染效率产生影响。
于是第一步便是定位到主要的几个组件避免其在隐藏时执行 DOM 卸载保留节点通过这一步改变我们直接消除了卡死现象。
部分优化尝试
为了更好的模拟卡顿现象我们可以通过 chrome devtools 中 performance tab 中的 CPU throttling 配置来模拟卡顿 在 Windows 高配版机器上我们先将 CPU 降低配置 4x 情况然后录制一段操作从下图中可以看出有明显的任务执行耗时过长 CPU 占用过高的现象 以耗时最长的任务中占用时间最长的活动为例我们搜索一下该关键词可以查到一个讨论 https://stackoverflow.com/questions/39916356/reacterrorutils-invokeguardedcallback-in-react-fires-event-repeatedly-in-ie-brow简单来说我们可以尝试优化点击事件不进行冒泡来减少事件的触发例如
event.stopPropagation();通过优化该事件我们可以一定程度上对事件在 DOM 上的传递 调用进行优化但说到交互事件模型我们在实际优化尝试时也需要对 Web API 有些了解以防用错 Web API 而南辕北辙比如一个常见的面试题就是对比 Event 上暴露的两个 API stoppropagation 与 stopimmediatepropagation 的用途区别可别用错了。关于此细节可以参考回答 https://stackoverflow.com/questions/5299740/stoppropagation-vs-stopimmediatepropagation
但假如我们需要针对不同事件切换不同的 API 该怎么办呢这里可以简单写个函数封装一下再加个类型守卫来实现比如如下的伪代码通过传入一个点击回调事件而后在实际事件触发时通过判断 Event 类型从而调用不同 API 以达到优化效果
const isMouseEvent (event: Event | MouseEvent): event is MouseEvent stopImmediatePropagation in eventexport const stopPropagationWrapper (handleClick: Func) (event: Event | MouseEvent) {if (isMouseEvent(event)) {event.stopImmediatePropagation();} else {event.stopPropagation();}handleClick(event);
};我们继续针对卡顿问题的调用情况进行梳理。从录制的执行队列中选取较长的一个 long task 进行分析可以看到在模拟卡顿时排名靠前四的调用任务分别如下 其中 fsync 函数调用时间占第一而拆分 fsync 的活动调用可以看到主要调用了 fsyncSync 此处未对 fsync 进一步分析以确定优化策略但对于 fsync 的作用可以参考如下一段描述 fsync 函数只对由文件描述符 filedes 指定的单一文件起作用并且等待写磁盘操作结束然后返回。fsync 可用于数据库这样的应用程序这种应用程序需要确保将修改过的块立即写到磁盘上。 这说明应用中有可能有数据库读写操作也可能有文件读写操作所以如果要进一步优化的话可以从这个方面展开囿于时间限制我们继续探索可行的快捷优化方案。
在最初解决卡死问题时我们看到了过多的 DOM 卸载/挂载现象但回到前端框架本身我们也可以用一些常规的手段来减少组件不必要的 rerender这些方案通常通过仔细阅读 React 文档便可以略知一二比如在必要的地方增加 memo 以减少不必要的渲染执行一个示例代码如下
import {FC,memo,
} from react;const Detail: FC ({}) {return (divDetail/div);
}export default memo(Detail);此外还有什么写法可能会影响 Web 应用的性能呢闭包。
我们检查了客户端代码仓库里的两个列表文件发现其中组件包含过多闭包变量大多数写法是在一些函数定义中直接从上层作用域引用了一些变量进行操作而不是通过参数传入函数这样的数据/函数在使用后无法及时释放内存空间可能会对内存存在持续占用的现象因此这也是优化的方向之一。
后续可能的优化空间
在一些 long task 任务的分析中我们还可以具体定位到代码来进行优化这里再举一个例子。
通过录制卡死情况下的堆栈调用情况可以发现有一个 2.7s 任务中包含很多活动如 Minor GC、react event、fsync、ReactElement 等等其中 mergeProps 函数调用耗时250ms。 针对这些函数调用有些可能是 React 内部实现 API有些可能是 UI 库 API所以要想一一优化也需要逐个分析看是优化代码的调用与响应方式还是合并组件 props 的传递与调用。 此外通过监控 layers 变化情况也会发现一些 slow scroll rects这在 chrome 中都会通过红色区域以标注出来通过定位这些在滚动中可能会造成缓慢的区域并检查代码也有提升应用性能的可能性因此也是优化方向之一。 比如针对我们的场景通过调整 layer 布局可以看到虽然 layer 层级很多但是主要的 slow scroll rects 区域还是集中在主内容区即分页列表本身。 Electron 注意事项
本来为了可以针对这些数据进行持续的分析想从 performance 中将数据下载下来以便之后有空时继续调试但由于 Electron 的某些限制或者说是错误我们目前无法保存 performance tab 下的性能数据到本地以便进行更深入的分析和查看。如果有涉及到 electron 开发的场景需要注意下这个问题。问题现象详见 issue https://github.com/electron/electron/issues/39818
优化效果
为了提高客户端的性能和用户体验我们进行了一系列的优化措施。首先我们分析了卡死现象包括客户端出现卡死时的 CPU 占用率/JS 堆栈/DOM 节点数情况、虚拟机运行状态等。然后我们尝试了一些优化措施如去除Modal/Drawer的 unmountOnExit 配置等。接下来我们梳理了卡顿问题调用情况分析了排名靠前的四个调用任务。为了减少组件不必要的rerender我们在必要的地方增加了 memo。此外我们还提到了组件中包含过多闭包的问题以及右键菜单卡顿问题的排查。
由于客户端需求迭代过快在前端技术上没有做较多的数据监控、性能评估等建设这都对我们评估用户体验与定位问题产生了影响此外由于生产工具链的不完善在生产环境进行定位与调试都给我们带来了比较大的挑战与时间消耗这也会是我们持续要跟进与解决的一些开发链路的效率提升工作之一。
通过这些优化我们希望能够解决客户端卡死问题并改善卡顿现象并提高用户的使用体验。当然从具体效果上来看我们确实在如下两个方面进行了改善
交互性能上问题页面在切换时即便将 CPU 降低配置 4x 情况下也再无出现卡死现象卡顿现象有减轻趋势渲染效率上从数据上看频繁出现的 500ms-700ms long task 已减为当前观察范围内没有超过 300ms 的 long task代码执行效率上有较大提升
以下为优化后效果采样图 简要总结
通过分析与优化尝试我们解决了客户端卡死问题并改善了卡顿现象但其中暴露出一些编程规范与用法不够优雅的问题还需要在日常中持续完善这也是这次优化未尽事宜需要在未来不断排期以彻底解决。
当然此中涉及到的一些调试与问题定位方法也不仅局限于客户端的问题排查而是通用 Web 应用性能评估时调试可以用到的手段而更深入的研究则要开始涉猎到框架代码等内部函数调用的地方了这也是本文未涉及部分有待后续继续研究与定位。 原文地址 基于一次应用卡死问题所做的前端性能评估与优化尝试
