更复杂的代码，为何跑得快了10倍？一次Draw Call优化引发的思考

大家好，最近我挖了一个新的开源项目坑：N-Body 模拟，这是一个纯粹由兴趣驱动的项目，旨在通过编程模拟天体间的万有引力，并欣赏由物理规律所生成的优美图形。

在这个项目中，有一个核心环节是绘制天体的运行轨迹。轨迹本质上是一条由无数个点连接而成的曲线。为了高效存储这些点，我使用了一个 CircularBuffer<T>，即环形缓冲区。它的内部实现相当经典：一个数组加上两个指针，分别标记数据的有效起止位置，非常适合存储这种定长的流式数据。

初遇瓶颈：当轨迹长到令人抓狂

最初，我选择使用 Direct2D 的 DrawLine 方法来逐段绘制轨迹。代码的逻辑非常直观，就是遍历轨迹点，然后两两相连画线：

for (int i = 0; i < _lastSnapshot.Stars.Length; ++i)
{
    StarSnapshot star = _lastSnapshot.Stars[i];
    StarUIProps prop = _uiProps[i];

    // 遍历每两个相邻的点，并绘制一条线段
    prop.TrackingHistory.Enumerate2((Vector2 from, Vector2 to, int i) =>
    {
        // 根据点的位置计算一个渐变透明度
        float alpha = 1.0f * i / (prop.TrackingHistory.Count - 1);
        Color4 color = new Color4(prop.Color.R, prop.Color.G, prop.Color.B, alpha);
        
        // 调用DrawLine API
        ctx.DrawLine(from, to, XResource.GetColor(color), 0.02f);
    });
}

在轨迹点不多的时候，这套方案跑得非常欢快。然而，当用户希望看到更长、更华丽的轨迹时，问题就暴露了。当点的数量达到 「10万」 个级别时，界面开始出现肉眼可见的卡顿和掉帧。很显然，性能瓶颈出现了，优化迫在眉睫。

量化问题：用数据说话

为了精准定位问题，我进行了一次简单的性能测试。我使用 Stopwatch 来记录在轨迹点数达到10万个时，整个绘制过程的耗时。

protected override void OnDraw(ID2D1DeviceContext ctx)
{
    // ... 其他绘制准备工作 ...

    Stopwatch sw = Stopwatch.StartNew();

    DrawCore(ctx); // 核心绘制逻辑

    // 当轨迹点达到10万时，打印耗时
    if (_uiProps[0].TrackingHistory.Count == 100000)
    {
        sw.Elapsed.TotalMilliseconds.Dump();
    }
    
    // ... 其他效果处理 ...
}

测试结果相当不乐观，连续几次的耗时输出如下：

50.0262
51.7592
51.0839
50.7521
50.838

平均耗时稳定在 「50毫秒」 左右！这是一个什么概念？为了保证流畅的用户体验（比如 60 FPS），每一帧的渲染时间必须控制在 「16.67毫秒」 以内。现在 50 毫秒的耗时，意味着帧率已经掉到了 20 FPS 以下，卡顿是必然的结果。

柳暗花明：一次调用胜过十万次

既然 DrawLine 的循环调用是瓶颈，那么优化的思路就应该是「减少调用的次数」。在和朋友讨论后，我决定尝试使用 ID2D1PathGeometry 来重构绘制逻辑。

ID2D1PathGeometry 允许我们先在内存中构建一个完整的几何路径，然后一次性地将其提交给 GPU 进行绘制。新的代码如下：

// 先绘制轨迹
for (int i = 0; i < _lastSnapshot.Stars.Length; ++i)
{
    StarSnapshot star = _lastSnapshot.Stars[i];
    StarUIProps prop = _uiProps[i];

    if (prop.TrackingHistory.Count < 2) continue;

    // 1. 创建一个路径几何对象
    using ID2D1PathGeometry1 path = XResource.Direct2DFactory.CreatePathGeometry();
    
    // 2. 打开路径并获取一个"画笔" (GeometrySink)
    using ID2D1GeometrySink sink = path.Open();
    
    // 3. 定义路径的起点
    sink.BeginFigure(prop.TrackingHistory.First!.Value, FigureBegin.Hollow);
    
    // 4. 将所有的点批量添加到路径中
    prop.TrackingHistory.Enumerate((pt, index) =>
    {
        if (index > 0) { sink.AddLine(pt); }
    });
    
    // 5. 结束并关闭路径定义
    sink.EndFigure(FigureEnd.Open);
    sink.Close();
    
    // 6. 一次性将整个路径绘制出来
    ctx.DrawGeometry(path, XResource.GetColor(prop.Color), 0.02f);
}

改完代码后，我怀着忐忑的心情再次运行性能测试，结果让我大吃一惊：

6.8739
6.4511
6.436
6.0901
5.9227

平均耗时骤降到了 「6毫秒」 左右！性能几乎提升了 「10倍」！🚀

刨根问底：为什么“更重”的代码跑得更快？

这个结果一度让我非常困惑。从代码表面上看，使用 ID2D1PathGeometry 的版本涉及到了更多的 API 调用：CreatePathGeometry、Open、BeginFigure、AddLine、EndFigure、Close，还有多个 using 语句。这套操作看起来比一个简单的 DrawLine 调用要“重”得多。

我曾经误以为，DrawLine 是一个非常底层的、直接的绘制指令，而 ID2D1PathGeometry 是一个更上层、更抽象的封装，性能可能会更差。

但「真正的关键在于理解 Draw Call（绘制调用）的成本」。

每一次 ctx.DrawLine 的调用，都是一次 「CPU 到 GPU 的通信」，我们称之为 Draw Call。这是一个相对昂贵的操作，因为它涉及到状态切换、数据传输和驱动程序开销。在我最初的实现中，绘制10万个点的轨迹，就意味着产生了 「10万次」Draw Call！

而使用 ID2D1PathGeometry 的方案，虽然在 CPU 端看起来代码更复杂，但所有的路径构建工作（AddLine 等）都「只在内存中进行，不涉及与 GPU 的直接交互」。直到最后调用 ctx.DrawGeometry 时，这 10 万个点的几何数据才被打包好，「一次性」地提交给 GPU。

这就相当于，我们将 「10万次零散的 Draw Call 合并成了一次重量级的 Draw Call」。GPU 一次性接收所有数据，然后高效地完成光栅化。虽然单次传输的数据量变大了，但完全避免了 99999 次昂贵的通信开销。这正是性能提升近10倍的根本原因。

总结

这次优化经历让我深刻体会到，在性能优化的世界里，「找到瓶颈所在，远比知道如何优化更重要」。

1. 「表象具有欺骗性」：API 调用的多寡并不直接等同于性能开销。看起来“重”的代码，可能因为更符合底层硬件的工作原理而快如闪电。
2. 「理解原理是关键」：如果不理解 Draw Call 的成本，我可能会在其他地方（比如数据存储、颜色计算）浪费大量时间，而这些地方的优化对于整体性能来说可能只是杯水车薪。只有理解了“CPU与GPU通信是昂贵的”这一原理，才能找到正确的优化方向。
3. 「量化驱动优化」：没有性能测试的数据支撑，所有的优化都只是猜测。通过 Stopwatch 精准量化，我们能清晰地看到优化的效果，并确认我们的方向是正确的。

「性能问题往往不是因为计算机“算得慢”，而是因为我们在用一种“低效的方式”让它去算」。理解其工作原理，才能让它发挥出真正的威力。

感谢您阅读到这里！如果感觉本文对您有帮助，请不吝 「评论」 和 「点赞」，这也是我持续创作的最大动力！