写插件的门槛越低，生态就会越好，用户量也会越多。

性能优化有边际递减效应，性能非常差确实影响体验，然而达到一定水平以后，再优化也不会有明显的体验提升了。
随着近几年处理器性能极大提升，加上内存价格大幅下降，长期来看，其实 VSCode 优势更大。

对了，顺便一提，Tauri 的规划里其实还有抛弃 WebView ，自己实现界面绘制，虽然我感觉大概率走不通这条路。
但是可以从这一点看出来，Tauri 的目标和 Electron 其实完全不一样，只是恰巧有一些交集……

其实两者的用途不太一样……

Electron 适合直接把网页打包成应用，或者以 JavaScript/TypeScript 为主的应用。
而 Tauri 的定位则是为 Rust 程序提供一个界面，只是界面部分使用系统的 WebView 来实现。

不绑卡不购买容易被封。
注册之后马上绑定支付方式，买个便宜的应用就好了。

100%不是全新，估计是退货的机器
哪怕是官方翻新，都会换一块新电池

是这个问题：
https://www.v2ex.com/t/736214

@killgfat 其实还可以指望原生 Windows on ARM 游戏，等到今年 6 月就有原生 Unity 了。
目前 Android 上那些模拟器跑 Wine 本体和 DXVK 也是转译的。

@nuevepicos 如果游戏改用 Vulkan API ，其实可以直接使用 AMD 官方的 FSR2 实现。
苹果只有 Metal ，所以得自己移植 FSR 到 MetalFX 里了。

要是真做 Android 3A 大作，那么用 Vulkan API 很合理吧。

@Hsinyao
英文版 Windows 的 Swap 还真叫 Virtual Memory……
不过无所谓了，已经能根据语境来区分它的含义了。

@geeksammao
其实还真有，以前 HTC 的系统就默认开启 Swap ，虽然只有 16MB 。
以前的第三方 ROM 里，有一个叫乐蛙的 ROM ，默认还给了 32MB 的 Swap 。
印象中当时我手头的 Android 设备内存容量是：128MB 、256MB 。内部存储空间 4GB 、8GB 。
这个大小今天看起来小，不过在当时还算可以。

其他的系统我没怎么用过，那些长得太像原生 Android 的估计还真没有，而那些宣称“深度优化”的估计有。

iOS 早期版本有墓碑机制，虽然不是同一种东西，但其实理念比较相似。
iOS 会限制一个 APP 只能用系统总内存的 1/4 ，超过就干掉。如今也有，但是限制放得很宽，iPadOS 限制非常宽。

所以前台应用都用不到 Swap 。
后台应用的内存数据其实会保存到闪存上，切换时再加载到内存。

后来大家都有了内存压缩，于是内存压缩就成了主流了。

如今的各厂商的“内存扩展”背后的技术其实是 zRAM Writeback ，在 Android 上可以 root 之后用 Scene 4 看到。

@wanguorui123 内存碎片也不会延长 Swap 的时间，那些不能利用的内存空间实际上也不会访问到，不访问的页面都不会触发 Swap 。

只考虑当前的问题时，和内存泄漏可以一块讨论，它们都只是看起来大（向系统申请的内存多，用任务管理器看着大），实际用的小而已。

当前任务真正用的那部分实际有多大，才决定对性能的影响有多大。

@wanguorui123 内存泄漏的部分其实永远都只会在闪存里，平时看起来就像普通的文件一样。

既然是泄漏的内存，那就是程序没有办法访问或者有办法但代码逻辑里却不用的。
不读写这块内存，就不会发生缺页中断，不会发生换页操作。

我没有说换页不需要时间和电量，但是禁用 Swap 把应用杀了只会花费更多的时间（包括展示广告、用户操作的时间）和电量。

如果用户体验真的更好，这个帖子就不会存在了。

@wanguorui123 不会有那么夸张，原神占用的内存大小都没有 4GB……
如果 APP 真的占用了 4GB ，当前任务所需要的活跃内存也不会达到 4GB 。

还有大多数程序内存数据，除非是图片、音频等资源，其实都很容易压缩。其实可以设计成两级，先进入内存压缩，再进入闪存。

对于难压缩的数据（可以试着压缩开头的一小块，算一下压缩率）可以直接进闪存。

实际上不用等待 7~8 秒。如果真的要那么久，往往应用从头加载也会那么久……

@wanguorui123 不是 Swap 不耗电，只是凡事都需要对比，哪种方案更耗电。

如果内存不足以维持前台应用正常运行，那么其实已经完全没法用了，就像当年 iPhone 6 玩王者荣耀结算界面闪退，iPhone 8 玩原神玩一半闪退（ 1.0 版本还不给玩，1.1 给了）
这是更糟糕的用户体验……

这时候如果有 Swap 可以用，至少能维持应用正常运行。

如果只是用来存储后台应用，那么，内存不足的场景下（充足的时候就没有区别了），如果有 Swap ，应用的内存会存储到 SSD 里，如果没有，应用就会被杀掉。

有 Swap 的时候，当你切换回这个应用，系统只需要从硬盘里读取数据到内存中，然后一切状态都恢复了。程序本身不需要做任何初始化工作，约等于给所有应用都适配了状态恢复。

如果没有 Swap ，考虑当下现实情况，比如你切换到微信，却发现还需要看地球。
这时候应用还要额外做初始化工作，加载本地存储的持久化数据，创建各种对象，生成界面元素等等。此过程不但需要从硬盘读取数据，还需要做不少计算。完毕之后，用户还要操作 APP ，点开之前使用的界面。
耗电只会比有 Swap 的情况更多。

还有，你所谓的后台恢复机制，实际上也许和你想象中有出入。如果你想象中就像 Swap 那种样子，应用的内存全部保存起来，下次打开就会读取，那它还真不是这样。
iOS 6 之前没有这个东西，不过有墓碑机制。iOS 6 之后有个 UI 状态读取和恢复的 API ，但是其他应用数据都要自己保存。
后来苹果还改过这套 API 。后面我不做 iOS 开发了，不太熟悉……

其实并不是那种“整个 APP 数据完整保存下来”的机制。

只不过它可以缩短初始化的流程，能用之前的数据直接去创建应用界面和各种对象，还能让用户省去打开之前使用的界面的操作。让用户感觉“一点开应用就接着上次没看完，没用完的地方继续操作”，就像现在的 VSCode 、JetBrains IDE 那样。


最后，在 Android 上开启和关闭这玩意很简单，虽然代码实现不太一样，但是目的基本一样。我并没有发现它会造成可感知的续航缩短。比如开启之前我能用一天半，开了之后只能勉强用一天。实际上没这个现象。

Windows 11 + NVIDIA 显卡
有条件可以搭配一台 Steam Deck OLED