主 题：[开源]空载内存砍掉 75%，我把我的 SSH 工具 OxideTerm 用 Rust+GPUI 完全重写了
发 布 者：soleilune
标签分类： 技术
时 间：2026-07-21 14:17:29
内容预览：大家好，我是 OxideTerm 的作者。之前在 NS 发过几次帖，老读者可能还记得 1.4.2 那篇末尾提了一嘴「在往 GPUI 原生迁移，不知道什么时候能写完」。我现在写完了。2.0 正式发布。OxideTerm确实成为了原生软件。一、为什么换引擎——WebView 的上限到了Tauri 是个好东西，1.x 版本的功能也是实实在在跑通的。但随着终端能力越来越多，我逐渐碰到了 WebView 很难绕开的限制：功能可以继续加，渲染开销和底层可控性却很难再往前走。举几个当时让我头疼的具体场景：大日志刷屏：yes 或者 cat 一个大文件时，xterm.js 的 WebGL/Canvas 渲染、Rust 与 JavaScript 之间的数据传递会一起承受压力，终端 UI 容易掉帧浅色主题锯齿：xterm WebGL 渲染器在浅色背景下有渲染缺陷——不是配置问题，是底层就这样，我尝试过注入一些参数去优化，但是没用。空载 320MB 内存：一个终端工具吃掉这些，虽然能用，但总觉得不对。即使没有打开会话，WebView、DOM 和 JavaScript 运行时的固定开销依然存在继续局部优化当然还能挤出一些空间，但已经很难改变整体架构带来的固定成本。所以我做了一个决定：把整个应用重写，换成 GPUI。它是 Zed 编辑器使用的 Rust 原生 GPU UI 框架。新版不再使用 WebView 和 JavaScript UI 层，终端状态、界面组件与渲染逻辑都留在 Rust 这一侧。换完之后，macos空载内存从 320MB 左右降到了 80MB 出头，windows则从 182.4MB 下降到了 23.5MB. 我自己看了都觉得很夸张。这不是某一个参数调优的结果，而是移除 WebView、DOM 和 JavaScript 运行时之后，整体架构变化带来的结果，现在你可以用更低的内存来驱动
直达链接： https://www.nodeseek.com/post-831977-1
发 布 者：soleilune
标签分类： 技术
时 间：2026-07-21 14:17:29
内容预览：大家好，我是 OxideTerm 的作者。之前在 NS 发过几次帖，老读者可能还记得 1.4.2 那篇末尾提了一嘴「在往 GPUI 原生迁移，不知道什么时候能写完」。我现在写完了。2.0 正式发布。OxideTerm确实成为了原生软件。一、为什么换引擎——WebView 的上限到了Tauri 是个好东西，1.x 版本的功能也是实实在在跑通的。但随着终端能力越来越多，我逐渐碰到了 WebView 很难绕开的限制：功能可以继续加，渲染开销和底层可控性却很难再往前走。举几个当时让我头疼的具体场景：大日志刷屏：yes 或者 cat 一个大文件时，xterm.js 的 WebGL/Canvas 渲染、Rust 与 JavaScript 之间的数据传递会一起承受压力，终端 UI 容易掉帧浅色主题锯齿：xterm WebGL 渲染器在浅色背景下有渲染缺陷——不是配置问题，是底层就这样，我尝试过注入一些参数去优化，但是没用。空载 320MB 内存：一个终端工具吃掉这些，虽然能用，但总觉得不对。即使没有打开会话，WebView、DOM 和 JavaScript 运行时的固定开销依然存在继续局部优化当然还能挤出一些空间，但已经很难改变整体架构带来的固定成本。所以我做了一个决定：把整个应用重写，换成 GPUI。它是 Zed 编辑器使用的 Rust 原生 GPU UI 框架。新版不再使用 WebView 和 JavaScript UI 层，终端状态、界面组件与渲染逻辑都留在 Rust 这一侧。换完之后，macos空载内存从 320MB 左右降到了 80MB 出头，windows则从 182.4MB 下降到了 23.5MB. 我自己看了都觉得很夸张。这不是某一个参数调优的结果，而是移除 WebView、DOM 和 JavaScript 运行时之后，整体架构变化带来的结果，现在你可以用更低的内存来驱动
直达链接： https://www.nodeseek.com/post-831977-1
