@wxf666 估计哪里的内存没释放吧，其实你反复切换语言内存也会一直往上涨不会往下掉，这得跑 memory profiler 才能知道原因，数据结构好好设计一下的话是可以做的内存占用几乎维持刚启动时占用不变的，不过这是个随便写的 demo 无所谓了。
Avalonia 的话有个 80mb 左右的常数内存占用，再往上就看代码的算法和数据结构了，和框架本身关系倒不是很大。
notepad 那俩毕竟是下了大功夫优化了占用的 app 。

@wxf666 我的 tokenizer 没做虚拟化，你粘贴的代码文本是一次性全部进行高亮处理保存在内存里的，而不是只处理显示出来的那些代码。如果你想公平比较的话，建议只贴正好占一个窗口那么多的代码量。

@nikenidage1 Avalonia 官网确实没写。我姑且算是 Avalonia 项目的代码贡献者之一所以有了解到这些东西。

@wxf666 体积主要取决于开发者发布时有没有做代码裁减，默认不开，开了之后成品一般在 30mb 往上，不开的话 100mb 往上。
由于是 gpu 加速渲染，渲染后端走的 angle ，内存占用确实是 100mb+。如果关掉 gpu 渲染走软件渲染的话内存占用就只会有 30mb 左右。
至于那个 ui 设计软件，他们在内存里载入了自己的素材库和本地 ai 模型来辅助设计，内存占用自然比较大。

不过也没什么可说的，Avalonia 的体积就是 30mb 起步，启用 angle 后端做硬件加速渲染内存占用 100mb 起步，仅使用软件渲染内存占用 30mb 起步。

这里放两个拿 Avalonia 写的仿 vscode 的全功能代码编辑器，自带多种主题和多语言的代码高亮，一个是开启 gpu 渲染的 angle 版本，一个是采用软件渲染的 software 版本，并且采用了 nativeaot 编译，你可以试试:

gpu 加速渲染:
https://1drv.ms/u/s!ApWNk8G_rszRgrZ47r4LrTUlPupSRA?e=XcbR18

软件渲染:
https://1drv.ms/u/s!ApWNk8G_rszRgrZ5LOnqPDLtcKyrqA?e=C4AP86

@nikenidage1 Avalonia 11 的内存占用稍微大了一些其实是因为启用了新的 GPU 加速的合成渲染器，这个渲染器性能很好但是有一定的内存占用，虽然这部分内存占用其实不来自 Avalonia ，而是来自 ANGLE （一个 OpenGL ES 库）。
如果想要回归到原来的那种软件渲染可以在你的 Program.cs 的 BuildAvaloniaApp 函数里面加

```csharp
.With(new Win32PlatformOptions
{
RenderingMode = new[] { Win32RenderingMode.Software }
})
```

内存占用立即降到只有 30mb 左右。

Avalonia 11.0: https://github.com/AvaloniaUI/Avalonia

文档: https://avaloniaui.net/GettingStarted

对于你说的条件全部满足，写完之后采用 NativeAOT 编译即可达到双击立即启动的水平，并且不需要携带运行时。不过注意其中 macOS arm64 架构的 NativeAOT 需要用 .NET 8 的 sdk 。

像 Unity 、JetBrains 、GitHub 之类的厂商也都在用 Avalonia 。

谈可读性的前提是大家拥有相似的认知水平，认知水平相差太大就会导致一个人觉得很好读而另一个觉得不好读的情况发生。
比如你对一个熟悉函数式语言的人讲使用 pattern matching 有助于提升可读性，他大概率会同意你的观点；而你对一个跟没有怎么接触过函数式语言的人讲这件事情，他大概率觉得你在胡扯，而反倒觉得尽可能使用基础的控制流语句才是提升可读性的方法。

之前用过官方的 rabbitmq 库，个人感觉还挺好用的，而且性能上也做得很好。
https://github.com/rabbitmq/rabbitmq-dotnet-client

推荐 Avalonia (11.0 版本)，跨平台并且原生支持 GPU 加速，还支持 nativeaot 编译出原生二进制代码。

@arfaWong 那是 Google ANGLE 的 dll ，虽然可以静态链接进去但是作者没这么做。

@hez2010 忘记贴地址了: https://github.com/bflattened/bflat

要不试试 bflat ，go 工具链体验版本的 c#，默认就是 nativeaot ，既具备交叉编译同时类库还比 go 丰富得多，出来的体积还比 go 更小。
既然是命令行工具那也就没有什么所谓的 nativeaot 限制，基本想咋用就咋用。
其实就算是 gui 应用你拿 avalonia 写照样不存在限制，人家原生就支持 nativeaot 。

如果是 Windows 应用开发的话建议首选 WinUI 3 ，既能遵守平台原生设计风格，对系统各种 API 调用也更方便。
如果需要跨平台的话可以用 Avalonia （指 11.0 版本），这几乎是除了 UWP/WinUI 之外唯一一个实现了渲染合成分离架构渲染器的 GUI 框架，可以确保无论什么时候都能有流畅的动画，还能通过 Native AOT 编译直接输出原生二进制。
当然开发 Windows 应用也可以用 Avalonia ，可以把主题从自带的那个换成 FluentAvalonia 的包就有完整的 Win 11 Fluent Design 样式了，并且就算带了这个样式也还是跨平台的。

@diagnostics 在电池设置里有个优化选项。

你需要自己在系统设置里把你需要的 app 设置成不优化后台进程。不然某些国产系统白名单做的不好就会给你随便杀进程。

很简单，因为 nuget 客户端本身就是用来操作上游包仓库的客户端。
你要是想找包管理器的话，那你需要的不是那个 nuget.exe ，而是 dotnet add package/dotnet remove package ，以及 dotnet nuget 命令。

@hez2010 说的不太对，间接引用也算。应该说只要使用了 GPL 的代码（无论是代码层面的使用，还是因为静态链接导致的二进制层面的使用）都算。
动态链接的话不算。

直接引用 /修改了 GPL 代码或者静态链接了从 GPL 代码编译出来的东西都需要遵守 GPL 代码开源。
除此之外的话就看代码作者自己要不要求你开源了。