38 lines
3.1 KiB
Markdown
38 lines
3.1 KiB
Markdown
# Tessera 架构与进展导览
|
|
|
|
核对日期：2026-10-25。范围：本仓库当前实现；Aster 子模块固定在 `f3e1670`，本次不更新其代码或版本。
|
|
|
|
Tessera 目前是**运行 Endor 对象程序的原生桌面宿主**。Endor 程序创建和共享对象，Page 把对象组织成可交互界面；Tessera 负责窗口、输入、布局、绘制、调试入口和本机 API。它已经能运行多页面示例，但还不是带持久化、权限和业务后端的完整应用平台。
|
|
|
|
建议按下面顺序阅读。图表示真实结构或经过标注的简化流程，不把后续计划画成已经存在的组件。
|
|
|
|
| 文档 | 回答的问题 |
|
|
| --- | --- |
|
|
| [01 模块与部署](01-modules.md) | 目录为什么这样分？有哪些线程与外部依赖？ |
|
|
| [02 对象模型与所有权](02-object-model.md) | Block、Page、Window、Mount 分别是什么？谁保留对象？ |
|
|
| [03 执行与发布](03-runtime.md) | Endor 如何变成界面？错误和过期请求怎么处理？ |
|
|
| [04 布局、绘制与输入](04-rendering.md) | 修改对象后如何刷新？点击如何回到同一个 VM？ |
|
|
| [05 桌面工作区](05-workspace.md) | 标签、原生窗口、默认页、开发工具如何配合？ |
|
|
| [06 当前进展](06-progress.md) | 已经做到什么？还有哪些限制？怎样复现？ |
|
|
| [07 设计决策](07-decisions.md) | 为什么使用这些边界？整理还没有解决什么？ |
|
|
| [逐文件整理清单](file-map.md) | 每个文件迁移到哪里、负责什么，本次拆出了什么？ |
|
|
|
|
UML 已渲染为普通 PNG 图片，直接嵌入各篇说明，不依赖 Mermaid 或 PlantUML 插件。需要放大可打开 SVG；八张图的图片、SVG 和可编辑源码集中在 [UML 图册](uml/README.md)。图像由本地脚本从 `.puml` 生成，不使用在线渲染服务。
|
|
|
|
|
|
|
|
[放大组件图 SVG](uml/rendered/components.svg)
|
|
|
|
## 先抓住四个概念
|
|
|
|
1. **对象是程序状态**：共享内容留在 Aster 管理的对象堆内；切换标签不靠重放源码恢复对象。
|
|
2. **Mount 是一次展示位置**：同一个 Block 可以在不同位置出现，每个位置有自己的几何、滚动和焦点上下文。
|
|
3. **Frame 是发布给窗口的值**：窗口收到命令、文本、标量 ID 等原生数据，不拿到 VM 堆引用。
|
|
4. **Page 和标签不是两套页面系统**：标签是托管 Page 的窗口侧投影；默认页也是 Endor Page。
|
|
|
|
## 本轮整理结果
|
|
|
|
`src` 的实现收进 `shell / runtime / model / render / bridge` 五个目录，根目录保留启动入口和源码导航。`api.rs` 从约 1800 行拆成请求处理、worker 与在线指南；`ui_bridge.rs` 从约 3450 行拆出画面树、签名、原生方法调用和类型初始化，主文件保留会话与展示刷新协调。
|
|
|
|
这些目录是**职责分组，不是已经隔离的五个 crate**。目前 model、bridge、render 仍有协作依赖，主窗口事件与 worker 之间也有协议耦合。根目录保留 crate 私有模块别名，让本次迁移不同时改写全部调用路径；详见设计决策。
|