是不是要到你的例子了

@renmu123 现在已经不流行 dropbox 了吗？

这个优化（如果不开源的话）会拦住绝大大多数模仿者，体验会做的比别人都好，因为华为在通讯（老本行），音视频编解码（海思技术）等方面的深度，往最谦虚里说，在国内也是数一数二的。

SC 局域网联机玩过吗？把应用层协议（类比 HTTP 、WS ）放到 OS 层，再把一些常用设备（如摄像头、门铃）的 “API”（类比 API 的 JSON 数据格式）也封装到 OS 层，然后再把协议优化一下（比如不基于 TCP/UDP，而是基于 IP 甚至 Mac 层）。

无区别（或者说区别不大）：chrome 简化的认为一个 Tab 一个进程 VS IE6 哪种一个页面开一个程序 =》 由于页面和页面间的关系一般不大（除了切换稍微麻烦一点），你可以认为没什么关系

有区别：爬虫，多进程版本会自动分配不同的任务给不同的进程，这其中会有很多协调工作（不重复，失败重分配等） VS 单进程多开几个版本，你要手动的配置每个进程的任务，并且不会协调（快的程序做完了就停了，不会替别的程序干活）

招行如果在深圳的话，有那张香港工作人员过来办的，不过近期疫情过不来

> 多开一个线程（调度器或虚拟机）来调度这些协程
简单的一个逻辑问题， 假设多开一个线程额外消耗 1000，每次协程切换比线程切换少消耗 10，那么管理 100 个就回本了，管理 1000 个优势就上来了。

前端搭个 nodejs，结束

@Tianao 说的对，你先得定义“视觉上的红色或蓝色”，如果说不清楚的话，选一些样例，炼丹吧

大多数 PM 都是平庸的

1. 没有接口的情况下，你没办法保证你没有任何 bug，@redtea 最后肯定就慢在联调这里了，但很可能最后一个 bug 还是落在你这里，你说不清楚
2. 你觉得他划水，他可能觉得你甩锅，所以写周报不一定能解决问题，但不写肯定不行
3. 最怕的是你们两没有一个统一的领导，更上级已经不怎么管技术

说 redis 的，其实和你的方案没有本质区别，都是找一个地方存储，当然 redis 可能更合适，因为
1. 超时不需要你处理了，天然支持
2. 性能更好，但实际上估计你也跑不满

另外，你说的那个在是否更新标志使用 redis 也是要处理的，而且也需要一个超时

测一下路由器的类型

@itbeihe 跟聚合接口有点类似，有什么好的框架吗？

@ybonfire 对，那么这一层应该放在哪里？ App 里？云上的某个模块，比如 node ？后端的某个模块里？


@wangritian 如果不上 HTTP/2.0 的化，性能会是另外一个问题，如果上了的话，你怎么看我前面提到的几个问题？

能简单说一下原因吗？
在服务的最底层，肯定是基于领域来开发的，但聚合这件事本身逃不掉，要么在后端做，要么在前端做，所有这里仅讨论放到哪里做合理。

>> 小插曲：顺便写到这里想到一个问题，大家对前后端的理解，会不会不一致？比如 H5 端、App 端肯定算前端，那么 node 端呢？我理解严格来说 node 端是不严谨的说法，但为了交流方便这里借用一下这个概念。或者严谨一点，如果用一个 nodejs （获取其它技术） 把业务接口进行了聚合，那么这个 nodejs 算前端还是后端？（我后面的描述把这一部分仍算作后端，如果大家定义不一致可以探讨）

继续探讨放哪里合理的事，我个人认为放到后端因为：
1. Android 、iOS 绝大多数情况下，只需要做一次聚合逻辑
2. API 形式的对接，更容易做测试。（不是说不能做，但更容易，可以探讨，我也没有在查到太多在 App 内做“单元”测试的成功案例，注意这里“单元”打了引号，因为严格来说，直接测 API 不属于单元测试范畴）
3. 调整业务逻辑不需要用户升级（仅限 APP ）
4. 日志更容易获取，方便解决问题。（同样是相对来说，我了解 App 有各种日志上传的方案，但这个因为比较敏感，网上资料不多）

另 @ChanKc @ppphp 提供的 graphql，之前了解不多，需要去细看一下，感谢

经常打的字会变成 VIP 专用字

国产电视集成乐播投屏方案，airplay 已经很成熟了，经常用 macos 投屏开会，除了现在乐播强制加了广告