前言
这节课我们不写应用代码，核心目标是搞懂"从你点一下按钮，到屏幕像素发生变化"中间到底经过了哪些环节、每个"零件"分别负责什么工作。理解底层技术栈之后，后续遇到渲染异常、事件不响应之类的问题，你就能快速定位到底是哪一层出了bug。
一、先搞懂Xilem和Masonry的关系
很多新手分不清这俩的区别，其实它们是两个不同层级的库，分工明确、配合工作：
- Masonry是底层的Widget工具包：它负责维护一个保留式的Widget树，处理布局计算、事件分发、底层渲染调度。它的API是给"造UI框架的人"用的，不是给普通应用开发者用的。
- Xilem是建在Masonry之上的响应式UI框架：它负责状态管理、视图diff、提供声明式API，它的API是给"写应用的人"用的。
打个通俗的比方：Masonry相当于汽车的底盘、发动机、传动系统，Xilem相当于方向盘、仪表盘、操控系统。你开车（写应用）用的是Xilem的接口，底层跑的全是Masonry的能力。
二、整个技术栈分层拆解
我们按照从用户交互到屏幕像素的顺序，从上到下讲每个组件的作用。
1. 窗口与事件层：winit
核心职责是创建跨平台原生窗口，处理所有系统级事件：鼠标点击、键盘输入、窗口缩放、拖动、系统通知这些。不管是Windows、macOS还是Linux，winit都封装了统一的API，Xilem/Masonry完全不需要关心不同平台的窗口差异，全部交给winit处理。
你之前课程里用的.run_window()，底层就是winit在创建窗口、跑事件循环。
2. UI逻辑层：Xilem + Masonry
这俩配合完成UI的核心逻辑，分工如下：
- Xilem负责"声明式视图+状态管理"：你写的app_logic闭包就是Xilem的部分，它管理应用状态，每次状态变化重新生成View树，对比新旧View树的差异，告诉Masonry"哪些地方需要更新"。
- Masonry负责"Widget树管理+布局计算"：接收Xilem的更新指令，维护实际的Widget树（比如按钮、文本、布局容器这些实体），计算每个组件的位置、大小，把事件（比如按钮点击）回调给Xilem的状态修改闭包。
3. 2D渲染层：Vello + wgpu
这俩负责把所有UI元素画到屏幕上：
- wgpu是跨平台的GPU抽象层，相当于Rust版的Vulkan/Metal/DirectX统一接口，它屏蔽了不同显卡、不同操作系统的GPU API差异，让上层不用管底层是N卡、A卡还是集成显卡，是Windows的DX还是macOS的Metal。
- Vello是基于wgpu构建的2D矢量渲染引擎，由Linebender团队（也就是开发Xilem的团队）专门为UI场景优化，采用GPU计算着色器做渲染，比传统的OpenGL管线性能更高，尤其是处理复杂矢量图形、文字、动画的时候优势明显。Masonry把所有Widget的绘制指令收集起来，交给Vello，Vello调用wgpu把这些指令渲染成屏幕上的像素。
4. 文本处理栈：Parley + Fontique
专门负责所有和文字相关的工作：
- Fontique负责字体集合管理：扫描系统里的所有字体，建立字体索引，当你指定"用微软雅黑"的时候，它负责找到对应的字体文件。
- Parley负责文本布局：计算文字的大小、换行、对齐、字间距，把一段文字转换成精确的每个字符的位置信息，再交给Vello渲染出来。之前你用的text()组件，底层就是这俩在工作。
5. 无障碍层：AccessKit
负责让应用能被辅助工具读取，比如屏幕阅读器（给视障用户用的）、语音控制工具。它会把Masonry的Widget树转换成标准的无障碍树，让系统级的辅助工具能识别界面上的按钮、文本内容，比如你点一个按钮，屏幕阅读器能读出"加一按钮"，就是AccessKit在工作。
三、完整的事件流：所有组件怎么串起来
我们以"点击计数器的+1按钮"为例，走一遍完整流程：
- 用户点击鼠标，winit捕获到鼠标点击事件，把事件的坐标、类型传递给Masonry。
- Masonry根据坐标计算出点击的是"+1按钮"这个Widget，触发按钮的点击回调，回调里执行count += 1，修改Xilem管理的应用状态。
- 状态变化触发Xilem重新运行app_logic闭包，生成新的View树，Xilem的diff引擎对比新旧View树，发现只有文本内容从"0"变成了"1"，其他部分没变。
- Xilem把"更新文本内容"的指令传递给Masonry，Masonry更新对应的Label Widget的内容。
- Masonry重新计算布局（这个场景布局没变，但会走一遍检查流程），然后把所有需要重绘的区域指令交给Vello。
- Vello调用wgpu，把更新后的文本渲染到屏幕上，用户看到数字从0变成了1。
整个过程在毫秒级完成，用户感知到的就是点了按钮数字立刻变化。
四、为什么选这些组件？
- 选winit：Rust生态里最成熟的跨平台窗口库，支持所有主流桌面平台，API稳定。
- 选wgpu：目前Rust生态唯一成熟的跨平台GPU抽象层，WebGPU标准的Rust实现，未来兼容性最好。
- 选Vello：由Linebender团队自己做的渲染引擎，专门为UI场景优化，和整个技术栈适配度最高，性能比基于OpenGL的方案高很多。
- 选Parley：同样是Linebender团队开发的Rust原生文本栈，和Vello的适配更好，支持复杂的文字排版特性。
- 选AccessKit：Rust生态里唯一成熟的跨平台无障碍解决方案，支持所有主流操作系统的无障碍API。
五、练习题
练习1（基础概念）
分别说明以下组件在Xilem技术栈中承担的职责：winit、Masonry、Vello、Parley、AccessKit。
练习2（流程判断）
当用户拖动窗口边框调整窗口大小时，以下哪个组件主要负责处理窗口尺寸变化的事件？哪个组件负责重新计算所有UI元素的布局？哪个组件负责把调整后的界面重新渲染到屏幕上？
练习3（思考题）
为什么Xilem不直接调用wgpu渲染，而是要通过Masonry这一层中间层？
六、练习题答案
练习1答案：
- winit：负责创建跨平台原生窗口，处理所有系统级输入事件（鼠标、键盘、窗口操作等）。
- Masonry：底层Widget工具包，负责维护Widget树、计算布局、分发事件、调度渲染。
- Vello：基于wgpu的2D矢量渲染引擎，负责把所有UI元素渲染成屏幕像素。
- Parley：文本布局引擎，负责计算文字的大小、换行、对齐等排版信息，配合Fontique完成字体加载。
- AccessKit：无障碍适配层，负责把UI树转换成标准无障碍树，支持屏幕阅读器等辅助工具。
练习2答案：
- 处理窗口尺寸变化事件的是winit；
- 重新计算UI布局的是Masonry；
- 重新渲染界面的是Vello（通过wgpu调用GPU）。
练习3答案：
核心原因是职责分离。Xilem是上层的响应式框架，只负责状态管理和视图diff，不关心底层的Widget实现、布局计算；Masonry是底层的Widget工具包，负责所有和UI实体相关的逻辑。如果Xilem直接绑定wgpu，那它就无法适配其他渲染后端（比如Web端的DOM渲染），也无法被其他框架复用。
通过Masonry这一层，Xilem只需要关心"更新什么内容"，不需要关心"怎么渲染"，未来如果要把Xilem适配到Web端，只需要把Masonry替换成Web的DOM后端即可，上层的Xilem代码完全不用改。同时Masonry也可以被其他框架复用，比如有人想做一个即时模式GUI框架，也可以直接基于Masonry开发，不用重复造轮子。
七、课后小结
这节课的核心是理解整个技术栈的分层和协作流程：
- winit管窗口和系统事件
- Xilem管状态和视图diff
- Masonry管Widget树和布局
- Vello+wgpu管渲染
- Parley+Fontique管文字
- AccessKit管无障碍
每一层各司其职，通过清晰的接口协作，最终实现了高性能、跨平台的UI框架。后续课程里如果遇到渲染、事件相关的问题，你就可以按照这个分层来定位问题出在哪一层。
底层搞懂了，要不要接着看第八课：条件渲染（one_of）？