为什么我的UI界面会突然卡顿，失去响应

有操作都应是“非阻塞”的，以确保能随时响应用户的输入。导致主线程阻塞的常见“元凶”主要涵盖五个方面：主线程被“长时间”的同步计算所“阻塞”、单次渲染的界面节点过多或过于复杂、内存中存在“未释放”的巨大对象或“内存泄漏”、响应了“高频率”触发的事件而未做“节流”或“防抖”、以及后台的“网络请求”或“数据处理”逻辑设计不当。

其中，主线程被长时间的同步计算所阻塞，是问题的根源。绝大多数图形用户界面系统，都运行在一个“单线程”模型上，这个唯一的线程，既要负责绘制界面，又要负责响应用户的点击、滚动等操作。如果开发者，在这个线程上，启动了一项耗时巨大的计算（例如，处理一个巨大的数据数组），那么，这个线程，就会被完全地、毫无保留地，被这个计算任务所“霸占”，直到它完成为止。在此期间，所有新的用户操作，都会被“无视”，界面因此“冻结”，从而给用户带来“卡死”的直观感受。

一、问题的“本质”、单线程的“宿命”

要深刻理解“界面卡顿”的根源，我们必须首先，理解现代图形用户界面，其内在的、底层的“工作模型”。这个模型，可以被概括为“单线程 + 事件循环”。

1. 图形用户界面的“单线程”模型

在几乎所有我们日常接触的图形用户界面框架中——无论是网页浏览器、安卓、苹果的操作系统，还是各种桌面应用框架——所有与“界面”相关的操作，包括绘制界面元素、响应用户的鼠标点击和键盘输入、执行动画等，都被严格地，限定在了一个唯一的、专用的“主线程”上执行。

之所以采用这种“单线程”的设计，主要是为了简化状态管理，避免复杂的并发问题。如果允许多个线程，在同一时刻，随意地，去修改同一个界面元素（例如，线程A想把它变红，线程B想把它变绿），那么，整个界面的状态，将很快地，陷入一种不可预测的、混乱的“竞态条件”之中。

2. 事件循环的工作原理

这个唯一的“主线程”，其内部，运转着一个永不停止的“事件循环”。我们可以将其，理解为一个极其勤勉的“调度中心”，它在周而复始地，执行着一个简单的循环：

检查“任务队列”：去一个名为“任务队列”的“信箱”里，看看是否有新的“任务”到达。这些“任务”，可以是“用户刚刚点击了一下按钮”、“一个网络数据包已经下载完成”、“一个定时器的时间到了”等等。

取出一个任务并执行：如果队列中有任务，就取出最老的一个，并完整地、从头到尾地，执行与这个任务相关的所有代码。

进行界面“渲染”：在该任务执行完毕后，检查，是否有任何代码，请求了对界面的修改。如果有，就进行一次统一的、重绘屏幕的操作。

返回第一步，继续检查任务队列。

3. “阻塞”的科学定义

界面的“卡顿”或“失去响应”，在技术层面上，其唯一的、直接的原因，就是上述“事件循环”的第二步——“取出一个任务并执行”——其耗费的时间，过长了。

根据谷歌等行业领导者提出的RAIL性能模型，如果一个任务的执行时间，超过了100毫秒，人类用户，就能明确地，感受到“延迟”。如果，这个时间，超过了500毫秒甚至1秒，那么，用户，就会主观地，判定这个程序已经“卡死”了。因为，在这个耗时的任务，执行完毕之前，整个“事件循环”，都被“阻塞”在了第二步。它既没有机会，去处理任何新的、后续的用户输入（如你的第二次点击），也没有机会，去执行任何屏幕的重绘。

二、元凶一、主线程的“同步”计算过载

这是导致主线程阻塞的、最直接、也最常见的“罪魁祸首”。

1. 场景一：复杂的数据处理

问题描述：开发者，从一个接口，获取到了一个包含了数万条记录的、巨大的数据数组。然后，在一个响应用户点击的回调函数中，直接地，对这个数组，进行了一次复杂的、多重嵌套的“循环、过滤、排序、转换”的同步操作。

后果：这个数据处理的循环，可能会持续执行数百毫秒甚至数秒。在此期间，主线程被完全“冻结”，界面对用户的任何后续操作，都“毫无反应”。

2. 场景二：耗时的算法

问题描述：在主线程上，直接地，执行一些计算密集型的算法，例如，复杂的路径规划、图像的滤镜处理、数据的加密或解密等。

【解决方案】：将所有“耗时计算”，都从“主线程”，转移到“后台线程”。

Web Worker：在网页开发中，Web Worker技术，允许我们，创建一个或多个，完全独立于主线程的“后台线程”。我们可以将那些计算密集型的、与界面无直接关系的数据处理任务，都“派发”给这些后台线程去完成。后台线程，在计算完毕后，再通过一个异步的消息，将最终的“结果”，安全地，返回给主线程。主线程，则只负责，接收这个“结果”，并用它来更新界面。

异步化拆分：对于一些无法，或不方便，被完全转移到后台线程的任务，我们可以采用一种“化整为零”的策略。即将一个“大的”同步任务，人为地，拆分为多个“小的”任务块，并利用setTimeout(..., 0)这样的技巧，将每一个小任务块，都作为一个新的、独立的“宏任务”，重新调度到“任务队列”的末尾。这使得，在每两个小任务块的执行间隙，主线程，都有机会“喘息”，去处理其他的用户输入和界面渲染。

三、元凶二、渲染的“性能”瓶颈

有时，卡顿，并非源于“计算”，而是源于“绘制”本身。

一次性渲染“过多”的元素：当一个需求，要求，在一个页面上，同时，渲染一个包含数千行、数十列的巨大表格时，浏览器，需要，在短时间内，创建数万个独立的界面元素节点，并为它们，逐一地，计算样式和布局。这个过程，本身，就可能耗时数秒，导致界面“白屏”或“卡顿”。

频繁且无效的“重绘”与“回流”：在网页中，界面的渲染，分为“回流”（计算元素的位置和几何形状）和“重绘**（填充元素的像素颜色和样式）两个阶段。“回流”的成本，远高于“重绘”。如果我们的代码，在一次操作中，反复地，去修改那些会“影响布局”的属性（例如，一个元素的宽度、高度、或边距），那么，就会，触发多次的、昂贵的、全局性的“回流”，导致严重的性能问题。

【解决方案】：

虚拟化/窗口化：对于需要展示海量数据的长列表或表格，我们不应，一次性地，将所有数据，都渲染出来。而应采用“虚拟化”技术，即，只渲染那些，当前，在用户的“可视窗口”内，所能看到的、少数的几十个元素。当用户滚动时，再动态地，计算和渲染新的可见元素。

请求动画帧：对于需要，实现流畅动画的场景，应使用requestAnimationFrame，来将我们的动画逻辑，与浏览器的“刷新频率”，进行同步，以获得最佳的性能。

优化样式操作：尽量避免，在JavaScript中，频繁地，读写会触发“回流”的样式属性。

四、元凶三、高频事件的“处理风暴”

“疯狂”的事件触发：在界面中，存在一些“高频”事件，例如，scroll（滚动）、mousemove（鼠标移动）、resize（窗口大小调整）。这些事件，可以在短短一秒钟内，被触发数十次甚至上百次。

问题的根源：如果，我们为这些“高频”事件，绑定了一个处理逻辑相对复杂的“事件回调函数”，那么，这个回调函数，就会被“疯狂地”，在一秒钟内，执行数十上百次。这会迅速地，将“任务队列”，填满，并耗尽中央处理器的计算能力，导致界面，在滚动或拖拽时，出现明显的“掉帧”和“卡顿”。

【解决方案】：为高频事件的回调函数，配备“减速器”。

函数防抖：其策略是，“稍等一下，等你不动了，我再处理”。它会强制一个函数，在某个连续的操作结束后（例如，用户停止了输入），只被执行一次。这非常适用于，像“搜索框的输入联想”这样的场景。

函数节流：其策略是，“别太快，按我的节奏来”。它会确保一个函数，在一定的时间间隔内（例如，每200毫-秒），最多只被执行一次。这非常适用于，像“页面滚动”或“窗口缩放”的事件处理。

五、元凶四、内存的“隐形”杀手

最后，一个常常被忽略的、导致界面“间歇性”或“越来越”卡的“隐形杀手”，是不健康的内存使用。

内存泄漏：如我们在前文《为什么有些对象在没有引用后，内存仍无法被回收》中所述，如果程序中，存在“内存泄漏”，那么，随着用户使用时长的增加，应用所占用的内存，就会只增不减。

与卡顿的关系：当内存占用，达到一个较高的水平时，垃圾回收器，就会被更频繁地触发，并且，每一次执行“垃圾回收”所需的时间，也会更长。这些垃圾回收的暂停，都是在“主线程”上，进行的“阻塞性”操作。这，正是导致许多应用，“用久了，就越来越卡”的根本原因。

【解决方案】：

利用内存分析器：使用像Chrome浏览器开发者工具中的“性能”和“内存”面板，来主动地，分析应用的内存使用情况，定位并修复内存泄漏。

养成良好的资源管理习惯：例如，在组件被销毁时，及时地，注销所有相关的事件监听器和定时器。

六、在流程与规范中“防范”

性能作为“一等公民”：在进行需求分析和评审时，就应将“性能”，作为一个重要的非功能性需求，来进行明确的定义和讨论。

代码审查：在进行代码审查时，应将“是否存在可能阻塞主线程的同步计算”、“高频事件的处理是否已做节流/防抖”等，作为重要的检查项。

性能预算：团队，可以共同制定一个“性能预算”，例如，“我们的任何一个用户交互，其主线程的响应时间，都不得超过100毫秒”。这个“预算”，可以通过自动化的性能测试工具，在持续集成的流程中，进行监控。

在项目计划中体现：对于任何一个新功能的开发，都应在项目计划中，明确地，包含一个用于“性能分析与测试”的任务，以确保，它，不会在紧张的开发节奏中，被遗忘。

常见问答 (FAQ)

Q1: 什么是“主线程”？为什么它这么容易被阻塞？

A1: “主线程”，在图形用户界面程序中，是那个唯一的、负责处理所有用户交互（如点击、滚动）和执行所有界面更新（如重绘）的线程。正因为它是“唯一”的，所以，任何一个耗时的任务，只要在这个线程上执行，都会“独占”它，导致它，无法再去处理任何其他的事情，从而，引发界面的“冻结”。

Q2: “函数防抖”和“函数节流”有什么区别？

A2: 两者都是用于，降低高频事件回调执行频率的技术，但策略不同。“防抖”，是在一个连续动作的“结束”时，只执行一次。而“节流”，则是在一个连续动作的“过程”中，以一个固定的频率（例如，每200毫秒一次），反复地执行。

Q3: 我应该如何使用浏览器开发者工具来诊断界面卡顿问题？

A3: 使用“性能”面板。点击“录制”按钮，然后，在你的界面上，复现那个卡顿的操作。录制结束后，面板，会为你生成一份详细的“火焰图”。在这张图中，那些“顶部平坦”的、耗时很长的、带有“红色三角”标记的“长任务”，就是导致你的界面卡顿的“罪魁祸首”。

Q4: 后端程序也会有类似“界面卡顿”的问题吗？

A4: 后端程序，虽然没有“界面”，但同样存在“线程阻塞”的问题。例如，在一个多线程的Web服务器中，如果所有的“工作线程”，都因为一个慢查询或一个死锁，而被“阻塞”住了，那么，这个服务器，就将无法再响应任何新的用户请求，从用户的角度看，网站，就“卡死”了。其底层的“任务队列被耗尽”的原理，是相通的。