一、写在前面为什么这一课很重要前12课我们学了按钮、布局、条件渲染、Lens、状态管理等具体语法。如果一直停留在这个API怎么用很容易陷入一种错觉Xilem 只是另一个写法不同的 UI 框架。但事实并非如此。Xilem 的架构建立在一条极其清晰的原则上——“一切皆设计图”Everything is a Blueprint。这不是一句宣传语而是贯穿类型系统、运行时调度、状态管理的一条主线。不理解它你写的代码能跑但你看不懂为什么这么设计理解了它你会发现 Xilem 的每一个 API 都在呼应同一个中心思想。这一课我们用官方最小的计数器示例不到20行把这条主线彻底扒开讲透。二、完整代码usewinit::error::EventLoopError;usexilem::view::{Axis,text_button,flex,label};usexilem::{EventLoop,WindowOptions,WidgetView,Xilem};// ① 状态一个普通的 Rust 结构体#[derive(Default)]structCounter{num:i32,}// ② 设计图函数状态 → View Treefnapp_logic(data:mutCounter)-implWidgetViewCounteruse{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data:mutCounter|data.num1),),)}// ③ 启动把状态 设计图函数交给框架fnmain()-Result(),EventLoopError{letappXilem::new_simple(Counter::default(),app_logic,WindowOptions::new(Counter app),);app.run_in(EventLoop::with_user_event())?;Ok(())}运行效果窗口显示数字0和一个increment按钮点击按钮数字加1。这不到20行代码每一行都在回答同一个问题如何用画蓝图的方式写 UI。三、先建立正确的心理模型工程师 vs 设计师在传统命令式 UI 框架比如 GTK、Qt、Win32中你扮演的是施工队长// 传统写法伪代码letlabelLabel::new(0);letbuttonButton::new(increment);button.on_click(||{label.set_text(1);// ← 你直接指挥 Label 干活});window.add(label);window.add(button);你要持有每一块砖Label、Button 的引用要手动告诉每一块砖去做什么set_text还要负责它们的生老病死创建、更新、销毁。而在 Xilem 中你扮演的是设计师fnapp_logic(data:mutCounter)-implWidgetViewCounter{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data|data.num1),))}你只画一张图纸View Tree上面写着这里放个标签显示data.num那里放个按钮点击时data.num 1。你不持有任何控件不指挥任何控件也不销毁任何控件。你只负责描述想要什么谁来建造、怎么建造、什么时候重建全部交给框架。这就是一切皆设计图的第一层含义你从施工队长变成了设计师。请牢牢记住这个心理模型——后面每一行代码的分析都建立在它之上。四、逐行深挖每一行都是画图不是施工第①步struct Counter { num: i32 }——蓝图上的数据#[derive(Default)]structCounter{num:i32,}这是你的全部状态——一个整数。注意它具备的三个反常识特征特征1没有任何 UI 相关字段。没有Label、没有Button、没有Widget引用甚至没有窗口这个概念。它就是一个纯粹的、普通的 Rust 结构体。特征2它是Default的。因为 Xilem 需要一个初始蓝图来启动——第一帧画面必须由某个初始状态生成。Counter::default()给出num 0框架据此画出0 和 increment 按钮。特征3它不与任何 UI 生命周期绑定。这意味着Counter可以被任意app_logic消费可以脱离 GUI 环境做单元测试可以在不同平台间复用。状态是纯粹的事实UI 只是事实的一种呈现。这一点和 React 的useState、Elm 的 Model 是同一个思想脉络。第②步app_logic——整个理念的心脏fnapp_logic(data:mutCounter)-implWidgetViewCounteruse{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data:mutCounter|data.num1),),)}这是本课最核心的函数。它的签名本身就是一份宣言输入一个状态mut Counter。输出一张设计图impl WidgetViewCounter。注意三点1返回类型是WidgetView不是Widget。这是一切皆设计图在类型系统层面的直接体现。看名字Widget 真实控件有内存、有生命周期、能接收事件、能渲染WidgetView 控件的图纸轻量、无状态、可以随意生成销毁如果你返回Widget就说明你在直接建造而返回WidgetView说明你只是在画图。编译器帮你在类型层面把设计和施工分开了。2参数是mut Counter不是Counter。为什么必须是可变的两个原因app_logic是根组件。在 Xilem 中根组件是唯一持有全局状态修改权限的地方这个权限通过mut传递下去。按钮闭包|data: mut Counter| data.num 1需要一个mut Counter来修改状态。这个mut的最终来源就是app_logic的参数——权限链从根组件一直贯通到事件闭包。如果写成Counter那么按钮闭包就拿不到修改权限整个状态变化 → 界面更新的链路在编译期就被切断了。这是 Xilem 用类型系统保证单向数据流的方式。3 use是什么鬼Xilem 0.4 大量使用精确捕获precise capturing语法。 use的意思是返回的 View 类型不捕获函数外部的任何引用它的生命周期与参数解耦。为什么需要这个因为 Xilem 要求 View 类型必须满足static要放进框架的调度队列里。如果编译器推断出返回类型借用了某个外部引用就会违反static编译失败。use明确告诉编译器“这个返回类型不借用任何东西放心让它static。”这是 Xilem 0.4 的必写语法细节新手经常在这里卡住。再看函数体的三个调用逐一对应蓝图上的三种标注label(format!({}, data.num))— 蓝图上标注这里显示数字。它返回一个 Label 类型的 View 节点并没有在屏幕上创建任何东西。它只是把data.num当时的值抄进了图纸。下次app_logic被重新调用时会抄新的值。text_button(increment, |data: mut Counter| data.num 1)— 蓝图上标注这里放个按钮文字是 increment点击时执行这个闭包。闭包是状态修改的唯一入口——你永远不会在别的地方写data.num 1。flex(Axis::Vertical, (...))— 蓝图上标注这些子元素纵向排列。元组(label, button)表示两个子节点Xilem 用元组组合 View天然容纳任意数量上限由 trait 实现决定。整个函数是一个纯描述。它没有副作用不会触发渲染不会分配 Widget。它只是在说“如果状态长这样那么界面应该长这样。”第③步main——把设计图交给施工队letappXilem::new_simple(Counter::default(),// 初始状态app_logic,// 设计图函数WindowOptions::new(Counter app),);app.run_in(EventLoop::with_user_event())?;Counter::default()— 初始状态用来生成第一帧蓝图。app_logic— 传递的是函数本身不是它的调用结果。这意味着框架在运行时可以反复调用它每次状态变化都会调用一次。run_in(EventLoop)— 启动事件循环。之后框架接管一切监听状态变化 → 重新调用app_logic→ 生成新蓝图 → diff → 更新屏幕。这里有一个深刻的对比在你之前接触的框架里main里通常写的是创建窗口、创建控件、注册事件、显示窗口——一堆施工动作。而在 Xilem 里main只是把状态和设计图函数交给框架然后什么都不管了。你真正的工作量全在app_logic里而app_logic只是画图。五、运行时到底发生了什么一次点击的完整生命周期光看静态代码还不够我们跟着一次按钮点击走完全程看设计图如何在运行时起作用。初始状态Counter { num: 0 }→ 框架调用app_logic→ 生成第一棵 View Treeflex(Vertical) ├── label(0) └── text_button(increment, 闭包)框架据此建造第一套真实 Widget一个垂直布局、一个显示 “0” 的标签、一个写着 “increment” 的按钮。用户点击 increment 按钮第1步闭包执行。|data:mutCounter|data.num1data.num从0变为1。注意闭包只改了状态没有碰任何 UI。第2步框架检测到状态变化。Xilem 运行时会追踪状态的版本内部机制你不用管。发现变化后重新调用app_logic(mut Counter { num: 1 })。第3步生成一棵全新的 View Tree。flex(Vertical) ├── label(1) ← 变了 └── text_button(increment, 闭包) ← 没变注意新树不是旧树的增量修改而是从头完整生成的。这看起来很浪费但 View 是极轻量的没有真实控件那么重生成成本极低。第4步diff 新旧两棵树。框架比较新树和旧树逐节点判断flex(Vertical)— 类型、参数都没变 →跳过label(0)vslabel(1)— 只有文本变了 →需要更新text_button(increment, 闭包)— 文本和闭包都没变 →跳过第5步最小化更新真实 Widget。框架只更新那个 Label 的文本内容从 “0” 改成 “1”其他 Widget 完全不动。这就是所谓的保留式重建retained rebuild——虽然你的代码每次都重新生成整棵树但屏幕上的真实控件被精细地复用。整个过程的核心洞察你的代码从不操作 UI 对象。你从未写过label_widget.set_text(1)这样的代码。你只在新蓝图上写了label(format!({}, data.num))剩下的事全部由框架完成。这就是一切皆设计图的运行时含义状态是唯一的真相界面是状态的函数。六、一切皆设计图的三条承诺把理念再提炼一层。它实际上向你承诺了三件事承诺一你永远不持有 UI 对象。没有 Label 引用、没有 Button 句柄、没有 Widget 指针。你持有的只有状态和生成设计图的函数。这消除了整个类别的 bug不会忘记移除事件监听器——你从来没注册过。不会忘记销毁子组件——你从来没创建过。不会状态和界面不同步——界面是状态的函数必然同步。承诺二状态变化自动触发重绘。你不需要手动通知框架状态变了请更新界面。框架自己监听、自己重新调用app_logic、自己 diff、自己施工。你的代码是纯函数状态 → 设计图。副作用建造、更新、销毁由框架在安全的时机执行。承诺三视图树是无状态的一次性产物。View Tree 生成完、diff 完就被丢弃了。它不是活着的对象不需要维护不需要释放。它只是当前状态下界面该长什么样的一份快照。这意味着你完全不用考虑视图的生命周期——每次状态变化都重新生成框架负责处理新旧交替。你的心智负担从管理 UI 对象降为描述 UI 样子。七、三层架构从蓝图到像素Xilem 内部有三层结构但你只需要关心最上面一层┌────────────────────────────────────────────────────┐ │ View 层你写的代码 │ │ app_logic 返回的 WidgetView 树 —— 设计图 │ │ 瞬时存在每次状态变化都重新生成、diff 后丢弃 │ └────────────────────────────────────────────────────┘ ↓ diff ┌────────────────────────────────────────────────────┐ │ Element 层框架内部 │ │ 桥接 View 与 Widget 的中间表示 │ │ 负责调度、比对、决定哪些 Widget 需要更新 │ └────────────────────────────────────────────────────┘ ↓ 最小化更新 ┌────────────────────────────────────────────────────┐ │ Widget 层Masonry Vello │ │ 真实可点击、可渲染的控件 │ │ 用 Vello GPU 引擎绘制到屏幕 │ └────────────────────────────────────────────────────┘三层之间的边界极其清晰你只写 View 层app_logic。Element 层你不接触——它决定 diff 结果。Widget 层你不接触——它负责真实渲染和事件接收。一切皆设计图的边界就在这里你只生活在最上面一层视图是最上面的那层薄薄的描述。下面两层由框架自动维护你不需要、也不能手动干预。八、为什么这样设计三个深层动机理解理念之后再问一个为什么Xilem 为什么要选择一切皆设计图这条路动机一状态与界面解耦杜绝不一致。传统框架中状态和控件是两份数据你手动同步它们一疏忽就会出现数据变了界面没变或界面变了数据没变的 bug。Xilem 把界面变成状态的纯函数状态是唯一真相界面永远是状态的投影——不一致在结构上不可能发生。动机二跨平台复用逻辑。app_logic是纯 Rust 函数不依赖任何具体平台。同一份app_logic可以跑在桌面Xilem、Web未来、移动端未来。因为它是设计图不是施工过程——设计图是抽象的施工是具体的。动机三编译期保证单向数据流。状态修改只能通过事件闭包进行而事件闭包拿到的mut权限来自app_logic参数。这条权限链由类型系统保证你不可能在其他地方偷偷改状态。这就是为什么 Xilem 不需要 Redux、MobX 这类状态管理库——类型系统已经把约束嵌进去了。九、Cargo.toml 配置[package] name xilem_lesson13 version 0.1.0 edition 2024 [dependencies] xilem 0.4.0 winit 0.30Rust 2024 editionXilem 0.4 要求winit提供事件循环EventLoop、EventLoopErrorxilem 0.4.0内部依赖 Masonry、Vello、winit十、课后练习练习1改成减法计数器把按钮文本改为decrement闭包改为data.num - 1。其他不动。目的体验改状态 改蓝图的直觉。练习2加一个重置按钮在 flex 元组中再加一个text_button(reset, |data: mut Counter| data.num 0)。观察元组如何自然地容纳多个子节点。练习3加一个翻倍按钮进阶提示你需要一个能读写data.num的闭包。text_button(double,|data:mutCounter|data.num*2)思考这个闭包和increment的闭包结构完全一样为什么它们能放在同一个元组里练习4思考题——为什么mutapp_logic的参数是mut Counter而不是Counter。请从按钮闭包的状态修改权限来源这个角度写一段话解释如果改成Counter会在哪一步编译失败练习5观察题在app_logic里加一行println!(app_logic called)运行程序点击几次按钮。观察并解释为什么每次点击都会打印一次这个观察如何印证状态变化 → 重新调用 app_logic十一、本课核心要点回顾要点含义一切皆设计图你写的是界面应该长什么样的描述不是创建/操作界面对象的指令工程师 vs 设计师你从施工队长变成设计师框架从道具管理员变成施工队长WidgetViewvsWidget类型系统在编译期把设计和实物分开mut的设计意图根组件拥有全局状态修改权限通过参数链贯通到事件闭包use的作用精确捕获语法让返回类型满足static要求一次点击的完整周期闭包改状态 → 框架重调 app_logic → 生成新树 → diff → 最小化更新三条承诺不持有 UI 对象 / 状态变化自动重绘 / 视图树是一次性快照三层架构View你写/ Element框架内部调度/ Widget框架内部渲染为什么这样设计状态与界面解耦、跨平台复用、编译期保证单向数据流一切皆设计图不是修辞而是 Xilem 架构的类型系统承诺。app_logic的返回类型是impl WidgetViewCounter编译期就保证你只能生成设计图无法触碰到实物。当你习惯了这个思维方式写 UI 就变成了写一个纯函数——给定状态返回描述。剩下的交给框架。下一课我们会在这个基础上引入Lens机制看 Xilem 如何用设计图的思想实现组件化——把大蓝图拆成小蓝图让状态的不同片段由不同的子函数负责。
【xilem0.4基础语法学与练】第13课：Xilem 0.4 计数器示例体现“一切皆设计图“
一、写在前面为什么这一课很重要前12课我们学了按钮、布局、条件渲染、Lens、状态管理等具体语法。如果一直停留在这个API怎么用很容易陷入一种错觉Xilem 只是另一个写法不同的 UI 框架。但事实并非如此。Xilem 的架构建立在一条极其清晰的原则上——“一切皆设计图”Everything is a Blueprint。这不是一句宣传语而是贯穿类型系统、运行时调度、状态管理的一条主线。不理解它你写的代码能跑但你看不懂为什么这么设计理解了它你会发现 Xilem 的每一个 API 都在呼应同一个中心思想。这一课我们用官方最小的计数器示例不到20行把这条主线彻底扒开讲透。二、完整代码usewinit::error::EventLoopError;usexilem::view::{Axis,text_button,flex,label};usexilem::{EventLoop,WindowOptions,WidgetView,Xilem};// ① 状态一个普通的 Rust 结构体#[derive(Default)]structCounter{num:i32,}// ② 设计图函数状态 → View Treefnapp_logic(data:mutCounter)-implWidgetViewCounteruse{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data:mutCounter|data.num1),),)}// ③ 启动把状态 设计图函数交给框架fnmain()-Result(),EventLoopError{letappXilem::new_simple(Counter::default(),app_logic,WindowOptions::new(Counter app),);app.run_in(EventLoop::with_user_event())?;Ok(())}运行效果窗口显示数字0和一个increment按钮点击按钮数字加1。这不到20行代码每一行都在回答同一个问题如何用画蓝图的方式写 UI。三、先建立正确的心理模型工程师 vs 设计师在传统命令式 UI 框架比如 GTK、Qt、Win32中你扮演的是施工队长// 传统写法伪代码letlabelLabel::new(0);letbuttonButton::new(increment);button.on_click(||{label.set_text(1);// ← 你直接指挥 Label 干活});window.add(label);window.add(button);你要持有每一块砖Label、Button 的引用要手动告诉每一块砖去做什么set_text还要负责它们的生老病死创建、更新、销毁。而在 Xilem 中你扮演的是设计师fnapp_logic(data:mutCounter)-implWidgetViewCounter{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data|data.num1),))}你只画一张图纸View Tree上面写着这里放个标签显示data.num那里放个按钮点击时data.num 1。你不持有任何控件不指挥任何控件也不销毁任何控件。你只负责描述想要什么谁来建造、怎么建造、什么时候重建全部交给框架。这就是一切皆设计图的第一层含义你从施工队长变成了设计师。请牢牢记住这个心理模型——后面每一行代码的分析都建立在它之上。四、逐行深挖每一行都是画图不是施工第①步struct Counter { num: i32 }——蓝图上的数据#[derive(Default)]structCounter{num:i32,}这是你的全部状态——一个整数。注意它具备的三个反常识特征特征1没有任何 UI 相关字段。没有Label、没有Button、没有Widget引用甚至没有窗口这个概念。它就是一个纯粹的、普通的 Rust 结构体。特征2它是Default的。因为 Xilem 需要一个初始蓝图来启动——第一帧画面必须由某个初始状态生成。Counter::default()给出num 0框架据此画出0 和 increment 按钮。特征3它不与任何 UI 生命周期绑定。这意味着Counter可以被任意app_logic消费可以脱离 GUI 环境做单元测试可以在不同平台间复用。状态是纯粹的事实UI 只是事实的一种呈现。这一点和 React 的useState、Elm 的 Model 是同一个思想脉络。第②步app_logic——整个理念的心脏fnapp_logic(data:mutCounter)-implWidgetViewCounteruse{flex(Axis::Vertical,(label(format!({},data.num)),text_button(increment,|data:mutCounter|data.num1),),)}这是本课最核心的函数。它的签名本身就是一份宣言输入一个状态mut Counter。输出一张设计图impl WidgetViewCounter。注意三点1返回类型是WidgetView不是Widget。这是一切皆设计图在类型系统层面的直接体现。看名字Widget 真实控件有内存、有生命周期、能接收事件、能渲染WidgetView 控件的图纸轻量、无状态、可以随意生成销毁如果你返回Widget就说明你在直接建造而返回WidgetView说明你只是在画图。编译器帮你在类型层面把设计和施工分开了。2参数是mut Counter不是Counter。为什么必须是可变的两个原因app_logic是根组件。在 Xilem 中根组件是唯一持有全局状态修改权限的地方这个权限通过mut传递下去。按钮闭包|data: mut Counter| data.num 1需要一个mut Counter来修改状态。这个mut的最终来源就是app_logic的参数——权限链从根组件一直贯通到事件闭包。如果写成Counter那么按钮闭包就拿不到修改权限整个状态变化 → 界面更新的链路在编译期就被切断了。这是 Xilem 用类型系统保证单向数据流的方式。3 use是什么鬼Xilem 0.4 大量使用精确捕获precise capturing语法。 use的意思是返回的 View 类型不捕获函数外部的任何引用它的生命周期与参数解耦。为什么需要这个因为 Xilem 要求 View 类型必须满足static要放进框架的调度队列里。如果编译器推断出返回类型借用了某个外部引用就会违反static编译失败。use明确告诉编译器“这个返回类型不借用任何东西放心让它static。”这是 Xilem 0.4 的必写语法细节新手经常在这里卡住。再看函数体的三个调用逐一对应蓝图上的三种标注label(format!({}, data.num))— 蓝图上标注这里显示数字。它返回一个 Label 类型的 View 节点并没有在屏幕上创建任何东西。它只是把data.num当时的值抄进了图纸。下次app_logic被重新调用时会抄新的值。text_button(increment, |data: mut Counter| data.num 1)— 蓝图上标注这里放个按钮文字是 increment点击时执行这个闭包。闭包是状态修改的唯一入口——你永远不会在别的地方写data.num 1。flex(Axis::Vertical, (...))— 蓝图上标注这些子元素纵向排列。元组(label, button)表示两个子节点Xilem 用元组组合 View天然容纳任意数量上限由 trait 实现决定。整个函数是一个纯描述。它没有副作用不会触发渲染不会分配 Widget。它只是在说“如果状态长这样那么界面应该长这样。”第③步main——把设计图交给施工队letappXilem::new_simple(Counter::default(),// 初始状态app_logic,// 设计图函数WindowOptions::new(Counter app),);app.run_in(EventLoop::with_user_event())?;Counter::default()— 初始状态用来生成第一帧蓝图。app_logic— 传递的是函数本身不是它的调用结果。这意味着框架在运行时可以反复调用它每次状态变化都会调用一次。run_in(EventLoop)— 启动事件循环。之后框架接管一切监听状态变化 → 重新调用app_logic→ 生成新蓝图 → diff → 更新屏幕。这里有一个深刻的对比在你之前接触的框架里main里通常写的是创建窗口、创建控件、注册事件、显示窗口——一堆施工动作。而在 Xilem 里main只是把状态和设计图函数交给框架然后什么都不管了。你真正的工作量全在app_logic里而app_logic只是画图。五、运行时到底发生了什么一次点击的完整生命周期光看静态代码还不够我们跟着一次按钮点击走完全程看设计图如何在运行时起作用。初始状态Counter { num: 0 }→ 框架调用app_logic→ 生成第一棵 View Treeflex(Vertical) ├── label(0) └── text_button(increment, 闭包)框架据此建造第一套真实 Widget一个垂直布局、一个显示 “0” 的标签、一个写着 “increment” 的按钮。用户点击 increment 按钮第1步闭包执行。|data:mutCounter|data.num1data.num从0变为1。注意闭包只改了状态没有碰任何 UI。第2步框架检测到状态变化。Xilem 运行时会追踪状态的版本内部机制你不用管。发现变化后重新调用app_logic(mut Counter { num: 1 })。第3步生成一棵全新的 View Tree。flex(Vertical) ├── label(1) ← 变了 └── text_button(increment, 闭包) ← 没变注意新树不是旧树的增量修改而是从头完整生成的。这看起来很浪费但 View 是极轻量的没有真实控件那么重生成成本极低。第4步diff 新旧两棵树。框架比较新树和旧树逐节点判断flex(Vertical)— 类型、参数都没变 →跳过label(0)vslabel(1)— 只有文本变了 →需要更新text_button(increment, 闭包)— 文本和闭包都没变 →跳过第5步最小化更新真实 Widget。框架只更新那个 Label 的文本内容从 “0” 改成 “1”其他 Widget 完全不动。这就是所谓的保留式重建retained rebuild——虽然你的代码每次都重新生成整棵树但屏幕上的真实控件被精细地复用。整个过程的核心洞察你的代码从不操作 UI 对象。你从未写过label_widget.set_text(1)这样的代码。你只在新蓝图上写了label(format!({}, data.num))剩下的事全部由框架完成。这就是一切皆设计图的运行时含义状态是唯一的真相界面是状态的函数。六、一切皆设计图的三条承诺把理念再提炼一层。它实际上向你承诺了三件事承诺一你永远不持有 UI 对象。没有 Label 引用、没有 Button 句柄、没有 Widget 指针。你持有的只有状态和生成设计图的函数。这消除了整个类别的 bug不会忘记移除事件监听器——你从来没注册过。不会忘记销毁子组件——你从来没创建过。不会状态和界面不同步——界面是状态的函数必然同步。承诺二状态变化自动触发重绘。你不需要手动通知框架状态变了请更新界面。框架自己监听、自己重新调用app_logic、自己 diff、自己施工。你的代码是纯函数状态 → 设计图。副作用建造、更新、销毁由框架在安全的时机执行。承诺三视图树是无状态的一次性产物。View Tree 生成完、diff 完就被丢弃了。它不是活着的对象不需要维护不需要释放。它只是当前状态下界面该长什么样的一份快照。这意味着你完全不用考虑视图的生命周期——每次状态变化都重新生成框架负责处理新旧交替。你的心智负担从管理 UI 对象降为描述 UI 样子。七、三层架构从蓝图到像素Xilem 内部有三层结构但你只需要关心最上面一层┌────────────────────────────────────────────────────┐ │ View 层你写的代码 │ │ app_logic 返回的 WidgetView 树 —— 设计图 │ │ 瞬时存在每次状态变化都重新生成、diff 后丢弃 │ └────────────────────────────────────────────────────┘ ↓ diff ┌────────────────────────────────────────────────────┐ │ Element 层框架内部 │ │ 桥接 View 与 Widget 的中间表示 │ │ 负责调度、比对、决定哪些 Widget 需要更新 │ └────────────────────────────────────────────────────┘ ↓ 最小化更新 ┌────────────────────────────────────────────────────┐ │ Widget 层Masonry Vello │ │ 真实可点击、可渲染的控件 │ │ 用 Vello GPU 引擎绘制到屏幕 │ └────────────────────────────────────────────────────┘三层之间的边界极其清晰你只写 View 层app_logic。Element 层你不接触——它决定 diff 结果。Widget 层你不接触——它负责真实渲染和事件接收。一切皆设计图的边界就在这里你只生活在最上面一层视图是最上面的那层薄薄的描述。下面两层由框架自动维护你不需要、也不能手动干预。八、为什么这样设计三个深层动机理解理念之后再问一个为什么Xilem 为什么要选择一切皆设计图这条路动机一状态与界面解耦杜绝不一致。传统框架中状态和控件是两份数据你手动同步它们一疏忽就会出现数据变了界面没变或界面变了数据没变的 bug。Xilem 把界面变成状态的纯函数状态是唯一真相界面永远是状态的投影——不一致在结构上不可能发生。动机二跨平台复用逻辑。app_logic是纯 Rust 函数不依赖任何具体平台。同一份app_logic可以跑在桌面Xilem、Web未来、移动端未来。因为它是设计图不是施工过程——设计图是抽象的施工是具体的。动机三编译期保证单向数据流。状态修改只能通过事件闭包进行而事件闭包拿到的mut权限来自app_logic参数。这条权限链由类型系统保证你不可能在其他地方偷偷改状态。这就是为什么 Xilem 不需要 Redux、MobX 这类状态管理库——类型系统已经把约束嵌进去了。九、Cargo.toml 配置[package] name xilem_lesson13 version 0.1.0 edition 2024 [dependencies] xilem 0.4.0 winit 0.30Rust 2024 editionXilem 0.4 要求winit提供事件循环EventLoop、EventLoopErrorxilem 0.4.0内部依赖 Masonry、Vello、winit十、课后练习练习1改成减法计数器把按钮文本改为decrement闭包改为data.num - 1。其他不动。目的体验改状态 改蓝图的直觉。练习2加一个重置按钮在 flex 元组中再加一个text_button(reset, |data: mut Counter| data.num 0)。观察元组如何自然地容纳多个子节点。练习3加一个翻倍按钮进阶提示你需要一个能读写data.num的闭包。text_button(double,|data:mutCounter|data.num*2)思考这个闭包和increment的闭包结构完全一样为什么它们能放在同一个元组里练习4思考题——为什么mutapp_logic的参数是mut Counter而不是Counter。请从按钮闭包的状态修改权限来源这个角度写一段话解释如果改成Counter会在哪一步编译失败练习5观察题在app_logic里加一行println!(app_logic called)运行程序点击几次按钮。观察并解释为什么每次点击都会打印一次这个观察如何印证状态变化 → 重新调用 app_logic十一、本课核心要点回顾要点含义一切皆设计图你写的是界面应该长什么样的描述不是创建/操作界面对象的指令工程师 vs 设计师你从施工队长变成设计师框架从道具管理员变成施工队长WidgetViewvsWidget类型系统在编译期把设计和实物分开mut的设计意图根组件拥有全局状态修改权限通过参数链贯通到事件闭包use的作用精确捕获语法让返回类型满足static要求一次点击的完整周期闭包改状态 → 框架重调 app_logic → 生成新树 → diff → 最小化更新三条承诺不持有 UI 对象 / 状态变化自动重绘 / 视图树是一次性快照三层架构View你写/ Element框架内部调度/ Widget框架内部渲染为什么这样设计状态与界面解耦、跨平台复用、编译期保证单向数据流一切皆设计图不是修辞而是 Xilem 架构的类型系统承诺。app_logic的返回类型是impl WidgetViewCounter编译期就保证你只能生成设计图无法触碰到实物。当你习惯了这个思维方式写 UI 就变成了写一个纯函数——给定状态返回描述。剩下的交给框架。下一课我们会在这个基础上引入Lens机制看 Xilem 如何用设计图的思想实现组件化——把大蓝图拆成小蓝图让状态的不同片段由不同的子函数负责。
