Unity GPU物理模拟：Verlet积分与Compute Shader实战解析-平芜编程栈

1. 项目概述：当物理模拟遇上GPU计算

如果你在Unity里做过布料、绳索或者软体这类需要柔体物理的效果，大概率被Unity自带的Cloth组件或者一堆复杂的关节（Joint）和刚体（Rigidbody）组合折磨过。性能开销大、参数调起来玄学、效果还常常不理想。几年前我在做一个需要大量飘带和旗帜的项目时，就深陷这个泥潭，直到我发现了Verlet积分这个“物理模拟界的瑞士军刀”，并且把它和GPU计算结合了起来。

今天要聊的这个“Unity Verlet Simulator”开源项目，就是一个把这件事做到极致的例子。它不是一个玩具Demo，而是一个完全基于GPU计算的、高性能的Verlet积分模拟器。简单来说，它用一套非常巧妙的数学方法（Verlet积分）来模拟物体的运动，并且把所有的计算都丢给显卡（GPU）去并行处理，CPU几乎零负担。这意味着你可以在手机上跑成千上万个模拟节点，做出以前想都不敢想的复杂动态效果，比如海草群、长发飘飘、或是整个帐篷布料的随风摆动。

这个项目的核心价值在于**“解放创意，无视性能瓶颈”**。它特别适合谁呢？首先是技术美术（TA）和图形程序员，你们可以把它作为底层工具，快速构建各种自定义的物理效果。其次是独立开发者和中小团队，没有资源去从头研发一套物理系统，这个开源项目就是现成的、高性能的解决方案。最后，哪怕你只是个对酷炫效果感兴趣的Unity爱好者，通过这个教程，你也能理解现代游戏里那些流畅物理背后的核心原理，并亲手实现出来。

2. Verlet积分原理：为什么是它，而不是别的？

在深入代码之前，我们必须先搞懂Verlet积分到底是什么，以及为什么它在游戏和实时模拟领域如此受青睐。这能帮助我们在后面理解项目的每一个设计决策。

2.1 从牛顿运动定律到数值积分

我们都知道牛顿第二定律：F = ma。在计算机里，我们无法求解连续的微分方程，只能把时间切成一小段一小段（时间步长Δt），去近似计算物体下一刻的位置。最直观的方法是欧拉方法：用当前速度更新位置，用当前加速度更新速度。

位置新 = 位置旧 + 速度 * Δt 速度新 = 速度旧 + 加速度 * Δt

欧拉法简单，但有个致命问题：它能量不守恒。在长时间模拟中，误差会累积，系统可能会获得或损失能量，导致模拟“爆炸”（物体飞走）或“衰减”（物体停下）。这对于需要稳定模拟的绳索、布料来说是灾难。

2.2 Verlet积分的巧妙之处

Verlet积分换了一种思路。它不直接存储和更新速度，而是通过当前帧和上一帧的位置来隐式地表达速度。它的核心公式是：

位置新 = 2 * 位置当前 - 位置旧 + 加速度 * Δt²

这个公式怎么来的？我们可以从泰勒展开推导，但更直观的理解是：(位置当前 - 位置旧) / Δt近似等于上一段时间的平均速度。那么，预测下一帧的位置，就等于从当前位置，加上这个平均速度再走一步，再加上外力引起的位移变化。

它的巨大优势有三点：

时间可逆性：公式是对称的，如果把“新”和“旧”对调，公式形式不变。这带来了更好的数值稳定性，能量漂移比欧拉法小得多，非常适合长期模拟。
无需显式速度：省去了存储和更新速度变量的开销。对于有成百上千个点的粒子系统，内存和计算都有节省。
约束求解友好：这是最关键的一点。在布料、绳索模拟中，我们有很多“约束”，比如“两个点之间的距离必须保持固定”。Verlet积分在更新位置后，可以非常方便地通过迭代调整点的位置来满足这些约束（例如，把两个拉远或压近的点，沿着它们连线的方向拉回或推开到正确距离）。这个过程就是著名的“位置动力学”（Position-Based Dynamics, PBD）的思想雏形。

注意：Verlet积分对时间步长Δt的稳定性有要求。如果Δt太大，或者加速度突变剧烈，依然会不稳定。项目中通过多次迭代约束求解（iterations参数）来增强稳定性，这就是为什么代码里有一个for循环来反复调用Solve。

2.3 GPU并行化：为何是必然选择？

传统的Verlet模拟在CPU上跑，当粒子数（节点）超过几千，每帧又要迭代求解约束8-10次，CPU很快就成为瓶颈。而GPU生来就是为大规模并行计算设计的。

在这个项目中，每一个模拟节点（GPUNode）和每一条约束边（GPUEdge）的计算都是完全独立的。例如，更新10,000个节点的位置，在CPU上是一个有10,000次的for循环，在GPU上则是启动一个包含10,000个线程的核函数，所有线程同时计算。约束求解也是如此，每条边的长度约束可以并行处理。

因此，将Verlet积分映射到GPU的Compute Shader上，是一个“天作之合”。GPUVerletSimulator这个类，本质上是一个数据管理器和调度器。它在CPU端准备数据（节点和边的数组），然后将这些数据封装成Compute Buffer（GPU能直接访问的内存块），最后调度对应的Compute Shader核函数（Kernel）在GPU上执行真正的模拟计算。

3. 项目核心架构与代码深度解析

理解了原理，我们再来拆解mattatz/unity-verlet-simulator这个项目的具体实现。它的代码结构非常清晰，是学习GPU计算在Unity中应用的优秀范本。

3.1 数据结构设计：GPU与CPU的桥梁

项目定义了两个核心结构体，分别对应节点和边。注意，它们使用了[System.Runtime.InteropServices.StructLayout]特性，确保内存布局是连续的，这对于高效传输到GPU至关重要。

GPUNode（节点）：

struct GPUNode { public Vector3 position; // 当前帧位置 public Vector3 prev; // 上一帧位置 public float decay; // 位置衰减系数（用于模拟阻尼，如空气阻力） // 通常还会有一个 padding 字段来满足GPU内存对齐要求，但示例中省略了 }

position和prev：是Verlet积分的核心，存储了当前和上一时刻的位置。
decay：一个介于0到1之间的系数。在每步积分后，position和prev的差值（即隐含的速度）会乘以这个系数。如果decay=0.98，意味着有2%的速度损失，用来模拟阻尼效果，让运动慢慢停下来。这是控制模拟“手感”的关键参数之一。

GPUEdge（边/约束）：

struct GPUEdge { public int a; // 节点A在数组中的索引 public int b; // 节点B在数组中的索引 public float length; // 约束的目标长度 }

a,b：不是直接存储位置，而是存储索引。这是因为在GPU计算中，我们通过索引去查找GPUNode缓冲区中对应位置的数据。这比直接存储Vector3更节省内存，且符合GPU并行访问模式。
length：这条边静止时的自然长度。约束求解的目标就是让节点a和b的实际距离尽可能接近这个length。

3.2 GPUVerletSimulator类：模拟器的中枢

这个类封装了模拟的全部逻辑。我们来看它的关键成员和方法：

构造函数与初始化：

public GPUVerletSimulator(GPUNode[] nodes, GPUEdge[] edges) { // 创建Compute Buffer，用于在GPU存储节点和边数据 _nodeBuffer = new ComputeBuffer(nodes.Length, sizeof(float) * 7); // Vector3*2 + float _edgeBuffer = new ComputeBuffer(edges.Length, sizeof(float) * 3); // int*2 + float // 将CPU数组数据上传至GPU Buffer _nodeBuffer.SetData(nodes); _edgeBuffer.SetData(edges); // 保存节点和边的数量，后续计算需要 _nodeCount = nodes.Length; _edgeCount = edges.Length; }

实操心得：ComputeBuffer构造函数的第二个参数是每个元素的数据大小（字节数）。这里必须精确计算。Vector3在Unity中是3个float，占12字节。所以一个GPUNode（两个Vector3加一个float）大约是12*2 + 4 = 28字节。示例中写的sizeof(float)*7（28字节）是正确的。计算错误会导致GPU读取数据错乱，模拟完全失效或崩溃。

Step方法：Verlet积分步进这个方法对应Compute Shader中的VerletStep核函数。

public void Step(ComputeShader compute) { int kernel = compute.FindKernel("VerletStep"); compute.SetBuffer(kernel, "_Nodes", _nodeBuffer); compute.SetFloat("_DeltaTime", Time.deltaTime); compute.SetFloat("_Damping", 0.99f); // 全局阻尼，可与节点的decay结合使用 // 调度GPU计算：线程组数量 = ceil(节点数 / 线程组大小) compute.Dispatch(kernel, Mathf.CeilToInt(_nodeCount / 64f), 1, 1); }

核函数（HLSL）伪逻辑：

// 每个线程处理一个节点 uint id = dispatchThreadID.x; if(id >= _NodeCount) return; GPUNode node = _Nodes[id]; // Verlet积分核心计算 float3 velocity = node.position - node.prev; // 隐含速度 node.prev = node.position; // 为下一帧做准备 // 应用加速度（此处示例为重力） float3 acceleration = float3(0, -9.8, 0); node.position += velocity * _Damping + acceleration * _DeltaTime * _DeltaTime; // 应用节点自身的衰减系数 velocity = node.position - node.prev; node.prev = node.position - velocity * node.decay; _Nodes[id] = node;

这个过程完全并行，效率极高。

Solve方法：约束迭代求解这是模拟真实感的关键。Solve方法会调用Compute Shader中的SolveEdgeConstraints核函数，并且通常要执行多次（iterations）。

public void Solve(ComputeShader compute) { int kernel = compute.FindKernel("SolveEdgeConstraints"); compute.SetBuffer(kernel, "_Nodes", _nodeBuffer); compute.SetBuffer(kernel, "_Edges", _edgeBuffer); compute.SetInt("_EdgeCount", _edgeCount); // 调度计算：每个线程处理一条边 compute.Dispatch(kernel, Mathf.CeilToInt(_edgeCount / 64f), 1, 1); }

约束求解核函数伪逻辑：

uint id = dispatchThreadID.x; if(id >= _EdgeCount) return; GPUEdge edge = _Edges[id]; GPUNode nodeA = _Nodes[edge.a]; GPUNode nodeB = _Nodes[edge.b]; float3 delta = nodeB.position - nodeA.position; float currentLength = length(delta); if(currentLength > 0) { // 计算偏离目标长度的比例 float diff = (currentLength - edge.length) / currentLength; // 根据两个节点的“权重”（如质量倒数）分配调整量 // 简单情况下，各调整50% float halfDiff = diff * 0.5f; nodeA.position += delta * halfDiff; nodeB.position -= delta * halfDiff; _Nodes[edge.a] = nodeA; _Nodes[edge.b] = nodeB; }

重要提示：约束求解是迭代过程。一次Solve只能让所有边向目标长度靠近一点。通过多次迭代（比如8次），才能让整个网络在每帧内都趋于稳定状态，模拟出布料的“紧绷感”。迭代次数越多，越硬朗，但性能开销也越大。

3.3 在MonoBehaviour中的使用模式

项目README中的示例代码展示了标准的用法：

初始化（Start）：构建节点和边的网络结构（如一条链、一个网格），创建GPUVerletSimulator实例。
每帧更新（Update）：
- 调用一次simulator.Step(compute)，进行Verlet积分，更新所有节点位置。
- 在一个循环中（例如8次）调用simulator.Solve(compute)，迭代求解约束，使结构稳定。
- （可选）从_nodeBuffer中把数据读回CPU（使用ComputeBuffer.GetData），用于渲染（如更新LineRenderer或Mesh的顶点）。

这种“GPU计算，CPU调度，结果回传渲染”的模式，是现代Unity高性能图形编程的典型范式。

4. 从零构建一个Verlet绳索：完整实操流程

理论说了这么多，我们动手做一个最简单的例子：一条受重力摆动的Verlet绳索。这能帮你把整个流程串起来。

4.1 第一步：设置项目与导入核心文件

创建一个新的Unity项目（建议使用2018 LTS或更新版本，确保Compute Shader支持完善）。
从GitHub仓库（mattatz/unity-verlet-simulator）下载项目。你只需要复制两个关键文件到你的项目：
- Assets/GPUVerletSimulator.cs：C#模拟器核心类。
- Assets/GPUVerletSimulator.compute：Compute Shader文件，包含了VerletStep和SolveEdgeConstraints等核函数。
在场景中创建一个空物体，命名为“VerletRope”。

4.2 第二步：编写控制器脚本

在“VerletRope”物体上创建一个新的C#脚本，命名为VerletRopeController。我们将逐步填充内容。

4.2.1 定义变量与初始化

using UnityEngine; public class VerletRopeController : MonoBehaviour { [SerializeField] private ComputeShader _verletComputeShader; // 拖入GPUVerletSimulator.compute [SerializeField] private int _nodeCount = 10; // 绳索的节点数 [SerializeField] private float _segmentLength = 0.2f; // 每段绳索的长度 [SerializeField] private LineRenderer _lineRenderer; // 用于渲染绳索的LineRenderer private GPUVerletSimulator _simulator; private GPUNode[] _nodes; private GPUEdge[] _edges; void Start() { // 1. 初始化LineRenderer if (_lineRenderer == null) _lineRenderer = GetComponent<LineRenderer>(); _lineRenderer.positionCount = _nodeCount; // 2. 创建节点数据 _nodes = new GPUNode[_nodeCount]; for (int i = 0; i < _nodeCount; i++) { // 从当前物体位置开始，垂直向下排列节点 Vector3 initialPos = transform.position + Vector3.down * i * _segmentLength; _nodes[i] = new GPUNode { position = initialPos, prev = initialPos, // 初始时上一帧位置等于当前位置，表示初始静止 decay = 0.99f // 轻微的阻尼，让摆动能慢慢停下来 }; } // 3. 创建约束边数据 _edges = new GPUEdge[_nodeCount - 1]; for (int i = 0; i < _edges.Length; i++) { _edges[i] = new GPUEdge { a = i, // 连接第i个节点 b = i + 1, // 和第i+1个节点 length = _segmentLength // 约束长度为预设的段长 }; } // 4. 固定第一个节点（绳索的悬挂点） _nodes[0].decay = 0f; // 将衰减设为0，意味着速度永远被归零，节点就被“钉住”了 // 5. 创建模拟器实例 _simulator = new GPUVerletSimulator(_nodes, _edges); } }

关键点解析：固定节点是通过设置其decay = 0实现的。在Step的核函数中，decay会作用于隐含速度。当decay=0时，node.prev会被设置为与node.position相等，使得隐含速度为零，节点就无法移动。这是一种非常巧妙的实现方式。

4.2.2 每帧模拟与渲染

void Update() { if (_simulator == null || _verletComputeShader == null) return; // 1. 执行Verlet积分步进（应用重力等外力） _simulator.Step(_verletComputeShader); // 2. 迭代求解约束，让绳索保持长度 const int solverIterations = 8; for (int i = 0; i < solverIterations; i++) { _simulator.Solve(_verletComputeShader); } // 3. （可选）将GPU数据读回CPU，用于渲染 // 注意：GetData是CPU-GPU同步操作，比较耗时。对于简单演示可以，生产环境需优化。 GPUNode[] currentNodes = new GPUNode[_nodeCount]; _simulator.GetNodeData(currentNodes); // 需要在GPUVerletSimulator类中添加此方法 // 4. 更新LineRenderer的顶点位置 Vector3[] linePositions = new Vector3[_nodeCount]; for (int i = 0; i < _nodeCount; i++) { linePositions[i] = currentNodes[i].position; } _lineRenderer.SetPositions(linePositions); }

为了能从模拟器获取数据，我们需要在GPUVerletSimulator类中添加一个公共方法：

public void GetNodeData(GPUNode[] dataOut) { if (dataOut.Length != _nodeCount) { Debug.LogError("Output array size mismatch!"); return; } _nodeBuffer.GetData(dataOut); }

4.2.3 添加交互：鼠标拖动让绳索可交互能极大增加演示效果。我们添加用鼠标拖动最后一个节点的功能。

void Update() { // ... 原有的模拟和渲染代码 ... // 鼠标交互 HandleMouseInteraction(); } void HandleMouseInteraction() { if (Input.GetMouseButton(0)) { Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition); RaycastHit hit; if (Physics.Raycast(ray, out hit)) { // 简单起见，我们假设点击到的是最后一个节点附近 // 更精确的做法是遍历所有节点，找到距离鼠标世界坐标最近的节点 int nodeIndexToDrag = _nodeCount - 1; // 拖动最后一个节点 // 将目标位置设置为鼠标在某个平面（例如Y=0）上的交点 Vector3 targetPos = hit.point; targetPos.y = hit.point.y; // 保持原有高度，或根据你的平面调整 // 直接设置该节点的位置和上一帧位置，使其“瞬移”到目标点 // 注意：这会破坏物理连续性，但作为交互是可以接受的 GPUNode[] nodes = new GPUNode[_nodeCount]; _simulator.GetNodeData(nodes); // 先获取当前数据 nodes[nodeIndexToDrag].position = targetPos; nodes[nodeIndexToDrag].prev = targetPos; // 将prev也设为相同值，使其当前速度为0 _simulator.SetNodeData(nodes); // 将修改后的数据设置回去 } } }

同样，需要在GPUVerletSimulator中添加SetNodeData方法。

public void SetNodeData(GPUNode[] data) { if (data.Length != _nodeCount) { Debug.LogError("Input array size mismatch!"); return; } _nodeBuffer.SetData(data); }

4.3 第三步：场景配置与运行

将GPUVerletSimulator.compute文件拖拽到VerletRopeController脚本的_verletComputeShader字段上。
为“VerletRope”物体添加一个LineRenderer组件，并拖拽到脚本的对应字段。在LineRenderer中设置好材质和宽度。
运行游戏。你应该能看到一条垂直悬挂的绳索。由于第一个节点被固定，其余节点受重力下落，但又被长度约束拉住，从而形成一个自然的悬链线摆动。
点击并拖动鼠标，可以拉扯绳索的末端，它会做出真实的物理反馈。

至此，一个最基本的、基于GPU的Verlet绳索模拟器就完成了。你可以通过调整_nodeCount、_segmentLength、solverIterations以及节点decay参数，来观察绳索的物理特性变化。

5. 性能优化与高级应用技巧

当你能跑通基础Demo后，下一步就是把它用到实际项目中，并榨干其性能。这里有几个关键的高级技巧和避坑指南。

5.1 性能瓶颈分析与优化策略

避免每帧GetData/SetData：上面示例中，我们每帧都调用GetNodeData来更新LineRenderer，这是一个严重的性能陷阱。ComputeBuffer.GetData会强制GPU-CPU同步，导致GPU流水线停顿，极大降低帧率。优化方案：使用Graphics.DrawProcedural或Compute Shader直接输出到渲染目标。
- 方案A（适用于Mesh）：将节点位置Buffer直接传递给一个Surface Shader或Unlit Shader，在顶点着色器中读取Buffer数据来变换顶点。这需要你对Shader编程有一定了解。
- 方案B（适用于LineRenderer）：如果非要用LineRenderer，可以降低数据回读频率。例如，只在每2-3帧读取一次数据，或者只在需要时才读取。对于视觉变化不快的模拟，人眼几乎察觉不到区别。
合理设置线程组大小：在ComputeShader.Dispatch时，我们用了Mathf.CeilToInt(_nodeCount / 64f)。这里的64是假设核函数中定义的线程组大小（[numthreads(64,1,1)]）。这个数字不是固定的，需要根据GPU架构调整。NVIDIA GPU通常喜欢32的倍数（32， 64， 128），而AMD GPU可能对64或256更友好。在Unity中，可以通过SystemInfo.maxComputeWorkGroupSize来查询设备支持的最大值，但通常64是一个安全且高效的默认值。
分批与LOD（细节层次）：如果你有成千上万个独立物体（比如一片草海），每个都是一个小的Verlet系统。不要为每个物体创建一个GPUVerletSimulator实例和Dispatch调用。应该将它们合并。
- 数据合并：将所有物体的所有节点和边数据打包到几个大的ComputeBuffer中。
- 计算合并：在Compute Shader中，通过额外的Buffer（如起始索引Buffer）来区分不同物体。这样，一次Dispatch就能模拟所有物体，极大减少CPU开销和GPU的API调用开销。
- LOD：对于远处的物体，可以减少其节点数量（_nodeCount）和约束求解迭代次数（solverIterations），用更低的计算成本换取近似的视觉效果。

5.2 扩展模拟类型：从绳索到布料与软体

这个项目的框架不限于绳索。通过改变节点和边的连接拓扑结构，你可以模拟各种物体。

1. 布料模拟：

节点拓扑：创建一个N x M的二维网格。每个网格点是一个节点。
约束边：
- 结构约束：连接每个节点与其右方、下方的邻居，形成网格的主结构。
- 剪切约束：连接每个节点与其右下方、右下方的邻居（对角线），防止布料在剪切力下过度变形。
- 弯曲约束：连接每个节点与其隔一个的右方、下方邻居（例如(i,j)连接(i+2, j)），用来抵抗弯曲，让布料有一定硬度。
固定点：通常固定布料顶边的几个节点，模拟悬挂的窗帘或旗帜。

2. 软体/可变形体模拟：

节点拓扑：在一个三维体积内（如一个球体）随机或按规则分布节点。
约束边：连接每个节点与其一定距离内的所有邻居节点。这需要根据初始位置动态生成边数据。
体积约束：为了保持体积，除了边约束，还需要额外的约束（如四面体约束）或全局的体积保持力。这是更高级的主题，但核心依然是Verlet积分+约束求解的框架。

3. 头发模拟：

可以看作是多个并行的、稀疏连接的绳索。每条头发是独立的链，但可以在发根处共享固定点，并在头发之间添加微弱的“排斥”约束，防止穿插。

5.3 常见问题与调试技巧实录

在实际使用中，你肯定会遇到各种奇怪的问题。下面是我踩过的一些坑和解决方法。

问题1：模拟“爆炸”或剧烈抖动。

原因A：时间步长（DeltaTime）过大。Verlet积分对大步长敏感。Time.deltaTime在帧率波动时可能很大（比如从60帧掉到30帧，Δt从0.016s变成0.033s）。
- 解决：使用固定的时间步长。float fixedDeltaTime = 1f / 60f;，或者在Step方法中限制_DeltaTime的最大值，例如Mathf.Min(Time.deltaTime, 0.033f)。
原因B：约束求解迭代次数不足。当节点速度很快或初始形变很大时，需要更多次迭代才能在一帧内将系统拉回稳定状态。
- 解决：增加Solve的迭代次数（solverIterations），尝试从8增加到16或32。同时可以尝试更高级的约束求解方法，如“松弛”法，每次只校正一部分误差。
原因C：节点衰减（decay）设置不当。如果所有节点的decay都为1（无阻尼），系统可能永远在振荡。
- 解决：为大部分节点设置一个小于1的decay，如0.98到0.995，引入微弱的能量耗散。

问题2：GPU模拟结果与预期不符，或者渲染不出来。

原因A：ComputeBuffer的数据大小（Stride）计算错误。这是最常见的原因。如果HLSL中结构体的定义与C#中ComputeBuffer声明的stride不匹配，数据就会错位。
- 调试：在C#端，使用Marshal.SizeOf(typeof(GPUNode))打印出实际结构体大小，确保与ComputeBuffer构造函数中的stride一致。在HLSL端，确保struct定义中变量的顺序和类型完全匹配。
原因B：Compute Shader核函数索引或线程数错误。在Dispatch时，如果线程组数量计算错误，部分节点或边可能没有被处理。
- 调试：在Compute Shader的开头添加if(id >= _NodeCount) return;这样的保护语句至关重要。也可以使用Debug.Log输出Dispatch的线程组数量进行核对。
原因C：数据没有正确上传或下载。在修改了节点数据（如通过交互）后，忘记调用_nodeBuffer.SetData。
- 解决：确保任何在CPU端对模拟数据的修改，都必须通过SetData同步到GPU Buffer。

问题3：如何在编辑器中实时调整参数并看到效果？

方法：将关键参数（如_segmentLength,solverIterations, 全局阻尼等）暴露为public或[SerializeField]。在Update中，如果检测到参数变化，就重新初始化_edges中的length，或者更新Compute Shader的全局变量。对于需要重启模拟的参数，可以放在OnValidate函数中处理，但注意OnValidate在编辑器模式下频繁调用，初始化成本高的操作要小心。

我个人在将一个复杂的旗帜布料系统集成到移动端项目时，最大的教训就是数据回读的代价。最初为了调试方便，每帧都读回数据在Scene视图画Gizmo，结果在真机上帧率直接掉了一半。后来彻底改为只在编辑器的OnDrawGizmos中（通过#if UNITY_EDITOR）且仅在选中物体时才进行有条件的数据回读和绘制，性能问题立刻解决。对于GPU计算，一定要树立“GPU是孤岛”的思维，尽量减少跨越边界的通信。