从 2026 年 3 月 1 日开源，到 26.10.9：Jalium UI 半年时间到底走了多远？

2026 年 3 月 1 日，Jalium UI 正式开源。

那一天，如果只是打开仓库看看，可能很难想到，半年之后，它会变成今天这个样子。

到了 2026 年 8 月 28 日，Jalium UI 26.10.9 正式发布。

从时间上看，不过半年。

从版本号看，也只是在 26.9.x、26.10.x 之间不断往前走。

但如果真正把这段时间的 Release 一个个翻下来，会发现这根本不是简单的"持续加功能"。

更像是在半年时间里，快速经历了一遍一个 UI 框架从"能工作"，到"开始像框架"，再到"开始处理真正复杂问题"的过程。

而且这个过程很有意思。

因为 Jalium UI 并没有一直朝着"功能越多越好"的方向跑。

它一路在重新调整自己的底层。

渲染。

布局。

文本。

输入。

虚拟化。

JALXAML。

AOT。

Native。

跨平台。

开发工具。

甚至连依赖关系和架构选择都经历过反复。

所以这一次，我不想单独聊 26.10.9。

我更想把 2026 年 3 月 1 日到 26.10.9 这条时间线完整串起来。

看看 Jalium UI 到底是怎么一步一步走到今天的。

一、先把时间线摆出来

从公开 Tags 和 Releases 来看，Jalium UI 这半年的版本演进大致可以分成几个阶段。3 月进入 26.9.x；4 月 17 日发布 26.10.0；之后分别在 4 月 23 日、4 月 28 日、5 月 23/25 日、6 月 6 日、6 月 29 日、7 月 16 日、7 月 30 日和 8 月 28 日持续推进，到目前最新的 26.10.9。

可以把这一路理解成：

时间	版本	更像是在解决什么
3 月	26.9.x	从项目走向真正的 UI 框架
3 月 27 日	26.9.6	Razor、GPU、软件渲染、媒体、拖放开始成体系
3 月 30 日	26.9.7 / 26.9.8	Window、输入、触控、绑定、JALXAML、Vello
3 月 31 日	26.9.9	TreeDataGrid、Razor 解释器、Docking、窗口体系进一步完善
4 月 17 日	26.10.0	第一次真正意义上的"大版本能力汇合"
4 月 23 日	26.10.1	retained rendering、DevTools、XmlnsDefinition、GPU 统计
4 月 28 日	26.10.2	NativeAOT、AOT-safe XAML、Vulkan 根因级优化
5 月 23 日	26.10.3	文本、媒体、WPF 补齐、编译期能力大幅扩张
5 月 25 日	26.10.4	根据实际使用反馈重新收敛架构
6 月 6 日	26.10.5	渲染缓存、动画、DevTools、ARM64、动态图像
6 月 29 日	26.10.6	百万级虚拟化、GPU parity、DevTools 虚拟化
7 月 16 日	26.10.7	启动、生命周期、NativeAOT、Linux、稳定性
7 月 30 日	26.10.8	布局、滚动、Retained Rendering、跨平台打包
8 月 28 日	26.10.9	CommonMark、@virtualize、图片管线、渲染正确性与性能

这些数字放在一起看，其实已经很有冲击力。

半年。

十几个版本节点。

而且每一次都不是简单改个版本号。

二、3 月：Jalium UI 还只是一个名字，但已经开始显露野心

Jalium UI 于 2026 年 3 月 1 日开源。

而到 3 月下旬，版本线很快进入了 26.9.x。

这里有一个特别值得注意的地方：

它非常早就开始碰 UI 框架最难的地方。

不是先做一个 Button，再做几个页面，然后开始写 Gallery。

而是很快进入：

GPU。

Native。

Razor。

文本。

布局。

输入。

媒体。

AOT。

这些领域。

三、26.9.6：第一次让人看出，这不是普通控件库

3 月 27 日的 26.9.6，是一个非常关键的节点。

这一版一下子往多个方向推进。

首先是 Razor。

开始出现：

RazorCodeBlockPreprocessor
RazorExpressionCompiler
RazorDependencyAnalyzer
RazorTemplateParser

以及轻量级依赖分析器。

也就是说，JALXAML 开始真正拥有自己的 Razor 能力，而不是停留在"XML 里面塞一点表达式"。

然后是 D3D12。

26.9.6 已经有完整的 Direct Renderer，包含 GPU Render Pipeline、字形图集、路径三角剖分、Shader 等。

同时，它第一次把：

Software Rendering Backend

正式摆了出来。

这件事情其实很重要。

因为一个 GPU UI 框架如果只有 GPU 路径，一旦硬件或驱动出问题，整个 UI 就可能跟着一起倒。

软件后端意味着：

至少框架开始认真考虑"没有 GPU 怎么办"。

除此之外，还有 Shader Effects、MediaElement、Windows 拖放、GPU Interop、控件主题、Debug HUD 等。

这一版有一种很明显的感觉：

Jalium UI 开始从"UI Demo"向"Framework"移动。

四、26.9.7 和 26.9.8：开始补"桌面软件"的骨架

3 月 30 日，26.9.7 和 26.9.8 接连出现。

这两版最明显的一个变化，是：

Window 不再只是一个能显示内容的容器。

开始有：

Left
Top
WindowStartupLocation
RestoreBounds
Owner
OwnedWindows
ShowInTaskbar
ShowActivated
AllowsTransparency

以及完整的窗口生命周期事件。

这其实是很关键的一步。

因为如果一个框架想做真正的桌面软件，它迟早要面对：

主窗口。

子窗口。

模态窗口。

拥有关系。

窗口状态。

DPI。

焦点。

系统菜单。

窗口生命周期。

Jalium UI 到这里，才开始真正拥有"桌面应用"的味道。

与此同时，26.9.7/26.9.8 还继续强化了：

Touch。

InkCanvas。

DirectWrite 文本命中测试。

VirtualizingStackPanel。

JALXAML 编译。

DataContext 继承。

PropertyAccessorRegistry。

Vello GPU 路径。

以及 TreeDataGrid。

五、26.9.9：第一次真正把"开发者体验"和"框架能力"放在一起

3 月 31 日，26.9.9 发布。

这一版非常有意思。

因为它开始把很多原本分散的东西串起来。

出现了：

TreeDataGrid。

新的 Cursor 系统。

Razor Lightweight Interpreter。

Razor Section Host。

PropertyAccessorRegistry。

DevTools 延迟树构建。

Docking 系统完善。

文档模型增强。

逐角圆角。

过渡 Shader。

OuterGlow / InnerShadow。

Window 管理。

InkCanvas 多点触控。

数据绑定。

JALXAML 构建。

Vello GPU 路径渲染。

尤其是 Vello。

这一版直接把旧的 D3D12 Pipeline 大块迁移到了新的 GPU 路径体系。

这意味着 Jalium UI 已经不是单纯在"调用 GPU"。

而是在建立自己的 GPU 渲染架构。

六、4 月 17 日：26.10.0 是一个分水岭

真正的分水岭，是 26.10.0。

GitHub Release 明确把它定义为从 26.9.9 以来的一次重大升级。

这一版有几个变化非常重要。

第一件事：双 GPU 渲染引擎

Jalium UI 同时引入：

Vello

和

Impeller

两套渲染引擎。

同时支持运行时选择与 Auto 模式，并覆盖 D3D12 和 Vulkan。

这一刻开始，Jalium UI 的"GPU 加速"不再只是 README 里的一句话。

它已经变成真正的架构。

七、26.10.0 做的第二件大事：ClearType

桌面 UI 很容易被忽略的一件事情就是文字。

但 Jalium UI 选择直接把 ClearType 子像素文本渲染做进去了。

基于 dual-source blending。

GPU 与 CPU 都有对应路径。

这件事其实很能说明作者的取舍。

它没有只追求：

"GPU 跑起来。"

而是开始追求：

GPU 跑起来以后，文字还得像桌面文字。

对一个真正的桌面框架来说，这比很多视觉特效都重要。

八、26.10.0 还第一次真正跨出 Windows

Android 原生构建支持正式进入版本。

Jalium.UI.Android

和

Jalium.UI.Desktop

开始有明确的独立打包体系。

同时 Vulkan Backend 也开始在 Windows 上承担真正的角色。

而且官方给出的 Vulkan Gallery 性能数据非常夸张：

Render 从约 118 ms

下降到约 13 ms

总帧时间从 91 ms

下降到约 17 ms

稳定帧率从约 6 FPS

提升到 60 FPS。

RenderText 热路径也从约 1.434 ms/次 降到约 0.001 ms/次。

这已经不是"小优化"。

这是一次架构层面的修正。

九、4 月 23 日：26.10.1 开始解决"框架怎么被别人使用"

26.10.1 开始，Jalium UI 的重点慢慢从底层渲染扩展到框架工程体验。

这一版带来了：

Retained-Mode rendering cache。

AppBuilder + DevTools 服务化。

XmlnsDefinition。

TextEffectPresenter。

GPU 统计。

Windows Vulkan Backend。

以及一轮大规模 WPF namespace 对齐。

这意味着 Jalium UI 开始非常在意另外一件事情：

开发者最终拿到的 API，到底好不好用。

十、26.10.2：AOT 开始成为 Jalium UI 的真正一等公民

4 月 28 日，26.10.2 发布。

这版是我认为整个版本历史里非常关键的一版。

因为它第一次把：

NativeAOT

真正放到了框架核心位置。

官方加入了单 exe NativeAOT 发布路径。

可以通过：

<PropertyGroup>
    <PublishAot>true</PublishAot>
    <UseJaliumNativeAot>true</UseJaliumNativeAot>
</PropertyGroup>

走静态 Native 路径，最终产出不依赖 jalium.native.*.dll 副本的自包含 EXE。

同时 WebView2 也可以走静态链接。

XAML 整条管线开始进行 AOT-safe 改造。

这说明 Jalium UI 开始真正思考：

不是"程序能运行"就够了。

而是：

发布以后，能不能干净、稳定、尽可能少依赖地运行？

这是框架走向成熟的一个非常重要的信号。

十一、26.10.3：把 WPF 时代留下来的细节，一点一点捡起来

5 月 23 日的 26.10.3，可以说是一个非常"硬核"的版本。

它开始补：

TextBox.CharacterCasing
MinLines
MaxLines
ComboBox.StaysOpenOnEdit
DataGrid.FrozenColumnCount

3D Animation。

Printing。

WindowsFormsHost。

同时把：

Razor 表达式。

自定义 xmlns。

Binding。

SourceGenerator。

文本渲染。

Grapheme Cluster。

多编码文件 IO。

全部往前推了一大截。

尤其是 Emoji。

这一版开始真正考虑 Unicode grapheme cluster。

也就是说：

👨‍👩‍👧‍👦

对于用户来说应该是一个整体。

编辑器的光标、删除、选择，不应该从中间硬生生切断。

这类细节，平时没人会夸。

但真正用起来，一旦做错，用户立刻就知道。

十二、然后发生了一件很有意思的事情：26.10.4 "回头了"

这是我觉得 Jalium UI 这段历史里特别有人情味的一件事情。

26.10.3 曾经做了一套自己的：

Jalium.Extensions.Hosting
Jalium.Extensions.DependencyInjection
Jalium.Extensions.Configuration

等等。

但到了 26.10.4，作者又把这一整套撤回。

重新恢复：

Microsoft.Extensions.Hosting

以及标准的 Microsoft.Extensions 体系。

原因也说得非常直白：

自研扩展虽然看起来很漂亮，但会带来生态兼容性问题:一方面，开发者熟悉的Microsoft.Extensions生态无法直接复用;另一方面,在keyedservices、OptionsBuilder、ConfigurationBinder等方面也难以与官方实现保持一致,容易造成 API行为差异和迁移成本，最终增加框架自身的维护负担。

所以最终选择：

退回标准答案。

这其实是一件挺难得的事情。

很多项目最怕承认：

"我之前这个决定可能不太对。"

但框架开发本身就是不断试。

试了以后发现不合适，就回来。

我反而觉得这是 Jalium UI 很真实的一面。

它不是从一开始就知道所有答案。

它也在边写边找。

十三、26.10.4：触控、手势、原生视频真正进来了

5 月 25 日的 26.10.4，又把重点拉回到用户交互。

Touch。

Manipulation。

RTS。

GestureRecognizer。

真实物理 inertia。

Pinch。

Flick。

DoubleTap。

TwoFingerTap。

Stylus。

全部开始形成完整输入闭环。

与此同时：

NativeVideoSurface

开始进入 D3D12 + Vulkan 的 GPU 视频路径。

音频管线也继续完善。

这时候的 Jalium UI 已经越来越不像"桌面 XAML 框架"。

它开始具备：

真正现代应用框架

的轮廓。

十四、26.10.5：重点从"能不能画"，变成"能不能高效地一直画"

6 月 6 日，26.10.5。

这一版最大的变化，我认为是 Retained Rendering。

D3D12 GPU retained layers。

Damage-driven invalidation。

Glyph Atlas。

Text Cache。

Impeller emit coalescing。

Vulkan Ink Layer。

Runtime HLSL → SPIR-V Shader Compiler。

这些东西背后的共同目标只有一个：

少做重复工作。

比如一个动画正在运行。

如果每一帧都把整棵 Visual Tree 重新绘制一遍，当然会慢。

Retained Layer 的意义，就是：

那些没变化的东西，不需要重新来。

这时候 Jalium UI 的渲染思维已经开始从：

"把东西画出来。"

慢慢走向：

"只画真正发生变化的东西。"

十五、26.10.5 还有两个非常现实的进步

第一，GIF、APNG、Animated WebP 开始直接接入：

Image.Source

不需要额外控制器就可以逐帧播放。

第二：

Windows ARM64

正式进入 runtime 支持。

所以到这里，Jalium UI 的平台故事又往前走了一步。

十六、26.10.6：一个百万行列表，终于开始认真挑战它

6 月 29 日的 26.10.6，我认为是 Jalium UI 在"极限规模 UI"上的一次试探。

这一版开始直接面对：

百万级列表。

不是几千条。

不是几万条。

而是：

Million-row virtualization。

这里有一个很漂亮的工程细节。

累计偏移不能一直用 float。

因为数据量足够大以后，float 的 24-bit mantissa 会产生明显量化误差。

官方指出，在约 4000 万像素附近，float 的累计 offset 可能量化到 4px 的粒度，最终形成大块空白带。

于是最终选择：

item height 可以继续 float，但 cumulative offsets 使用 double。

这种修改特别像真正的软件工程。

不是为了宣传。

纯粹就是：

"到这个数据量以后，真的出 bug 了。"

然后解决它。

十七、26.10.6 还解决了 DevTools 自己把自己拖死的问题

这个非常有意思。

开发工具自己也是一个 UI。

如果 Inspector 要查看非常大的 Visual Tree，却把整棵树全部实现出来，那么：

开发工具自己先卡死。

所以 26.10.6 把 Inspector Tree 改成 Virtualized Flat List。

只实现屏幕上看得到的节点。

这其实是一种很有意思的递归：

框架用虚拟化解决业务 UI，也用虚拟化解决自己的 DevTools。

这才算把这套技术真正吃进去了。

十八、26.10.7：开始处理那些最烦人的问题------启动、生命周期和跨平台

7 月 16 日，26.10.7 发布。

这一版的关键词非常朴素：

Startup。

Lifecycle。

Rendering parity。

Linux packaging。

NativeAOT。

没有特别花哨。

但其实非常重要。

一个框架做到这个阶段之后，最怕的已经不是：

"少一个控件。"

而是：

程序到底能不能正常启动？

有没有窗口？

后台服务会不会把 UI 卡死？

Android 会不会启动失败？

NativeAOT 会不会出问题？

Linux 不同 libc 会不会炸？

26.10.7 就是在处理这些真正决定用户能不能用的问题。

甚至还提供了 Android、Linux、Windows 的 NativeAOT Gallery 构建产物，并做了启动、ABI、资源、PE、ELF 等验证。

十九、26.10.8：开始进入"稳定框架应该有的样子"

7 月 30 日，26.10.8 发布。

官方自己给它的定位非常准确：

layout、scrolling、retained-rendering、runtime-hardening、cross-platform packaging release。

这一版集中处理：

Grid。

StackPanel。

WrapPanel。

ScrollViewer。

Scrollbar。

Popup。

Window。

Virtualization。

Retained Layers。

Dirty Region。

DPI text。

Glyph Atlas。

Liquid Glass。

Device Loss。

Resize Recovery。

Linux packaging。

Android activity/input/keyboard。

等等。

这时候你会发现：

Jalium UI 的开发重心已经发生变化。

前面是在：

"我要有什么。"

后面逐渐变成：

"我已经有了，那我要怎么让它可靠？"

这是一个很重要的分界线。

二十、然后来到 26.10.9

8 月 28 日。

最新版本。

Jalium UI 26.10.9。

这一版官方自己定义得很明确：

Large correctness and performance release。

而且它不是一个孤立版本。

是三个大型改动合并后的结果：

#170

#171

#172。

二十一、第一件事：JALXAML 的 @virtualize

这可能是 26.10.9 最值得普通开发者关注的能力。

以前：

@foreach (var row in Rows)
{
    ...
}

会在加载期间把所有元素都展开。

数据多了，就意味着：

对象多。

布局多。

内存多。

渲染压力也跟着上去。

现在可以：

@virtualize(var row in Rows)
{
    <Border Height="44">
        ...
    </Border>
}

语法还是很像 Razor。

但底层已经变成虚拟化 items host。

只把真正需要的内容实现出来。

这实际上把：

Razor 的开发体验

和

大型数据列表的性能需求

放到了一起。

我觉得这是 Jalium UI 很有代表性的一个设计。

它没有告诉开发者：

"你要学另外一个 Virtualizing API。"

而是尽可能让开发者继续写自己熟悉的东西。

然后框架自己负责聪明起来。

二十二、第二件事：Markdown 终于开始认真对待 Markdown

26.10.9 引入了真正的 CommonMark inline parser。

之前的 Inline Pass 使用的是比较简单的扫描方式。

结果像：

snake_case

这种普通标识符都可能被错误处理成 emphasis。

图片语法也没有真正完成。

Link title 还可能丢失。

这一次直接重写为 delimiter stack 模型。

而且 Markdown Block 开始真正由控件承载。

每一个 Markdown Block 可以拥有自己的 Template 和 Theme Brush。

这就意味着：

Markdown 不再只是一个文本解析器。

而是开始真正成为 Jalium UI 的一部分。

二十三、第三件事：图片终于得到了一条像样的异步管线

以前图片异步解码遇到过一种非常让人抓狂的问题：

图片可能永久白屏。

或者 DPI 缩放之后不断请求一个永远满足不了的 bucket。

然后不断重新 decode。

26.10.9 对这条链路进行了重做。

加入：

Bounded Worker Pool。

Watchdog。

Completion Notifier。

同时增加：

ImageDiagnostics

把图片生命周期各阶段通过 Trace / EventSource 暴露出来。

这件事情说实话一点都不"炫"。

但非常重要。

因为成熟框架最重要的事情之一，就是：

出问题以后，你得知道它为什么出问题。

二十四、26.10.9 对 GPU 的修复，也开始非常深入

这一版继续处理：

抗锯齿路径统一。

Gradient 在 Pixel Shader 计算。

Rect Shadow GPU 计算。

Scissor 像素对齐。

Path Mode 状态恢复。

Vulkan Clear。

Backdrop Material。

Gaussian Blur。

Pipeline State Fence 回收。

圆形线帽重复绘制等问题。

这些已经完全进入渲染器内部。

这意味着 Jalium UI 现在讨论的已经不是：

"有没有 GPU"。

而是：

这张 GPU Pipeline 到底是不是正确、高效、可预测。

这是完全不同的阶段。

二十五、SVG 也从"支持"走向"认真支持"

26.10.9 修正了一批 SVG 问题。

比如：

根节点上的 presentation inheritance。

<use> 递归保护。

百分比长度计算。

Per-pixel gradient。

Software dashing。

.svgz。

Malformed path。

Software Rasterizer。

这里甚至修到了 Lucide 这类常见 SVG 图标的兼容问题。

这个细节很重要。

因为一个 UI 框架最终不是生活在自己的 Demo 里。

它必须面对外面的世界。

别人给你的 SVG，不会按照你的理想格式来写。

别人给你的字体，也不会。

别人给你的图片，也不会。

真正的框架，最终就是在这些"不配合"的输入里一点一点长出来的。

二十六、Popup、Layout、Selector，也终于开始处理那些让开发者抓狂的小问题

26.10.9 里还修掉了很多看起来很小、用起来却特别烦的问题。

Popup 靠近屏幕边缘闪烁。

Popup 打开后拖动窗口被阻塞。

ScrollViewer Infinity measure 触发跨帧无限布局。

Selector 两向 Binding 在容器重新生成后失效。

Template / page swap 后焦点失效。

这些问题都进行了对应修复。

这就是我为什么一直觉得：

26.10.9 更像一次"框架打磨"。

它没有疯狂往上堆更多 API。

而是在把已经有的能力，一点一点变得更可靠。

二十七、回头看这半年，Jalium UI 到底改变了什么？

如果把所有版本放在一起看，我觉得可以把这段时间分成四个阶段。

第一阶段：先把框架做出来

3 月。

Razor。

GPU。

Window。

Input。

Media。

Binding。

Native。

这一阶段的关键词是：

"有。"

第二阶段：让它真正成为桌面框架

4 月。

Vello。

Impeller。

ClearType。

Vulkan。

Android。

UIA。

Retained Rendering。

NativeAOT。

这一阶段开始解决：

"像不像一个真正的桌面 UI 框架？"

第三阶段：把复杂场景啃下来

5 月、6 月。

Touch。

Gesture。

Video。

Audio。

Grapheme。

百万级 Virtualization。

DevTools Virtualization。

ARM64。

Linux。

这一阶段开始解决：

"真正复杂的软件能不能用？"

第四阶段：开始打磨框架的脾气

7 月、8 月。

Startup。

Lifecycle。

Layout。

Dirty Region。

SVG。

Markdown。

Theme。

Image Pipeline。

Dependency Property。

@virtualize。

这一阶段解决的是：

"能不能用得舒服？"

二十八、最让我觉得有意思的，其实不是版本号

很多开源项目都有一个问题。

发布的时候：

"新增 20 个功能。"

下一版：

"新增 30 个功能。"

再下一版：

"新增 50 个功能。"

最后 README 看起来越来越强。

但真正用起来，还是一堆问题。

Jalium UI 现在让我比较关注的地方，恰恰相反。

它的 Release Notes 里有大量内容甚至没那么"漂亮"。

什么：

Fence。

Cache。

Scissor。

Rasterizer。

DPI。

Offset。

Text Cache。

Layout Loop。

ABI。

GDI Pool。

SourceGenerator。

NativeAOT。

ResourceDictionary。

这些词可能不会让普通人激动。

但它们特别像真正的框架工程。

因为框架最终就是死在这些地方。

二十九、从 3 月 1 日到 26.10.9，最大的变化其实只有一句话

Jalium UI 已经从"我能画 UI"，走到了"我要成为 UI 的基础设施"。

最开始，它需要证明：

我能创建窗口。

我能画控件。

我有 GPU。

我有 JALXAML。

到了后面，它开始考虑：

我的文本准不准？

我的布局会不会死循环？

我的 Popup 会不会卡窗口？

我的列表 100 万行怎么办？

我的 SVG 真的兼容吗？

我的 NativeAOT 能不能发布？

我的 Linux 能不能跑？

我的 Android 能不能工作？

我的 DevTools 自己会不会卡死？

我的 Theme 改一块颜色，为什么要把整棵树重新算一遍？

我的图片为什么会白？

这就是一个框架逐渐成熟时最真实的变化。

三十、还有一个变化值得特别说明

随着 Jalium UI 进入今天的阶段，预览版不再继续通过 NuGet 分发。

我觉得这并不只是一个发布策略的小调整。

它其实也意味着：

Jalium UI 开始更加认真地区分"快速试验中的东西"和"真正应该交给用户使用的版本"。

而现在我们看到的 26.10.9，是 GitHub Release 中明确标记的最新版本。

这对于一个仍然高速迭代的框架而言，是一种很自然的收敛。

三十一、现在的 Jalium UI，到底是什么？

如果让我站在今天这个时间点重新定义它。

我不会再把它简单叫：

"一个新的 WPF。"

也不会只叫：

"一个 GPU UI Framework。"

因为这两个说法，都不够完整。

现在的 Jalium UI 更像是一套完整的 .NET UI Runtime：

上面是：

JALXAML、Razor、Binding、Template、MVVM、Controls。

中间是：

Visual Tree、Dependency Property、Layout、Input、Theme、Virtualization。

下面是：

D3D12、Vulkan、Software、Native、Text、Media、AOT。

再往外：

Windows、Linux、Android。

它正在把这些东西拼成一个整体。

三十二、当然，它依然没有"完成"

这一点必须说。

Jalium UI 仍然在活跃开发。

而且从 26.10.9 的 Release Notes 里也能直接看到一些已知问题，例如 Alpine ARM64 的 Wayland + software-Vulkan smoke test，以及 Linux 图片管线测试里的并发 race。

这反而证明了一件事：

它现在面对的已经是真问题。

不是"页面看起来不漂亮"。

而是：

并发。

驱动。

GPU。

ABI。

Native。

平台差异。

布局。

资源生命周期。

这些东西。

一个项目开始处理这些问题的时候，才真的进入了框架工程的深水区。

三十三、半年时间，究竟值不值得关注？

我的答案是：

值得。

但不是因为它"已经完美"。

也不是因为它"已经取代了谁"。

而是因为从 2026 年 3 月 1 日开源，到 26.10.9，这条路线其实非常清楚：

最开始，是把东西做出来。

然后，把底层搭起来。

然后，把性能解决。

然后，把跨平台补起来。

然后，把 AOT、文本、输入、媒体、虚拟化、DevTools 这些复杂问题一个个接上。

最后开始回头清理：

布局。

图片。

SVG。

Theme。

Binding。

Popup。

Dependency Property。

这些真正影响日常体验的地方。

这是一条很正常、也很难得的成长路线。

写在最后

其实我挺喜欢看这种还在成长中的框架。

因为成熟框架往往已经把很多东西藏起来了。

你只需要调用一个 API。

但是一个正在成长的框架不一样。

你能看到它为什么开始做 GPU。

为什么开始做 Vello。

为什么开始做 Impeller。

为什么开始搞 Retained Rendering。

为什么开始搞 NativeAOT。

为什么要重做图片管线。

为什么一个小小的 @virtualize 都值得单独做成一个功能。

甚至还能看到它曾经走过弯路。

26.10.3 做过自己的 Extensions。

26.10.4 又把它撤掉。

这种"做了，再推翻，再重新选择"的过程，我觉得比一份漂亮得没有瑕疵的路线图更真实。

因为软件本来就是这么做出来的。

没人能在 3 月 1 日开源的那一天，就知道 8 月 28 日自己会面对哪些问题。

真正重要的是：

遇到了以后，愿不愿意继续往下做。

从 3 月到 8 月。

从 26.9.x 到 26.10.9。

Jalium UI 已经走了相当长的一段路。

现在它当然还年轻。

但你已经能看到它的骨架。

能看到它对 UI 的理解。

也能看到它对性能、跨平台、Native 和开发体验的野心。

最重要的是------

它开始有自己的味道了。

这可能才是一个框架真正开始成长的标志。

Jalium UI

GitHub：

https://github.com/VeryJokerJal/Jalium.UI

开源时间：2026 年 3 月 1 日

当前最新版本：26.10.9（2026 年 8 月 28 日）

当前发布口径：

Windows 10+

Android 12+