一、关键字
白屏、闪屏、卡顿、页面崩溃、渲染异常
二、概述
项目开发、交付过程中，偶尔会遇到白屏、闪屏和卡顿现象。造成此类问题的原因有很多，例如内存不足、显存不足、内存泄漏等，但想要精确定位到具体什么原因导致的性能问题，如果没有相关的排查经验、没有一个明确的排查思路，那此类问题是非常不易排查，且耗时耗力的。
白屏、闪屏和卡顿问题会导致用户体验很差，客户对此类问题的容忍度一般都非常低，一旦出现，必然希望从速解决，越快越好。是故，如果每次遇到此类问题，都毫无章程的随缘排查，成本太高，效率无法保障。所以，整理一份排查指南，总结以往经验，既拉低人员要求，又降本增效，一劳永逸。
三、异常分析
总结、分析白屏、闪屏和卡顿的常见原因，及这些问题出现时需要重点排查的指标。
白屏的常见原因
一般白屏现象主要观察内存和显存的使用情况。浏览器的渲染进程和GPU进程的正常工作均离不开内存和显存。这两个进程只要有一个出问题，就会直接影响前端页面的展示。
小贴士：渲染进程和GPU进程有什么联系？
浏览器的渲染进程会将页面中的图形元素发送给GPU进程，GPU进程则将接收到的图形元素渲染成最终的图像，然后将渲染后的图像发送回渲染进程，最终显示在屏幕上。也就是说，GPU进程和渲染进程只要有一个出问题，另一个也会收到波及，最终导致页面无法正常显示。而内存和显存二者都能够影响这两个进程。
1、内存溢出
前端页面的展示离不开内存，计算机内存不足会对浏览器渲染进程/GPU进程产生负面影响，严重的话会导致渲染进程/GPU进程崩溃，进而导致页面白屏，更准确的说是页面崩溃。
渲染进程又被称为渲染引擎，其需要借助内存来存储和处理图像或其他页面内容，当内存不足时，将无法正常加载和渲染页面内容。GPU进程也需要借助内存来存储和处理图形数据，以便更快的渲染图形。
小场景：前端服务正常启动后，直接就无法正常加载、渲染和显示，可优先排查内存是否溢出，若溢出，则需升级硬件配置（增大运行内存）。
小贴士：什么是内存溢出？
内存溢出是指程序试图使用的内存超过了可用内存。
2、内存泄漏
内存泄漏导致的白屏是由于内存耗尽引起的，也就是页面实际耗用的内存超出预期内存。当存在内存泄漏时，随着泄漏的持续，轻则页面出现卡顿、闪屏，严重的会导致内存溢出，进而可能造成渲染进程/GPU进程崩溃，引发页面白屏（页面崩溃）。·
小场景：与内存溢出不同，前端服务刚启动时，可以正常加载、渲染和显示页面，但随着时间推移，页面逐渐出现卡顿现象，且运行时间越久，卡顿越明显，严重时甚至页面崩溃，此时可优先排查是否存在内存泄漏（监测内存增长）。
小贴士：什么是内存泄漏？
内存泄漏是指程序未正确释放已分配内存，从而导致系统内存的浪费。如果内存泄漏持续发生，最终会导致内存溢出，从而影响系统的正常运行。
3、显存不足，显存溢出
前端页面的展示离不开显存。显存不足会导致GPU性能下降，会影响浏览器页面的渲染进程/GPU进程，页面无法正常加载所需资源，页面的展示会受到影响，最直接的表现就是页面的渲染和显示速度下降，导致卡顿、闪屏，严重时可造成页面白屏，甚至当显存溢出时，极有可能导致页面的渲染进程/GPU进程崩溃，进而页面崩溃。
显存溢出比显存不足情节更加严重，根据溢出的程度，可造成页面白屏，甚至页面崩溃。如果溢出的程度较轻，可能只会造成页面白屏。若溢出的程度较重，则可能导致页面崩溃。
小场景：前端服务正常启动后，直接就无法正常加载、渲染和显示，排除内存溢出后，可优先排查显存是否不足或已然溢出，若显存确实不够，则需升级显卡。
小场景：基于WebGL的3D场景在高分辨率下展示时，容易出现白屏，是因为在大分辨率场景下，显存溢出，会导致WebGL崩溃，从而导致3D场景无法正常加载，可能导致出现白屏。
小贴士：显存不足和显存溢出的区别？
显存不足是指显存容量不足以支撑浏览器进程的正常工作。显存溢出是指程序试图使用的显存超过了可用显存容量。
4、CPU利用率满载
CPU利用率达到百分之90左右，甚至满载（100%）时，可能会造成页面白屏，甚至崩溃。因为CPU利用率长时间处于满载状态，导致系统资源不足，可能造成无法正常处理页面上的任务，从而导致页面白屏，乃至崩溃。
小贴士：造成CPU利用率满载的原因有很多，例如运行程序太多导致资源不足、程序出故障/死循环/内存泄漏/缓存污染/网络阻塞等导致CPU资源被大量占用。
5、GPU利用率满载
GPU利用率满载会导致GPU资源不足，从而导致页面无法正常加载，可能会导致页面白屏，甚至崩溃。
小贴士：造成GPU利用率满载的原因有很多，例如GPU内存不足、GPU运行时间过长\运行任务过多、GPU硬件问题等。
6、浏览器内核版本低
浏览器内核版本过低可能会出现网页代码的不兼容，从而导致页面无法正常显示，严重的引发闪屏、白屏。
7、浏览器没开硬件加速
浏览器不开硬件加速，也可能会导致页面卡顿、闪屏和白屏问题。
开启硬件加速可以让浏览器更快速的渲染页面，通常情况下，浏览器默认开启硬件加速，但如果电脑显卡较老或者驱动程序不兼容，可能会导致硬件加速无法开启，从而出现卡顿、闪屏甚至白屏问题。如果出现这些问题，可以尝试升级电脑的显卡驱动程序或在浏览器设置中手动开发硬件加速。
小贴士：谷歌浏览器怎么手动开启硬件加速？
- 步骤1：打开谷歌浏览器并在地址栏输入chrome://settings
- 步骤2：在“系统”标题下找到“使用硬件加速模式（如果可用）”并开启它
- 步骤3：重新启动浏览器以使更改生效
8、其他原因
当然，能够造成白屏的原因绝对不止以上七种，例如网络影响、带宽瓶颈、浏览器兼容问题、服务器问题、脚本加载失败/脚本报错/脚本阻塞、样式表加载失败/样式阻塞等都有可能造成白屏。
闪屏的常见原因
闪屏是指屏幕上出现白色或其他颜色的闪烁。闪屏和白屏可以归为一类问题，闪屏是暂时、偶发性的，所以其严重程度比白屏要轻。凡是能造成白屏的因素，在没有引发白屏之前，都有可能造成闪屏。
近期项目中实际遇到过的引发闪屏的因素有两类。
1、谷歌浏览器内核过低
内核版本过低可能会出现网页代码的不兼容，从而导致页面无法正常显示，可能引发闪屏。
2、页面中的多媒体文件拖慢页面性能
前端页面中的多媒体文件例如视频、动态图片等，会占用更多的内存和显存，因为它们需要更多的存储空间来存储和处理图像、音视频文件。此外，多媒体文件还需要更多的处理能力来渲染和播放，以及更多的网络带宽来传输。
小技巧：页面中多媒体文件尺寸保持不变，文件越小，内存和显存消耗越小。页面中多媒体文件大小保持不变，尺寸越小，内存和显存消耗越小。
卡顿的常见原因
卡顿和闪屏、白屏可以归为一类问题，卡顿的严重程度比闪屏要轻，凡是能造成闪屏、白屏的因素，在没有引发闪屏和白屏之前，都有可能造成卡顿。
近期项目中实际遇到过的引发卡顿的因素有两类。
1、页面中存在多媒体图表组件（数量多或文件大或尺寸大，或多方面都占）
当浏览器内存和显存消耗过大时，可能会造成页面卡顿。而多媒体文件例如视频和动态图片对内存和显存消耗很大，所以页面中存在视频和动态图片时，很容易出现卡顿现象。
小技巧：通过控制多媒体文件的大小和尺寸来降低内存和显存的消耗
小技巧：不需要在当前可视区展示的图表，暂时将多媒体资源移除，从而减少资源资源开支
2、页面中组件很多、很碎
页面中组件很多、很碎，交互也很多，可能会造成脚本臃肿，当浏览器加载脚本时，会消耗大量CPU和内存资源，导致页面卡顿。
重点需排查指标
出现卡顿、闪屏和白屏时，如下指标都是需要重点监测的。
| 测试机器 | 采集时间 | 内存占用 | GPU内存（显存） | CPU利用率 | GPU利用率 | FPS | 是否打开硬件加速 | 当前启用显卡 |
|---|---|---|---|---|---|---|---|---|
| 测试机1 | 10:30 | xxx | xxx | xxx | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | xxx | xxx | xxx | |
| 11:30 | xxx | xxx | xxx | xxx | xxx | xxx | xxx | |
| 测试机2 | 10:30 | xxx | xxx | xxx | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | xxx | xxx | xxx | |
| 11:30 | xxx | xxx | xxx | xxx | xxx | xxx | xxx |
1、什么是FPS？怎么检查？
FPS是每秒帧数，即每秒钟展示的图像数。帧数越高，画面越流畅，反之亦然。大部分前端页面60帧及以上用户体验非常流畅，低于30帧则很容易出现卡顿。查询FPS很简单，打开F12调试工具，使用快捷键Ctrl+Shift+P，搜索FPS，选中第一项，在页面左上角会显示实时的FPS。
2、内存、显存、CPU利用率、GPU利用率怎么检查？
使用浏览器任务管理器、计算机任务管理器即可查询上述指标。
如下图所示为计算机任务管理器，可观察到CPU利用率、GPU利用率、GPU内存占用情况（GPU内存的使用情况可以准确反映显存的使用情况）。
如下图所示为浏览器任务管理器，可观察页面渲染进程实际的内存占用和GPU内存占用情况（显存占用情况）。
3、谷歌浏览器怎么手动开启硬件加速？
- 步骤1：打开谷歌浏览器并在地址栏输入chrome://settings
- 步骤2：在“系统”标题下找到“使用硬件加速模式（如果可用）”并开启它
- 步骤3：重新启动浏览器以使更改生效
4、显卡
当电脑同时拥有集成显卡和独立显卡时，默认情况下会启用集成显卡，因为集成显卡可以提供基本的图形处理能力，且更节能，若需要更高性能的图形处理能力，需手动切换到独立显卡。
当电脑出现卡顿、闪屏甚至白屏时，检查显卡，若当前启用集显，可切换为独显后，进行复测。
小贴士：怎么查看计算机当前启用的是集显还是独立显卡？
按下“Win+X”组合键打开“任务管理器”，点击“性能”选项卡，观察左侧的侧边栏，如果有多个显卡，则会看到名叫“GPU 0”和“GPU 1”（或者更多）的选项卡。点击每个GPU选项卡，观察右侧窗格中的GPU使用率，如果该显卡正在使用，则会看到GPU使用率波动。
如下图蓝色框选内容所示，集成显卡通常被标识为Intel，而独立显卡通常被标识为NVIDIA或AMD。
四、案例分析
收集工作中遇到的页面卡顿、闪屏和白屏场景，列出排查步骤或解决方案，以供参考。
案例1
| 项目 | 说明 |
|---|---|
| 案例描述 | 页面不包含任何3D场景。访问时，页面初始加载正常，随时间推移，页面依次出现卡顿、闪屏，最终整个页面白屏甚至崩溃 |
| 确定目标 | 能够准确定位异常原因，尽可能缩小异常排查范围 |
| 重要信息 | 初始加载正常、随时间推移出现问题，猜测存在内存泄漏或显存泄漏 |
| 提出假设 | 内存泄漏（建议同步观察内存、显存、CPU利用率、GPU利用率） |
使用工具：浏览器任务管理器、计算机任务管理器
如下图所示可观察到CPU利用率、GPU利用率、GPU内存占用情况（GPU内存的使用情况可以准确反映显存的使用情况）
如下图所示可观察页面渲染进程实际的内存占用和GPU内存占用情况（显存占用情况）。
设计实验、验证假设、定位目标
- 有条件的话，建议准备多台计算机，控制变量，同步测试，多轮测试，直至验证假设，并定位目标
- 假设实验人员为非开发人员，不具备深入代码层检测能力。
- 以复现问题为首要目标，复现后，再尽可能的缩小排查范围（不断排除干扰项）
假设两台同样硬件条件的计算机参与测试，设计信息记录表如下，信息采集间隔根据实际情况设定。
| 测试机器 | 采集时间 | 内存占用 | GPU内存（显存） | CPU利用率 | GPU利用率 | 其他指标 |
|---|---|---|---|---|---|---|
| 测试机1 | 10:30 | xxx | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | xxx | |
| 11:30 | xxx | xxx | xxx | xxx | xxx | |
| 测试机2 | 10:30 | xxx | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | xxx | |
| 11:30 | xxx | xxx | xxx | xxx | xxx |
第一轮测试：
描述：以复现问题为主要目标，测试机1和测试机2部署、运行并访问相同的前端服务，观察、记录信息。
结论：假设一轮测试已复现出卡顿、闪屏现象，且明显观察到内存占用升高，其他指标正常，则确定为内存泄漏
第二轮测试：
描述：以找出内存泄漏位置为主要目标，采用二分法。测试机1和测试机2分别部署一套前端服务，要求，测试机1删除页面一半内容，保留一半内容，例如保留左侧内容。测试机2同样删除一半，保留一半，例如保留右侧内容（两台测试机保留的内容不要重复）。观察、记录信息。
结论：二轮测试结束后，观察两台测试机数据，内存没有增长的则表示观测图表正常，将内存出现异常的测试机观测图表继续二分，进行第三轮测试
第三轮测试：重复第二轮步骤
协调开发资源
经上述实验，确定为内存泄漏，且可将异常范围圈定在几个组件或功能之间，此时可以申请研发介入，进一步的定位代码层面问题，并优化。
案例2
| 项目 | 说明 |
|---|---|
| 案例描述 | 页面通过iframe嵌入3D场景，同时存在视频和动态图片。访问页面时，有轻微卡顿、偶发闪屏，长时间运行下依旧如此 |
| 重要信息 | 很稳定出现异常，异常不受运行时间影响或影响很小忽略不计 |
| 以往项目 | 内存不足或显存不足，或二者都有的情况都遇到过 |
使用工具：浏览器任务管理器、计算机任务管理器（与案例1相同）
解决方法1：尽可能减小视频和动态图片的文件大小、实际分辨率
文件大小协调设计师处理。
保证展示尺寸不变，降低实际分辨率，可设置低分辨率，然后使用scale放大到原尺寸。
解决方法2：检查3D场景分辨率，保证展示效果的前提下，尽可能降低实际分辨率
降低3D场景的分辨率可以减少图像处理和渲染所需的计算量，从而有效降低内存和显存的消耗。保证展示尺寸不变，降低实际分辨率，可设置低分辨率，然后使用scale放大到原尺寸。
解决方案3：将视频文件和动态图片在页面中的层级调高，减小对其他组件的影响
解决方案4：将当前不展示的视频文件和动态图片移除，需要展示的时候动态添加
解决方案5：升级内存和显存
很稳定的出现异常，时间因素影响忽略不计，说明内存和显存不存在泄漏问题，观察内存和显存使用情况，若发现内存或显存不够，以上四种方案都不采用的情况下，可直接升级硬件配置。
案例3
| 项目 | 说明 |
|---|---|
| 案例描述 | 页面通过iframe嵌入3D场景，初始访问正常，随时间推移，页面出现卡顿闪屏，最终iframe窗口崩溃，但主页面正常 |
| 确定目标 | 能够准确定位异常原因，尽可能缩小异常排查范围 |
| 重要信息 | 1.随时间推移出现异常，且异常慢慢加重 2.iframe窗口崩溃 3.主页面正常 |
| 提出假设 | 3D场景存在内存泄漏或显存泄漏，主页面本身无异常 |
使用工具：浏览器任务管理器、计算机任务管理器（与案例1相同，不多赘述）
设计实验、验证假设、定位目标
- 有条件的话，建议准备多台计算机，将主页面和3D场景分开单独测试
- 假设实验人员为非开发人员，不具备深入代码层检测能力
- 以复现问题为首要目标
假设三台同样硬件条件的计算机参与测试，设计信息记录表如下，信息采集间隔根据实际情况设定。
| 测试机器 | 测试内容 | 采集时间 | 内存占用 | GPU内存（显存） | CPU利用率 | GPU利用率 |
|---|---|---|---|---|---|---|
| 测试机1 | 主页面+3D场景 | 10:30 | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | ||
| 11:30 | xxx | xxx | xxx | xxx | ||
| 测试机2 | 单独运行主页面 | 10:30 | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | ||
| 11:30 | xxx | xxx | xxx | xxx | ||
| 测试机3 | 单独运行3D场景 | 10:30 | xxx | xxx | xxx | xxx |
| 11:00 | xxx | xxx | xxx | xxx | ||
| 11:30 | xxx | xxx | xxx | xxx |
测试机1：
目标：以复现问题为主要目标，观察、记录信息。
结论：一段时间后，出现卡顿，继续一段时间，出现闪屏，继续一段时间，iframe窗口崩溃，主页面正常，则判断确实存在资源泄漏。根据记录表，观察内存和显存的占用情况，确定是内存泄漏，还是显存泄漏，还是二者皆有。
测试机2：
目标：移除3D场景，单独测试主页面（根据出问题的现象，可初步判断主页面本身没有问题，但仍需测试，用数据再验证一遍）
结论：持续运行一段时间，主页面无异常，采样数据平稳，无较大波动，则说明主页面确实无异常
测试机3：
目标：移除主页面，单独测试3D场景
结论：一段时间后，出现卡顿，继续一段时间，出现闪屏，继续一段时间，3D场景白屏或崩溃。观察记录表，你会发现，测试机3出现问题的时间要比测试机1晚，但仍会出现，这是因为单独访问3D场景，没有页面与之竞争资源，所以坚持的时间可能会更久。
协调开发资源
结合测试机123的情况，可得出结论，确定3D场景存在内存泄漏或显存泄漏，此时可以申请研发介入，进一步的定位代码层面问题，并优化。
小贴士：页面中通过iframe嵌入存在资源泄漏的3D场景，出现异常时，为什么会出现仅iframe窗口白屏或崩溃，而主页面正常的现象？
通过iframe嵌入第三方页面时，主页面和子页面是两个独立的页面，各自拥有独立的GPU进程和渲染进程，二者之间资源隔离，使用的内存和显存资源并非共享，它们之间的数据交互也是通过消息传递实现的，而非共享内存空间。
这种设定是出于安全考虑，因为iframe嵌入的第三方页面可能来自不可信的源，因此为了保护主页面安全，不允许它们直接共享内存和显存。主页面和子页面会竞争计算机的内存和显存资源,所以才会出现实验中测试机1可能会比测试机3更快出现问题的情况。
案例4
| 项目 | 说明 |
|---|---|
| 案例描述 | 页面通过iframe嵌入3D场景，初始访问正常，随时间推移，页面出现卡顿闪屏，慢慢的，最终整个浏览器页面崩溃 |
| 重要信息 | 1.随时间推移出现异常，且异常慢慢加重 2.整个浏览器页面崩溃 |
| 提出假设 | 主页面和3D场景均可能存在内存泄漏或显存泄漏 |
案例4与案例3相似，唯一区别是案例4并非是仅iframe窗口崩溃，而是整个页面崩溃。
此时，主页面和3D场景均可能存在资源泄漏情况。主页面崩溃不能直接断定是主页面单方面出现资源泄漏，因为子页面资源泄漏严重或脚本报错的时候，也是有可能造成主页面崩溃的。所以，主页面和3D场景需要分别单独测试。
案例5
| 项目 | 说明 |
|---|---|
| 案例描述 | 主页面通过iframe嵌入3D场景，在分辨率3840*2160的屏上投放，3D场景直接无法正常加载 |
原因解释
基于WebGL的3D场景对分辨率有要求，水平最高不要超过3840，垂直不要超过1080，超出范围后，资源消耗加大，不能保证正常显示。分辨率越小，资源消耗越低。所以在保证显示效果的前提下，应尽量降低分辨率。
小贴士：基于WebGL3D场景为什么不支持高分辨率下展示？
WebGL需要大量的内存和显存来存储和渲染高分辨率的图像，如果内存和显存不足，很容易发生溢出，导致页面崩溃。
解决方案1
pixelRatio属性默认值为1，可以直接通过减小该属性值来降低3D场景的分辨率。
pixelRatio=0.25 // 表示将分辨率缩小为原来的四分之一
pixelRatio=2 // 表示屏幕的分辨率是原来的两倍小贴士：pixelRatio是什么意思？
pixelRatio是设备像素比（物理像素/逻辑像素），表示屏幕上一个逻辑像素占用多少个物理像素，默认值为1。pixelRatio可以用来衡量屏幕的分辨率，以便确定图像的清晰度和显示效果。
同一个页面，pixelRatio数值越大，分辨率越高，渲染效果越清晰，内存和显存消耗越大。
同一个显示屏，同一个前端页面，我们通过代码降低分辨率，指的是降低物理分辨率，即减少屏幕上的物理像素数量，从而使图像变得模糊。
解决方案2
3D场景不做变动，主页面嵌入3D场景时，在保证展示效果的前提下，通过降低3D场景实际分辨率的方式，从而降低内存和显存的消耗（设置小的分辨率，然后通过scale放大）。
五、注意事项
方法论
- 遇到卡顿、闪屏、白屏问题时，不要上来就想着怎么解决，请首先保证能把问题稳定复现出来，用数据说话
- 要学会设计实验，控制变量，不断缩小排查范围
谷歌浏览器
- 确保浏览器开启硬件加速
电脑显卡
- 电脑同时拥有集显和独显，默认启用集显，当页面出现卡顿、闪屏甚至白屏时，检查显卡使用情况，确保独显开启