抛弃 Electron!自研 C# UI 引擎XchyUI,内核仅 200KB,秒杀 Web 套壳!

抛弃 Electron!自研 C# UI 引擎XchyUI,内核仅 200KB,秒杀 Web 套壳!

6 年磨一剑!纯 C# 全自研轻量 UI 引擎|内核 < 200KB + .NET8 AOT 跨平台 + 百万数据 60fps

大家好,这是我利用6 年业余时间,历经无数次推翻重构,全链路自研的纯 C# 用户态跨平台 UI 引擎,今天第一次公开分享。

引擎的演进之路:从 WinForms + GDI 起步 → 多次架构重构 → 最终定型 GLFW + SkiaSharp深度融合业界三大核心思想:

  • Android View 绘制流程
  • Jetpack Compose 函数式组合编程
  • Flutter 渲染优化理念

当前PC客户端开发,大多基于以下技术体系: • .NET 官方框架:WinForms / WPF / WinUI / .NET MAUI • 开源跨平台方案:Avalonia • Web 套壳技术:Electron / Tauri • C++ 原生框架:Qt
绝大多数开发者与企业,都选择在这些成熟框架之上做二次封装、组件扩展,以此快速实现业务需求。
真正愿意从源头开始,全链路自研一整套UI引擎的开发者少之又少

而我的这套引擎,正是从0到1完全自研
渲染管线、视图布局系统、动画调度、虚拟滚动、事件分发、主题体系、状态管理,全部自主实现,形成全链路闭环
可满足 90% 以上的桌面客户端UI需求,复杂绘图可直接对接底层Skia渲染,生成绘制指令并提交GPU执行。

框架设计追求极简与高效:
• 单线程架构 + 对象复用机制,大幅降低GC压力
• 元素结构无冗余设计,内存占用极低
• 函数式组合编程 + 状态驱动界面重组
• 组件树一次声明、多处复用
• 业务逻辑与UI结构高度内聚,不分散
• 思想贴近 React / Flutter / Jetpack Compose,现代前端/移动端开发者可快速上手

与传统XML、重量级框架不同,本引擎坚持 小而精 的设计理念:
只提供最基础的原子组件,所有复杂组件(DataGrid、TreeView、图表、卡片等)均通过基础组件积木式组合实现。
框架不提供冗余、不内置臃肿组件,保持最轻量、最灵活、最可定制的核心优势。

全程无黑盒、无深度封装、无Web套壳、无浏览器内核,回归原生渲染本质。


引擎开发历程(真实走心)

从最初基于 WinForms + GDI 摸索渲染与布局,到中间数次因性能、架构、扩展性不足彻底推翻重构,再到最终选择 GLFW + SkiaSharp 构建跨平台渲染底座,6 年间不断打磨架构、优化渲染、精简内核。

最终沉淀出这套:极轻量、高性能、跨平台、纯 C# 用户态的 UI 引擎。每一行核心代码都经过反复推敲与验证。


引擎核心亮点

  • 纯 C# 用户态实现,Release 核心 DLL < 200KB
  • 函数组合式 API + 状态对象驱动界面重组
  • 自研无 Timer 高性能动画系统
  • 完整 View 布局系统:Row/Column/Flow/ 虚拟滚动容器
  • 百万级数据列表轻松稳定 60fps+
  • 自研渲染管线 + 脏矩形局部刷新
  • 底层对象池复用:SKPaint/SKFont/SKBitmap 全复用
  • 窗口对接 Silk.NET.GLFW,渲染基于 SkiaSharp
  • 支持 .NET8 AOT 原生发布
  • 已验证:Windows / Ubuntu,macOS 理论 100% 支持
  • 插拔式架构,可快速对接其他平台与渲染器

基础组件 & 扩展能力

内置基础组件:Text/Input/Icon/Row/Column/Flow/LazyRow/LazyColumn/LazyGrid/PopupCard

复杂组件如 DataGrid、TreeView、图表等,均可通过基础组件积木式组合实现,无需重写底层。

已实现 Demo

  • 百万数据高性能虚拟滚动列表
  • 仿微信 PC 端主界面
  • 饼图 / 柱状图 / 折线图 / 仪表盘
在这里插入图片描述


在这里插入图片描述


在这里插入图片描述


在这里插入图片描述

极简示例代码

ContentView(() => { // 垂直布局 Column(() => { // 响应式状态 var counterNum = StateValueOf(0); Text() .H3() .Binding(counterNum, (builder, num) => { builder.TextValue($"计数器:{num}"); }, true); // 无Timer循环动画 var visibleState = StateValueOf(true); var animateValue = AnimateFloatOf(visibleState, animate => { animate.Duration = 800; animate.Times = int.MaxValue; animate.Delay = 200; animate.Interpolator = XAnimationInterpolator.Uniform; }); Icon(SvgResources.CircleProgress) .Size(32) .Binding(animateValue, (builder, value) => builder.Rotate(value * 360) ); // 点击交互 Text("点击增加计数") .PrimaryButton() .Click(() => counterNum.Value++); }) .Size(WRAP) .Space(10); }); 
在这里插入图片描述

🚀 Demo 运行包(AOT 原生编译,开箱即用)

  • 提供 AOT 编译原生 exe,解压直接运行
    -[ ](通过网盘分享的文件:numdemo.zip
    链接: https://pan.baidu.com/s/1aEIAR4YdS2Blt9oVgPAjHA 提取码: hg4d)
  • 体积:exe + 非托管库共 24MB引擎自身 <200KB,体积来自 .NET 运行时 + Skia + GLFW
  • 运行系统要求
    • Windows 需 Win10 及以上(因 .NET8 AOT 最低支持 Win10)
    • Ubuntu 20.04 / 22.04 已验证
  • 首次启动稍慢:磁盘缓存 + GL 上下文 + Skia 初始化二次启动秒开,属原生渲染程序正常现象

关于 AI 是否会替代

AI 可以快速生成页面业务代码,但无法自研底层引擎。渲染管线、布局算法、虚拟滚动、脏矩形刷新、动画调度、内存池、深度性能优化……这些底层架构与多年沉淀的核心技术,才是真正壁垒,只会越来越稀缺。


后续计划

本项目为 6 年全自研成果,首次公开分享。如果关注和感兴趣的朋友较多,我会逐步开放:

  • 使用文档 & 开发教程
  • 函数式 UI 编写指南
  • 底层技术原理讲解(布局、渲染、动画、虚拟滚动)
  • 架构设计与性能优化细节
  • 开源 / 社区共建计划

欢迎交流,感谢支持!

Read more

Meta-Llama-3-8B-Instruct性能对比:不同量化方式

Meta-Llama-3-8B-Instruct性能对比:不同量化方式 1. 引言 随着大语言模型在消费级硬件上的部署需求日益增长,如何在保持推理质量的同时降低显存占用和提升推理速度,成为工程落地的关键挑战。Meta-Llama-3-8B-Instruct 作为 Llama 3 系列中兼顾性能与效率的中等规模模型,凭借其 80 亿参数、支持 8k 上下文以及出色的指令遵循能力,成为单卡部署的理想选择之一。 然而,原始 FP16 模型约需 16 GB 显存,仍超出多数消费级 GPU 的承载能力。因此,量化技术成为释放其潜力的核心手段。本文将系统性地对比 GPTQ-INT4、AWQ、GGUF(Q4_K_M)等多种主流量化方案在 vLLM 与 llama.cpp 等推理框架下的表现,涵盖显存占用、推理速度、输出质量三大维度,并结合 Open WebUI

React Native智能家居摄像头模块深度解析:直播、回放与告警的技术实现

在智能家居应用开发中,摄像头模块往往是功能最复杂、技术挑战最大的部分之一。本文将通过深入分析三个核心文件:CameraHome.js(实时直播)、CameraRecordNew.js(录像回放)和EventAlarmPageNew.js(事件告警),揭示一个成熟智能家居摄像头模块的技术架构与实现细节。 一、CameraHome.js - 摄像头直播控制中心 1. 主要功能全景 CameraHome.js作为摄像头的主控制界面,实现了全方位的设备管理功能: * 实时视频流处理:支持高清/标清双流切换、播放控制(播放/暂停/停止) * 高级云台控制:8方向转动、边界智能检测、6个预设视角管理 * 音视频交互:双向语音通话、麦克风与扬声器控制 * 智能场景模式:夜视模式、隐私模式、遮蔽模式一键切换 * 多存储状态监控:实时显示SD卡、云存储、NAS的使用状态 * 告警即时预览:今日告警数量统计、最新告警事件展示 2.

GLM-4-9B-Chat-1M环境部署:Transformers/vLLM/llama.cpp三推理框架对比选型

GLM-4-9B-Chat-1M环境部署:Transformers/vLLM/llama.cpp三推理框架对比选型 想象一下,你手头有一份300页的PDF合同,或者一整年的公司财报,你想让AI帮你快速总结要点、提取关键信息,甚至回答基于这份长文档的复杂问题。过去,这几乎不可能——模型要么读不完,要么读完就“失忆”,要么需要昂贵的多卡集群。 现在,情况变了。智谱AI开源的GLM-4-9B-Chat-1M模型,直接把上下文长度拉到了惊人的100万token,相当于一次性能读完200万汉字。更关键的是,它只需要一张24GB显存的消费级显卡(比如RTX 3090/4090)就能跑起来。 模型有了,怎么把它用起来?这就是我们今天要解决的问题。市面上主流的推理框架有好几个:Transformers、vLLM、llama.cpp,它们各有各的脾气和特长。选错了,你可能面对的是缓慢的推理速度、爆满的显存,或者复杂的部署流程。 这篇文章,我就带你亲手部署GLM-4-9B-Chat-1M,并横向对比这三个框架。我会告诉你,在什么硬件条件下,为了什么目的,应该选哪一个。目标很简单:让你用最少的折腾,

信号处理仿真:图像信号处理_(10).图像信号处理的硬件实现

信号处理仿真:图像信号处理_(10).图像信号处理的硬件实现

图像信号处理的硬件实现 在图像信号处理领域,硬件实现是将图像处理算法转换为物理设备的关键步骤。硬件实现可以显著提高处理速度和效率,特别是在实时处理和大规模数据处理中。本节将详细探讨图像信号处理的硬件实现原理和技术,包括常见的硬件平台、设计流程、性能优化方法等。 常见的硬件平台 1. FPGA(Field-Programmable Gate Array) FPGA 是一种可编程逻辑器件,可以在用户定义的硬件设计中实现复杂的数字逻辑功能。FPGA 的主要优点是并行处理能力和低延迟,适用于实时图像处理任务。 原理 FPGA 通过硬件描述语言(如 VHDL 或 Verilog)设计逻辑功能。用户可以在 FPGA 上实现自定义的数字信号处理算法,这些算法可以直接映射到硬件资源,从而实现高效的并行处理。 设计流程 1. 需求分析:确定图像处理任务的具体需求,包括输入输出格式、处理速度、资源限制等。 2. 算法设计:选择合适的图像处理算法,并进行数学建模。 3. 硬件描述:使用 VHDL 或