Feem 全双工架构 — 为什么它能同时发同时收

半双工 vs 全双工：一字之差，体验差十倍

网络通信领域有两个基础术语：

这个概念放到 Feem 这里：

半双工的本地传输工具（Xender、ShareIt 早期版本）：你要么向 A 发文件，要么从 B 收文件，同一时间只能做一件事。如果有 3 个人需要给你发文件，他们得排队。
全双工的 Feem：你可以同时向 A、B、C 发文件，同时从 D、E、F 收文件，还能和其中任何一个人发消息。所有传输并行进行、互不阻塞。

Feem 在技术架构上做了两件事：

Feem 采用多线程设计，每一个传输通道（不管是发送还是接收）都运行在独立的线程上。不同线程之间通过队列协调资源，不会互相阻塞。

对比之下，很多早期的本地传输工具是单线程设计——主线程同时负责设备发现、文件选择、传输控制、进度显示，任何一个环节卡住都会拖慢整个流程。

Feem 对每个已发现的设备都会维护一个独立的 TCP 连接和会话上下文。这意味着：

用一个具体场景来说明。假设一个设计团队有 4 个人（A、B、C、D），每个人都需要把自己的设计稿传给另外 3 个人。

A→B    A→C    A→D              (A 串行发 3 次)
        B→A    B→C    B→D      (等 A 发完，B 开始串行发 3 次)
                        C→A    (等 B 发完，C 开始...)

总共需要 4×3 = 12 轮传输，每一轮假设 10 秒，总计 120 秒（2 分钟）。期间大量时间在"等前一个人发完"。

A→B, A→C, A→D   并行
B→A, B→C, B→D   并行
C→A, C→B, C→D   并行
D→A, D→B, D→C   并行

所有人同时开始、同时结束。总共还是 12 条传输通道，但全部并行运行，总耗时大约 10~15 秒（取决于最慢的那一条通道）。

效率提升 8~10 倍。这就是全双工在多人协作场景下的威力。

一个常见疑问：同时发同时收，Wi-Fi 带宽会不会被瓜分，导致每条通道都变慢？

答案是：理论上会，但实际影响很小。原因有三：

现代 Wi-Fi 5（802.11ac）的理论带宽是 867 Mbps，实际有效带宽也在 300~500 Mbps。单条 Feem 传输通常只需要 50~150 Mbps。并行 3~5 条传输，每条仍能分得不错的带宽。

Feem 的多线程不是"野蛮地把所有带宽都占满"。它有内置的流量控制（Flow Control）机制，会根据网络状况动态调整每条通道的发送速率，避免某条通道独占带宽导致其他通道饥饿。

Feem 默认对传输做 TLS 加密，加密解密过程会消耗一些 CPU 资源。在老设备上（比如骁龙 600 系列、旧款 Intel Core i3），加密解密可能比带宽更早成为瓶颈——但这和全双工无关，单条传输同样会遇到。

全双工架构让 Feem 的其他特性也变得更强：

并行传输比串行传输会多消耗一些 CPU 和内存，但在现代设备上这个开销可以忽略：

如果你用的是非常老的设备（比如 Android 7 以前、Intel Atom 处理器），并行传输时可能会感觉到一点卡顿——但那是硬件性能的问题，不是 Feem 的 bug。