Widget的渲染机制使用了三棵树思想

简单来说就是

• widget树负责页面构建（画图纸）
• element树负责找不同（找出更新后图纸的不同点）
• renderobject树负责最终的界面更新和渲染（对图纸上的内容进行实现）

1. Widget树：描述“是什么”

◦ 本质是配置文件，用代码描述界面元素的“样子”和“结构”（比如按钮文本、输入框样式等），但不直接参与渲染。

◦ 每次状态更新时，Widget树会被重新构建（因为Widget是不可变的），但这一步只是生成新的配置，成本很低。

2. Element树：管理“如何更新”

◦ 作为中间层，它缓存Widget的配置，并对比前后两次Widget树的差异（即“找不同”）。

◦ 核心作用是决定哪些渲染对象需要更新：

◦ 若Widget的类型和key不变，Element会复用旧实例，只更新RenderObject的属性（比如按钮文本变化）；

◦ 若Widget类型或key变化，才会重建Element和RenderObject（比如从文本框换成按钮）。

◦ 因此，Element树是性能优化的关键，避免了重复创建渲染对象的开销。

3. RenderObject树：执行“最终渲染”

◦ 负责计算布局、绘制像素，是真正和屏幕渲染打交道的层。

◦ 每个RenderObject会记录自身的大小、位置、绘制指令等，最终由Flutter引擎将这些信息转化为屏幕上的图像。

类比理解（以装修房子为例）：

• Widget树：设计师画的装修图纸（描述客厅放沙发、卧室放床），每次改需求（如换沙发颜色）会重新画图纸，但图纸本身不花钱。

• Element树：施工队长，拿着图纸对比旧房现状，决定哪些地方要改（比如只换沙发，不拆墙），规划最小施工量。

• RenderObject树：工人团队，按施工队长的指令干活（搬沙发、刷墙），真正花钱花力气的环节。