这些编码软件当时 CPU 都没问题 现在的 CPU 更是轻松
不过现在很多 CPU 或者硬件会有带硬件加速可以 硬解 SBC AAC AC3 这些了
硬解也只要调用系统的 API 就可以实现 只要做好系统兼容性就好 具体软件不需要操心

写一个很容易 但是要让很多人用就难了 要推广和运营好更难 还要能融资 你是有什么黑科技呢还是有大量的用户呢？

@leebs "某个条件触发了耗时的 cpu 运算"
耗时 CPU 运算目前两种方法，核心概念就是保证主线程不阻塞
1. 把这部分放到其他子线程或者进程 然后主线程异步处理
2. 如果上面太难 就把需要长时间 CPU 处理的运算打碎成多个短暂同步运算然后异步处理 保证主线程不要长时间卡住

对于 2 比如一个运算需要 10s 那么就把它打碎成 1000 个小运算 每个 0.1s 然后中间异步等待
这样主线程就不会因为一个 10s 的运算而阻塞 10s
虽热这样一来 原先 10s 的事情可能变成了 15s 或者更久 但是至少不会长时间阻塞其他的请求

当然 2 这种方法比较时候低并发或者低概率触发的情况
如果真的高并发情况大概率 还是要用 1 来处理

@leebs node 单线程 如果做“CPU 密集的工作”或者“同步的 IO 操作”就会卡住
这个是一定要避免的 如果没法避免就必须用 worker https://nodejs.org/api/worker_threads.html

然后保证主线程不卡住就没问题了
所以 node 做 IO 密集的工作 性能还是可以的

不够就上多个 node 进程 然后外面做负载均衡就是
尽量无状态 如果必须要 session 就用 redis

@otakustay 用 C 口 的不一定是 PD 协议啊
我手头就有只支持 QC3 的 协议不支持的情况下只有好像最大只有 5v2a
M1 的 Mac 只要不是边用边充 应该还是可以冲进去一点点的

@xiaocongcong 买个 USB C 转 A 的转接头 几十块的事 这样偶尔用 U 盘也方便
如果经常需要 USB A 的话还是买个几百块的 hub 比较好

@hello2090 如果 fallback 到 5v1a 虽然“能充” 但是没有实际意义吧

@hello2090 不一定哦
C 口 有好多快充协议 Apple 只支持 PD
其他协议可以冲 但是可能会非常慢 搞不好越冲电越少

应该说所有支持 USB-C PD 的充电头都可以用

而且千万不要碰到一些魔改的充电 C 口 或者质量不行的
那就可能会把充电口烧了的

@mokevip 如果是给用户下载用的 建议用 zip 或者 tar+gzip (tgz)
如果面向普通或者企业客户用 zip 比较好
如果面向开发者或者工程师 tgz 比较好

@ysc3839 如果是自己内部用的 要压缩率不在乎时间用 tar+xz 要速度不在乎压缩率用 tar+zstd
如果是给客户 还是 zip 或者 tgz 比较好 你看 gitlab/github 都提供这样的

gzip 本来就不是压缩多个文件用的
gzip 不是 zip 文件格式
只能压缩单个文件或者 Buffer/流

如果要压缩多个文件 一般先 tarball 打包 然后再 gzip

如果不想按照 tar 来打包 你也可以自己打包多个文件
比如直接把所有 buffer 拼接在一起再 gzip 然后存一下文件名和 offset 就好

不奇怪啊 XS 已经老了 面对新机当然会比不过
但是你又觉得 13 贵 不值

你想要一个和 iPhone 一样的但是更便宜的新安卓机
当然这是不可能的
除非今年出全新 SE3 但是也已经爆料说不会出全新的了 只是 SE2 的内部升级

不奇怪 很多人都有这种“纠结”

你已经被 Apple 生态绑定的话 还是努力赚钱吧 钱够了 就不会纠结了

另外你也没必要觉得 Apple 不作为 毕竟疫情和芯片短缺的问题实实在在
Apple 又不是一个中国的企业 对国内企业已经影响不小了 在国外这些问题很严重的 现在做的已经不错了
你也只能怪 Apple 是 Design in CA 不是 in China 了

two-factor 就够了啊
就算验证码输入可以被监视
过一会儿就失效了

如果担心验证码被监控 可以用硬件啊
Yubikey 之类的

Yubikey 这种 其实就是一个虚拟的键盘硬件
然后里面算出来验证码 然后虚拟的键盘硬件通过 USB/蓝牙 /NFC 输入

@zyu0090 前提是之前没有刷过机
已经刷过怎么都没办法了