核心概念

Ansiq 的设计可以先浓缩成 4 个概念：

1. runtime-first
2. retained tree
3. signal-first reactivity
4. terminal-native rendering

后面的所有细节，基本都可以回到这 4 点上理解。

1. Runtime-first

很多 TUI 库的起点是“怎么画组件”，Ansiq 的起点是“谁来协调整个终端应用的运行”。

所以在 Ansiq 里，runtime 不是次要配角。它要负责：

• app lifecycle
• focus
• input routing
• reactive flush scheduling
• subtree replacement
• partial relayout
• viewport/session
• terminal patch emission

也正因为这样，Ansiq 更适合做“长期运行的终端应用”，而不仅仅是“画一屏 UI”。

2. Retained tree

Ansiq 不是 immediate-mode。

它不会要求你每一帧都重新描述整个终端画面，而是：

• 保留一棵 UI tree
• 在状态变化时只更新受影响的部分
• 最后再把变化过的区域画进 framebuffer

这点很关键，因为它决定了后面的：

• dirty scope
• subtree replacement
• continuity contract
• partial relayout

都成为可能。

3. Signal-first reactivity

Ansiq 的响应式核心现在是：

• signal
• computed
• effect

这里最重要的不是 API 名字，而是职责边界：

• 响应式系统决定 谁脏了
• runtime 决定 脏了之后怎么更新

这让 Ansiq 避免滑回“每次状态变化都整树 rerender”的模型。

4. Terminal-native rendering

Ansiq 的最终输出目标不是浏览器 DOM，而是 terminal。

所以它真正做的是：

• 渲染到 framebuffer
• 做 diff
• 发出 terminal patches

这一点决定了它对 viewport、scrollback、history commit 的重视程度会比很多普通 UI 框架更高。

这四个概念如何连起来

可以把 Ansiq 的主链路理解成：

signals change
-> dirty scopes
-> subtree rerender
-> partial relayout
-> invalidated regions
-> framebuffer diff
-> terminal patch emission

这里面每一段都对应一个单独的 runtime 责任。

你接下来会反复遇到的两个边界

边界一：reactive graph vs UI tree

响应式图和 UI 树是两棵不同的结构。
不要把它们想成一回事。

如果你想系统理解这一点，而不只是记住一句口号，后面“内部原理”里的 响应式图与 UI 树 会把原理拆开讲。

边界二：widgets vs runtime

Ansiq 希望低阶 widgets 保持易用，但不会把整个 runtime 退回到 immediate-mode 模型。

而如果你想理解“runtime 到底是怎么组织生命周期和主循环的”，后面的内部原理页 Runtime 循环 会继续拆开讲。

下一步

推荐按这个顺序继续：

1. 响应式
2. 组件与 view!
3. 如果你想提前深入内部机制，再读 生命周期与 Runtime 循环