之前用过 Packet Sender ，支持 TCP 和 UDP

Unity Editor 主要吃 CPU 性能吧，MAX 和 PRO 应该只有在 Play Mode 有性能区别，而且这点性能区别也可能被 Play Mode 一些 Debug 功能吃掉，体感上的提升可能不是那么大。

但是既然买了，就别换呗，16 寸用起来肯定比 14 寸更舒服。

PS 2020.2.xf 版本是真的不稳定

- 纯前端开发， 配合 VSC 和 WebStorm ，体验只会比 Win 本好不会更差
- 纯 Node 开发，同上
- 涉及 Node Native Modules 开发，请做好和工作流有关的调研
- 工作流强烈依赖 Docker ，请做好和 Image 相关的调研，有 x86 工作站 /服务器可以忽略本条，mac 本地当成一个 docker client 即可
- 反正我现在基本用不到本地的 Docker Desktop ，因为兼容性实在是个问题

- Jetbrains 系 IDE 目前重度使用过 WebStorm, PyCharm 和 EAP 版本的 Rider ，PyCharm 经常无法连接到 Debugger ，需要重启才能运作，目前没找到什么 Workaround ，不知道是系统问题，Python 版本问题还是 PyCharm 问题

@svampire 是的，而且 2021.2 系列的版本使用的体验真是一言难尽，BUG 贼多，只能说勉强能用

@luozhiyun 兄弟观察的挺仔细的，手头的 16 寸还留着，以防真的遇上了解决不了的问题。不是什么上得了台面的游戏，小众圈子里圈地自萌罢了
@link1994 平时社交圈过于狭窄，一直没有遇到心水的女孩子。的确，不做开发的话我宁可搞一套 ROG ，同价格配置可以直接起飞

@BlackJac95 国内没啥人用 Nest 吧，感觉 egg 更主流一些，我们是因为首席架构特别喜欢 Nest ，所以没得选

@zhpalt 对，本身就是原型项目，主要还是测试新的 Native Unity Editor (2021.2.2f)，大项目还是用着之前的 LTS 并没有迁移到这台电脑上

@zhpalt 这是我最近七天的内存压力曲线，很少有超过 25%的情况，基本开发场景是
- Jetbrain rider x2 一个客户端，一个服务端
- Unity 2021.2 x1 开发游戏
- Vscode x1 用来写一些脚本
- Docker for Mac 分配了 2G 内存，用来跑本地数据库

供你参考


Testflight 的话只有版本号改变需要审核，单纯增加 BuildNumber 应该是不会有额外审核的。

开箱即用的方法应该是不存在的。
要想避免 O(n)的查询复杂度的话，万变不离其宗的方法就是加索引，比较简单的就是加个对于 status 的倒排索引

倒排索引的 key 就是 status 的值，如下例子
[1] => {user1, user2, ...}
[2] => {user3, user4, .....}

如果服务器是 wsgi 的话，建议直接上 uwsgi 或者 gunicorn 来进行多 worker 部署，这两个都有能力部署多个 worker ，在实现接口的时候没那么多负担

我理解你的问题是，为什么 x86 的 docker 可以直接运行 arm64 的 docker image ？

以 Docker Desktop 为例子，安装时会自动安装 qemu 依赖，不同架构的镜像靠的是 qemu 模拟，可以参考以下回答
https://stackoverflow.com/questions/66350893/why-macosx86-can-run-docker-arm-container-arm64v8-alpine/66435150#66435150

可以通过 docker manifest 来检查一个镜像的架构，比如
docker manifest inspect --verbose arm64v8/alpine

"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}

坐标法国
14 寸满血 PRO + 32G + 1T
发布会结束立即下单，估计是因为换了美式键盘的缘故，预计到达时间 11/04 - 11/08

然后探讨下你叙述中显露出的一些问题，仅供参考

1. “登录 1000 人，每个客户端每 20ms 给服务器发送一条测试消息，长度为 10 的字符串”
不知道你的游戏框架的序列化是怎么做的，若是想要反映真实情况，仅仅用字符串来模拟肯定是不够的，建议在压测环境中引入序列化和反序列化，这样可以更多暴露出在这个过程中的内存、CPU 问题

2. “每个客户端每 20ms 给服务器发送一条测试消息”
不建议给 20ms 间隔，每个客户端直接将单个 TCP 链接打满更具备压测意义

3. “10 多分钟开始客户端大批掉线”
不知道你客户端掉线的原因是什么，若是用 TCP 的话，最好可以知道连接断开的原因然后具体分析，正常情况下掉线一定是不正常的

最后，
若是你的序列化方案就是字符串序列化，而又不想自己写压测逻辑的话，可以考虑用你的服务器结构实现一个最简单的 HTTP Server，然后用成熟的 HTTP 压测工具去压，这个不具备任何业务逻辑，但是能很好暴露出你潜在的服务器处理能力。

这里我用的 wrk， 可以参考一下我在 MacBook Pro (16-inch, 2019) 2.3 GHz 八核 Intel Core i9 下的结果，
wrk -c 400 -t 4 -d 5 http://localhost:13023/

Running 5s test @ http://localhost:13023/
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.11ms 1.25ms 38.01ms 88.82%
Req/Sec 20.08k 2.02k 23.81k 83.33%
407661 requests in 5.10s, 60.65MB read
Socket errors: connect 153, read 101, write 0, timeout 0
Requests/sec: 79880.37
Transfer/sec: 11.88MB

最近也在做类似的事情，可以参考一下我的方法论

1. 时间指标
- 平均响应时间
- 最大响应时间，用来衡量极端情况下的用户承受的最大延迟
- 方差，标准差，用来衡量用户承受延迟的分布
- 有能力的话可以做一个直方图，并不需要全量记录，个人感觉取 1%抽样就足够了

2. 内存指标
我用的是.net core, 一些概念可能和 java 不一样，可以类比下
- GC 次数，特别是不同代的 GC 次数
- GC 时间占总执行时间的比例
- 若是 GC 次数不正常，可以考虑间隔每段时间取堆内存的 snapshot，若是工具支持，最好可以拿到内存分布的热点图，比如这个函数这一行分配了全体的 90%的内存

在有以上数据的情况下，即使没有同类型的框架可以横向比较，也可以自己根据压测结果优化迭代，再行压测比较。

已经下单 14 寸 PRO 版本，没买 max 版本实在是囊中羞涩
到时候看看 16 核 GPU 能带来什么样的体验

可能 Conditional Types 可以帮到你
https://www.typescriptlang.org/docs/handbook/2/conditional-types.html

看一下 select_related 是否能满足你的需求
https://docs.djangoproject.com/zh-hans/3.2/ref/models/querysets/#select-related

看一下 webstorm 的 local history，或许还能救

没有 stash 的话基本没办法了

看到这题感觉回到了大学。

如果仅仅要求支持以上的几种形态的话，简单的做法就是定义等差，等比，开方等差的规则，然后判断当前数列不满足条件时，做差去递归求解就是了。别忘了加上最大递归层数的限制。后期如果增加需求加规则就好了。

不想要仅仅如此的话可以看一下如何做一个求解器，举个现成的例子，你在 wolfram alpha 上直接搜索 1，3，5，7，9，他就会提示你这是个等差数列，并给出通项公式，网址： https://www.wolframalpha.com/input/?i=3%2C5%2C7%2C9%2C11

最后，作业还是自己做吧。

- 需要额外更新的操作放到此异步方法内，额外更新的是同步操作

需要等待额外更新的操作结束才返回么？如果需要等待，那没必要用 Task.Run 再包一层

如果不需要等待，只是希望执行了以后就不管了，那么去掉 async，await，直接用 _ = Task.Run(...) 就可以了，Task.Run 会在线程池上执行操作，所以并不会开辟过多的线程。

---
另附，
1 、普通处理只需 CPU 计算
如果的确这个普通处理会耗费相对较多 CPU 时间，而期望调用函数尽快返回的话，用 Task.Run 是一个比较常见的方法

2 、需要数据库读写等 I/O 操作
此处建议直接找原生支持 Task 的异步方法的库