他认为是系统的问题，那根据是什么？只要有理有据，即使结论不正确，我觉得问题不大。
能否因为一次判断失误，就下结论认为他是这样一个人呢？一而再，再而三这样的话，那的确是这样的人。
思维方式还是很重要的，写代码是比较看重 debug 的能力。

大法的电池很强，17 年买的电视机，遥控板的电池今年才没电，整整坚持了 7 年。

侠之大者

哪里没有畜生？为什么会有这种不用证自明的话题？😂

鸿蒙的开发工具 Mac 版本居然没有 Intel 的模拟器

界面脚本可以实现，我用的网易的 airtest

静态库符号不存在，就是.o 没有被编译进去。一般 release 不会包含没被引用到的符号，debug 好像为了提高编译速度，会全量打包进去。

静态库架构对吗？ ARM 模拟器需要 ARM 静态库，另外 debug 不会对静态库进行裁剪，应该都会包含进去。

赢得太轻松了

可以获取运营商信息。。。

都要裁了，也就不用在乎是不是同事了

@dnjat 音视频的成本就是高的，不过你们这种一对一的，其实还是算简单的。但是正如你说的，如果需要 NAT 穿透，流量还是要走服务器，无法 p2p 。

2 这个问题就涉及架构问题，综合来看，多方通信架构无外乎以下三种方案。

Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A 、B 、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A 、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
MCU （ Multipoint Conferencing Unit ）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
SFU （ Selective Forwarding Unit ）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

我估计你们会采用 SFU 架构。

@dnjat WebRTC 是有处理的，看看有没有现成的开源，直接跑起来看看效果如何

降噪、回声消除这些你们自己就搞不定的。。。