📚 课程目录第2章跨模块通信基础

2. 跨模块通信基础：模块划分、通信接口与数据流归纳总结

跨模块通信这件事，说简单也简单，说复杂也复杂。我见过太多项目，前期觉得模块划分无所谓，等到了性能优化阶段，才发现通信延迟已经把帧率拖垮了。这一章我们先打好地基，把模块划分、接口设计和数据流梳理清楚。这三样东西理顺了，后面排查延迟问题才能事半功倍。

模块划分的核心就四个字：高内聚、低耦合。但落实到实际项目中，怎么分才合理？我个人习惯从两个维度来思考。

第一个维度：按功能域划分。说白了，就是把干同一类事的代码放到一起。渲染管线放一个模块，物理计算放一个模块，资源管理放一个模块。这样每个模块职责清晰，内部的改动不会影响外部。

第二个维度：按数据流划分。有些场景下，功能域划分不够用。我记得有一次做一款实时渲染工具，发现渲染模块和逻辑模块之间通信极其频繁，数据来回倒。后来我们把这两个模块合并成了一个更大的渲染管线模块，通信延迟直接降了40%。

下面是我总结的模块划分的几个关键原则：

提示：项目初期可以先用一张模块依赖图把关系画出来。我习惯用Visio或者draw.io画，画完你就能直观看到哪些模块之间通信过于频繁，哪些边界需要调整。

模块划分清楚了，接下来就是模块之间怎么说话。接口设计得好不好，直接影响通信延迟。

通信接口从大的方向分，就三种：

这里我想重点说一个坑：同步阻塞调用。我在项目中遇到过这样一个案例——逻辑模块调用渲染模块的接口，用的是同步RPC，渲染模块处理一帧需要16ms，逻辑模块就在那干等。结果就是逻辑模块的帧率被硬生生拖到了和渲染模块一样。你想想看，这其实完全可以用异步队列来解决。

避坑指南：我曾经因为忽略了一个接口的阻塞特性，导致整个管线在高峰期卡死。那次排查花了我整整两天。从此以后，我对每个接口都要求标注清楚：是否阻塞、是否有超时、是否有重试机制。

模块和接口都搞定了，接下来要回答一个问题：数据到底是怎么走的？从输入到输出，中间经过哪些模块？每个环节花多少时间？

数据流归纳，说白了就是给系统画一张“物流图”。我建议你按这几个步骤来：

做完这一步，你就能看到数据流中的“拥堵路段”在哪。举个例子，我几年前优化一个AR应用，画完数据流图发现：视频帧数据在送到渲染模块之前，在资源模块里做了一次多余的格式转换。那一次转换占用了3ms，去掉之后帧率直接从50fps升到了60fps。

  核心思路：数据流归纳不是为了画图而画图，是为了帮你找到那个“本不需要存在的延迟”。每多一次拷贝、多一次转换、多一次同步等待，都在吃掉你的帧率预算。

这三者不是孤立的。模块划分决定了接口的数量和复杂度，接口设计决定了数据流的效率，数据流分析又能反过来验证模块划分是否合理。它们形成了一个闭环。

下面这张图总结了本章的核心逻辑：模块划分是骨架，通信接口是连接，数据流是血液。延迟问题往往就出在接口堵塞或者数据流绕路上。

你在这张图里能看到三个核心信息：

延迟爆发点往往出现在接口处或者数据流的关键转折点。比如图中的 B→C 段，共享内存如果没用好，数据拷贝和同步等待就会在这里堆积。

注意：不要等出了性能问题才去画数据流图。我个人的习惯是在架构设计阶段就把数据流图画出来，标出每个接口的延迟预算。这样后面做性能优化时，你手里就有一张“地图”，知道该往哪个方向挖。

模块划分、通信接口和数据流归纳，这三件事是跨模块通信的地基。地基没打好，后面做延迟排查就像在迷宫里找路——累还不一定找得对。