hronro

[hronro @hronro]

@ewind_dev 又是一个 RIIR 项目吗？还是比起原版的 QuickJS 有什么明显的优势？

[hronro @hronro]

@jiahan_c 这人不是之前在搞 Ripple 吗，怎么又开了个新坑

[hronro @hronro]

@LeaskH 这个我记得好像是 PPPOE 的图标吧，如果是 DHCP 直接分配 IP 的话是不会有这个图标的。

[hronro @hronro]

@raoneoz It’s exactly like the way Japanese soldiers treated Chinese civilians during World War II.

[hronro @hronro]

太多人多负数 RC Filter 有误解了，我来简单解释一下，负数 RC 的本质其实放大摇杆的输入信号，比如说你在 0.1 秒内把摇杆从 0 推到 0.5，负数 RC 可能会把输出放大到 0.8 甚至更高，结果就是你会感觉你的变向更快了，加速更猛了。所以即使在完全没有辅助瞄准的 FPS 游戏中，负数 RC 也是有用的。需要注意的是，负数 RC 并不能降低你的输入延迟，他的这种放大行为就像是预判了你的后续输入，但这种预判并不是每次都正确，同时你的错误输入也会被它放大。另外，摇杆噪声也会被放大，这就是很多人说的“抖动”。

那么为什么负数 RC 在 Apex 中引起了这么大的争议呢？原因有二：

1. 有些 FPS 游戏的转向辅助，需要检测到右摇杆有一定的输入达到一定阈值才会启用，（比如 Apex/COD），当右摇杆静止或者输入很小是，转向辅助不会启用。但启用了负数 RC 之后，即使在右摇杆静止的情况下，由于摇杆噪声被放大，此时也能被游戏判定为超过输入阈值，从而启用转向辅助。
2. Apex 中辅助瞄准中的减速强度，与玩家和目标之间的相对速度有关，而负数 RC 放大了你的输入，你就有了更大的相对速度，从而你就能感受到更大的减速强度。

但在 The Finals 中，转向辅助是无条件启用的，无论右摇杆是否有输入。同时 The Finals 中的减速强度也是固定的，和相对速度无关。所以我个人认为，负数 RC 在 The Finals 中并不会给你带来不公平的优势，但它确实能改变（改善）瞄准的手感，所以我个人觉得负数 RC 在 The Finals 中是值得一试的东西。

[hronro @hronro]

@skywind3000 微软现在确实找对方向了。那个新出的基于 Rust 和 WinUI 3 的 windows-reactor 感觉还不错：https://t.co/CnXeWSk8ox

[hronro @hronro]

蛮有意思的，这两个人都在试图把造成这个问题的原因，归咎到某个与真正罪魁祸首毫无关系的东西上：原推把所有责任都推到了 Linux，而引用他的人把所有责任都推到了微软。
那么真正的责任在谁呢，我们来梳理一下：

- VS Code 是基于 Electron 开发的。VS Code 本身并没有在屏幕上渲染相关的代码，这部分都是由 Electron 负责的。
- 原推中遇到的问题，大概率是 Electron 在开启硬件加速之后，由于显卡驱动问题导致的。
- Electron 可以说是 Linux 的救星，Linux 上非常多应用都是基于 Electron 开发的。所以说并不是“其它所有东西似乎都运行良好”，所有基于 Electron 的应用应该都有这个问题。
- 原推中展示问题的是一段录屏，但我们我们在视频中却没看到任何录制软件的图标。同时视频中出现了两个光标，并且在鼠标点击的时候，光标周围会出现了一个圆圈。这看起来非常像是 macOS 自带的屏幕录制功能录出来的效果。也就是说原推是在 macOS 上使用了虚拟机运行的 Linux，然后使用了 macOS 的屏幕录制功能来录像的。
- Apple 的软件和硬件都不支持完整的 GPU 虚拟化。而在虚拟机中开启的 3D 加速，实际上是一种半虚拟化，你在 Linux 的 OpenGL/Vulkan 指令，会被翻译成 Metal 指令交给宿主机（macOS）执行。
- 显而易见这种转译层并不完美，遇到 BUG 也是正常的。

所以，这个事件的罪魁祸首其实是 Apple/macOS/macOS 上的转译层。但如果你不熟悉这所有的细节，你可能很容易就会像这两个人这样，把责任归咎到其它地方。

[Drak @_cyberdrak_]

- Instala un programa hecho por Microsoft en Linux
- El programa falla miserablemente cuando todo lo demás aparece funcionar bien
- Culpa a Linux

[hronro @hronro]

Tailscale 无论在哪个平台都依赖于 wireguard-go，都是用户态的实现。而且 Tailscale 有专门发博客讲他们是怎么把用户态的 wireguard-go 优化得比内核态的 wiregaurd 性能还要好的。我个人感觉普通用户也很难遇到内核态和用户态的瓶颈，没必要纠结那么多，直接用 Tailscale 的 macOS 客户端方便又省事。

[hronro @hronro]

@amehochan @lichuang 说实话，Sublime Text 打开大文件性能还不如 VS Code

[hronro @hronro]

@geekbb 你是不是对原生应用有什么误解？

[hronro @hronro]

@SoonCrush 远远不如 GFN 一根。GFN 上 20 美元可以有 100 小时的 9800x3d + RTX5800了，串流码率也能拉到 100Mbps，基本和本地游玩画面差不多了。

[hronro @hronro]

@abskoop 降噪耳机因为有了降噪，所以在嘈杂环境里可以开比普通耳机更小的音量，所以应该比普通耳机对耳朵的损伤更小。

[hronro @hronro]

@wwwgoubuli Rust 里的错误也是显示的吧，只是加了 ? 语法糖来帮你写快速向上传播错误的样板代码而已。

[hronro @hronro]

很多人觉得 Web 应用比原生应用慢、容易卡顿，是因为 JavaScript 太慢了。

事实恰恰相反，JS 其实很快，真正拖慢 Web 性能的，是因为 C++ 太慢了。

听到这里你肯定想反驳：明明 C++ 比 JS 快了不止一个数量级，你在这反向科普什么呢？别急，我们先来拆解一下 Web 到底慢在什么地方。

Web 的“慢”，主要慢在 UI 渲染上——也就是首次加载看到页面的时间，以及你每次交互后 UI 变化的时间。这种卡顿可能只有几十毫秒，但相比原生应用“指哪打哪”的丝滑，Web 就是让你觉得不够跟手。至于应用自身的业务逻辑计算，那点时间差用户压根察觉不到。

那究竟是谁在负责渲染 UI 呢？不是 JS，也不是 React。真正干脏活累活的，永远是浏览器的渲染引擎（比如 WebKit 或 Blink），而它们，全部都是用 C++ 写的。 JS 和 HTML 只是个“传话筒”，通过 API 告诉 C++ 引擎该画什么，自己并不负责真正的渲染。

看到这里你可能明白了，我说的“C++ 慢”，并不是指 C++ 这门语言本身不行，而是指它所实现的浏览器引擎和 DOM 机制，实在太慢了。

由于 DOM 本身庞大臃肿的设计缺陷，加上长达几十年的历史遗留包袱，导致这套 C++ 引擎在处理复杂网页时效率极低。更致命的是，JS 引擎和 C++ 引擎之间还要进行“跨语言通信”，每次 JS 操作 DOM，都要交一笔高昂的过路费。

相比之下，JS 凭借 V8 等引擎的 JIT 优化，性能早就跻身编译型语言的梯队，应付业务逻辑绰绰有余。所以，性能黑洞不在 JS 身上，反而在 C++ 写的渲染引擎里。

既然主要的性能瓶颈在底层渲染，那前端框架（如 React）天天做的性能优化，又是在优化什么？

今天的 Web 应用太复杂了，直接用原生 API 纯属开发灾难。React 引入声明式语法和 Virtual DOM，本质上是在 JS 层做了一层抽象。但抽象是有代价的，Virtual DOM 的 Diff 算法本身就会带来高昂的 JS 计算开销。

很多人崇拜的 React 时间切片（Time Slicing），实际上并不是让浏览器变快，而是把这笔高昂的 JS 开销拆分到各个微小的空闲时间片里，防止主线程被死死卡住，从而让浏览器有喘息的机会去优先响应用户的输入。换句话说，这个优化只是为了解决 React 自身引入的开销，它根本绕不过 C++ 引擎底层的性能天花板。

至于 Flutter on Web 为什么感觉更流畅？因为它是“掀桌子”的玩法。它直接弃用了浏览器的 DOM 树，改用 Canvas 配合 WebAssembly 运行的底层库（CanvasKit），在网页上直接绘制像素。这确实绕过了 C++ 引擎的 DOM 限制。

但 Flutter on Web 会是未来的趋势吗？我看未必。

这么做相当于在网页里硬生生自己造了一个微型的 UI 渲染引擎。这就意味着，除了业务逻辑，你还要靠代码去手动实现一大堆浏览器原本自带的底层特性：比如文本复制选中、SEO、屏幕阅读器（无障碍支持）等等。

让 Flutter 团队去把浏览器几十年沉淀的 feature 全重写一遍，成本太高了。再加上近期 Google 缩减 Flutter 投入的传闻，Flutter on Web 恐怕很难成为未来的主流。Web 的未来，终究还是要看 Web 自身标准的进化。

[wwwgoubuli @wwwgoubuli]

提到 web 的流畅，我讲点东西，和 flutter 没关系，和 react 有关系。

早期显示器基本都 60Hz。

所以浏览器提供了一个 API 叫 requestAnimationFrame，跟随屏幕刷新节奏。

所以这就是很多人都知道的 60帧那个事，如果 16.6ms 里没跑完，就会掉帧。

也就是 React 那个知名的发现时间快用完了就先暂停，把主线程还给浏览器，让它去画画，处理用户事件的行为。

今天的高刷显示器变多了，120Hz，144Hz，还有 240 和 360 的显示器（虽然我觉得意义不大了），意味着单个时间切片也变短了。

但 React 并没有继续跟随说把 16.6ms 继续切短，做更多调度，比如算成 8.3ms。而是改成了默认切片时间就是 5ms。

理由是这样的：

5ms 对于 60Hz，在一帧 16.6ms 里可以跑最多 3 个 5ms 的切片。

如果是 120Hz 的 8.3ms，跑 5ms 还有3.3ms 多余的时间，浏览器可以从容地去完成各种绘画和操作。

如果是 240Hz，4.1ms，5ms 稍微超时了一点点，但这时候人眼已经感知不出来了，所以也无所谓。

除非你是个电竞选手。

5ms 是个很好的 sweet spot。

这个细节可以自己去搜索下，官方有提过，也有不少文章讲过。如果你现在打开 https://t.co/osO381er3d 也可以看到第 16 行的引入，指向了一个 5ms的 flag。

只不过很早以前在 scheduler 里好像是写死的，现在要处理的不只是浏览器，在不同环境编译时，可以更容易的调整这个参数。

——————
上面一大通其实和原 po 说的 flutter 没什么关系，只是今天正好复习到这里，看源码有一些东西发生了变化，就正好巩固下。

web 仍然有很多不如 native 丝滑的地方，w3c 的保守策略，历史欠债等，但一直有无数人在为了它的性能和表现在努力。

有很多地方确实不适合 web 方案，选 native 更合适。但我高度怀疑——可能有的开发者根本就不知道怎么用好 web 方案。
——————

我不是专业的前端开发，可能有不准或错误的地方，那就请大佬们指正。

[hronro @hronro]

@HappyQQ_AI 老实说我已经几年没用过 VS Code 了，不过在我的印象中，VS Code 如果不乱装插件，性能还是能看的（除了冷启动慢点）。

[hronro @hronro]

@HappyQQ_AI 如果你看过 VS Code 的一些访谈，你会发现 MS 首先想做的是一款能跑在浏览器里的在线编辑器，其次才是想做一款好用的编辑器。在能跑在网页上的前提下， VS Code 的性能基本没什么提升空间了，如果你用过已经死掉的 Atom，那才是真正的慢卡崩溃，而 VS Code 已经解决了 Atom 的性能问题。

[hronro @hronro]

@geniusvczh 轮子哥现在不用 Copilot 了？

[hronro @hronro]

@q1ngyang @StarrySkyOvO i 家的 GPU 搞虚拟化还需要破解吗

[hronro @hronro]

@wuyuandev @WinRAR_RARLAB 什么意思？某个服务的付款验证，是在某个 UI 库里自做的？