Texture 技术路线图全解读：以四大核心品质驱动的 iOS 异步 UI 框架演进规划-平芜编程栈

移动开发
UI组件

【免费下载链接】Texture

Smooth asynchronous user interfaces for iOS apps.

项目地址：https://gitcode.com/gh_mirrors/te/Texture

Texture（原 AsyncDisplayKit）是一套面向 iOS 的平滑异步 UI 框架，其官方路线图并非简单罗列版本号与功能清单，而是以框架的"四大核心品质"（Reliable、Familiar、Lean、Bold）为决策基准，分 2.1 与 2.5+ 两个阶段规划演进方向。本文以 docs/_docs/roadmap.md 为骨架，结合仓库内 principles.md、Layout Transition API 文档与源码实现，逐条拆解路线图各项规划的含义、动机与当前源码落点，帮助读者理解 Texture 的设计哲学，并掌握其布局过渡 API、实验特性开关等核心能力的实际用法。

一、路线图的制定逻辑：四个关键词定义 Texture 的北极星

路线图开篇即说明：Texture 是一个快速演进的项目，由一个精干的核心团队维护，因此这份路线图会随时间变化，并非刚性承诺。真正驱动路线图内容的，是框架的四大核心品质，其完整定义位于 docs/_docs/principles.md：

品质	核心诉求	落地方式
Reliable（可靠）	行为与文档一致，生产环境不崩溃，即使被误用	有意义的、稳定的单元测试，投入大量资源建设测试
Familiar（熟悉）	接口尽量贴近 UIKit、CSS 等行业标准；偏离标准时也要直观直接	与其他成熟框架对比 API，开发新 API 时向用户征集反馈，慷慨地提供抽象层（前提是不牺牲 Reliable）
Lean（精简）	速度与内存占用行业领先，API 简洁，实现代码短小有序	审视每行代码的性能影响，持续重构，构建并暴露性能指标工具
Bold（大胆）	定期加入雄心勃勃的功能，如动画布局过渡、可见度深度系统	提出疯狂的想法并把它推进到工作流中，为其分配资源

这四条品质回答了路线图中每个条目的"为什么"：每一项规划都应当让框架更可靠、更熟悉、更精简或更大胆。理解了这一点，下文 2.1 与 2.5+ 的条目就不再是零散愿望清单，而是一套有内在逻辑的演进纲领。

二、2.1 版本规划：巩固熟悉度、拥抱声明式 API

2.1 版本规划聚焦于Familiar与Bold两个象限，即"让现有用户更顺手"与"推出令人兴奋的新范式"双线并行。

2.1 · Familiar：让 UIKit 工程师零门槛迁移

2.1 的 Familiar 类目包含三项规划：

逐步加大 Swift 投入（Increase investment in Swift over time）。Texture 的源码主体是 Objective-C（如 Source/ASDisplayNode.h），但文档示例（见 layout-transition-api.md）均提供 Swift/Objective-C 双语版本，说明 Swift 友好度一直是接口设计的关注点。路线图明确把它列为长期投入方向。
采用更规律的发布节奏（Adopt a more regular release cadence）。对照仓库根目录的 CHANGELOG.md 可以看到，项目历史上存在大跨度发布（如 2017-10 的 2.5.1 与 2018-05 的 2.7 之间隔了数月），规律化发布正是为了缩短用户等待新特性与修复的时间。
为 Layout Transition API 提供可逆的 0-100% 过渡（Reversible 0-100% transitions）。这是对布局过渡能力的关键增强：当时的过渡是单向的（从旧布局过渡到新布局），规划中希望过渡进度可以在 0% 到 100% 之间自由往返，为手势驱动的布局过渡铺路。

2.1 · Bold：声明式 Collection Node API

2.1 唯一的 Bold 条目是声明式 Collection Node API（Declarative collection node API）。这是对当时以ASCollectionNode+ 数据源/委托回调为主的命令式编程模型的一次范式升级：让开发者直接描述"数据长什么样"，由框架推导出增删改与布局，而不是手写cellForItemAtIndexPath式的样板代码。路线图原文附有"Try it out"占位链接（原文链接为空），说明该能力在写作时仍处于征集反馈的早期形态。值得注意的是，仓库中确实存在与之配套的抽象，例如 Source/ASCollectionNode.h 以及ASCollectionFlowLayoutDelegate等布局委托类（见 Source/Details/ASCollectionFlowLayoutDelegate.h），可视为向声明式方向演进的底层支撑。

三、2.5+ 版本规划：四大象限的长期投入

2.5+ 阶段横跨全部四个品质象限，代表更长远的技术方向。

Reliable：审计排版特性

Audit typography features（审计排版特性）。TextKit 排版是 Texture 文本能力的根基，仓库中 Source/TextKit 目录包含ASTextKitAttributes、ASTextKitRenderer、ASTextKitTruncating等十余个排版相关类。所谓"审计"，即系统性地核查这些排版特性（字距、断行、截断、字重调整等）的行为正确性与一致性，属于典型的 Reliable 投入——不新增功能，先确保已有功能经得起生产环境检验。

Familiar：更好的 Supplementary Node 支持

Better supplementary node support（更好的补充节点支持）。在 UICollectionView 生态中，supplementary view（header/footer/装饰视图）是标准能力。Texture 当时已通过ASSectionContext、ASCollectionElement等类支持补充节点（见 Source/Details/ASCollectionElement.h），路线图规划的是进一步对齐 UIKit 的使用体验，降低接入成本。

Lean：真正的异步布局

True asynchronous layout（真正的异步布局）。这是 Lean 象限最核心的一条。需要澄清的是，当前版本已经支持异步测量，但"真正的异步布局"仍属规划：transitionLayoutWithAnimation:等 API 的shouldMeasureAsync参数可保证测量发生在后台线程（见下文源码分析），而整棵布局树的构建、提交与应用仍要回到主线程。路线图设想的终极形态是让布局过程整体脱离主线程，从而把主线程时间片几乎全部让给交互与渲染。

Bold：三箭齐发

2.5+ 的 Bold 类目包含三条：

Layout Transition API 的一等公民过渡（First class transitions）：将布局过渡从"手动写动画"提升为框架内置的、开箱即用的动画能力，配合默认过渡时长、延迟与动画选项属性（defaultLayoutTransitionDuration/defaultLayoutTransitionDelay/defaultLayoutTransitionOptions，见 Source/ASDisplayNode.h）。
极致可调试性（Extreme debuggability）：让开发者能直观看到"节点在做什么、为什么慢"。仓库中已有对应的工具积累：ASDisplayNode+DebugTiming（Source/Private/ASDisplayNode+DebugTiming.h）、tips 提示系统（Source/Debug/AsyncDisplayKit+Tips.h），以及文档目录中的调试指南（如 docs/_docs/debug-tool-ASRangeController.md、docs/_docs/debug-tool-hit-test-visualization.md）。
AsyncKit?（带问号的猜想）：原文以问号结尾，说明这只是一个探索性方向——即把 AsyncDisplayKit 的异步渲染内核抽离为更通用、可复用的底层库。写作时它尚未形成明确方案，属于"大胆设想"的典型代表。

四、从路线图到源码：布局过渡与实验特性的实现落点

路线图反复提及 Layout Transition API，它是连接 2.1（可逆过渡）与 2.5+（一等公民过渡）两条规划的核心主线。以下结合源码说明其当前实现形态，这既是理解路线图的钥匙，也是可直接用于实战的 API。

4.1 Layout Transition API 的现状与用法

Layout Transition API 的核心目标在 docs/_docs/layout-transition-api.md 中有精确定义：你只需要指定目标布局，Texture 自动计算新旧布局差异，自动添加新节点、在过渡后移除不需要的节点、更新已有节点的位置。其前置条件是启用 Automatic Subnode Management——由框架根据layoutSpecThatFits:的结果自动增删子节点。

API 全部集中在ASDisplayNode (ASLayoutTransitioning)分类中（Source/ASDisplayNode.h），核心方法如下：

方法	作用	线程要求
`transitionLayoutWithAnimation:shouldMeasureAsync:measurementCompletion:`	以当前`constrainedSize`失效并重算布局，可选异步测量	主线程
`transitionLayoutWithSizeRange:animated:shouldMeasureAsync:measurementCompletion:`	以新的`ASSizeRange`重算布局；若传入 size range 与当前相同则 no-op，适合旋转等尺寸变化场景	主线程
`cancelLayoutTransition`	取消所有进行中的布局过渡	任意线程
`animateLayoutTransition:`（可重写）	执行自定义动画；此时新节点已插入，可在此调整层级	主线程
`didCompleteLayoutTransition:`（可重写）	过渡完成后的清理；移除操作在此发生	主线程

一个典型用法——切换注册表单的字段并带动画过渡（摘自 layout-transition-api.md 的 Objective-C 版本）：

// 1. 更新驱动布局的状态 self.signupNode.fieldState = SignupNodeAge; // 2. 触发布局过渡（异步测量，随后回调 animateLayoutTransition:） [self.signupNode transitionLayoutWithAnimation:YES shouldMeasureAsync:YES measurementCompletion:nil]; // 3. 在子类中重写动画，借助 ASContextTransitioning 读取新旧 frame - (void)animateLayoutTransition:(id<ASContextTransitioning>)context { if (self.fieldState == SignupNodeName) { // 从 context 取初始/最终 frame，配置出场与入场动画 [UIView animateWithDuration:0.4 animations:^{ self.nameField.frame = [context finalFrameForNode:self.nameField]; self.nameField.alpha = 1.0; self.ageField.frame = [context finalFrameForNode:self.ageField]; self.ageField.alpha = 0.0; } completion:^(BOOL finished) { // 关键：动画结束必须调用 completeTransition:， // 新布局才会成为当前 calculatedLayout [context completeTransition:finished]; }]; } }

从源码看，transitionLayoutWithAnimation:只是对transitionLayoutWithSizeRange:的封装——它取当前_constrainedSizeForLayoutPass作为 size range 转发（Source/ASDisplayNode+Layout.mm），而transitionLayoutWithSizeRange:内部会校验传入尺寸非法值（max 宽高 <= 0）并走ASLayoutTransition流程（Source/Private/ASLayoutTransition.mm）。ASLayoutTransition使用 BFS 遍历整棵布局树，判断是否存在无法异步布局的节点（例如已加载视图的节点），以决定过渡能否在后台完成（见该文件开头的ASLayoutCanTransitionAsynchronous函数）。过渡期间必须调用completeTransition:，因为旧布局的移除操作发生在didCompleteLayoutTransition:阶段。若要处理"非动画"情形，可检查[context isAnimated]并回退到[super animateLayoutTransition:context]。

完整的可运行示例位于 examples/ASDKLayoutTransition（Podfile 项目），适合作为实战起点。

4.2 实验特性机制：Bold 想法的"灰度通道"

路线图中诸多 Bold 设想（新渲染路径、新的数据控制器管线等）在仓库中体现为一套实验特性开关机制，这是"大胆而不失控"的工程化保障：

开关位定义在 Source/ASExperimentalFeatures.h，从ASExperimentalTextNode（新文本节点）到ASExperimentalCheckBatchFetchingOnScroll共 17 个实验位，并提供名称与位掩码互转的辅助函数；
配置 schema 定义在 Schemas/configuration.json，包含version与experimental_features数组，数组元素为exp_text_node、exp_interface_state_coalesce等字符串枚举；
集中式配置 API 位于 Source/ASConfiguration.h，开发者可在 App 启动时注入配置，通过 delegate（Source/ASConfigurationDelegate.h）在特性启用/禁用时获得回调。

这套机制允许框架团队把尚未完全定型的能力以"实验"形态发布到生产环境，收集真实数据后再决定转正或回滚——正是路线图"定期加入雄心勃勃功能"的执行层设计。

4.3 可调试性方向的现有积累

"极致可调试性"同样已有雏形：ASDisplayNode+DebugTiming记录各阶段耗时（Source/Private/ASDisplayNode+DebugTiming.mm），tips 系统（Source/Debug/AsyncDisplayKit+Tips.mm）在开发期直接提示使用误区，配合ASRangeController调试工具文档（docs/_docs/debug-tool-ASRangeController.md），构成了从"性能剖析"到"行为纠错"的调试链条。

五、路线图是动态文档：与当前版本的对照

路线图在开头就声明"会随时间变化"，仓库现状印证了这一点：根目录 CHANGELOG.md 显示项目已发布到 3.2.0（2024-05-21），历经 2.6、2.7、2.8、3.0 等多个版本。对照可见：

文档规划的"更规律的发布节奏"在 2.5 之后确实得到执行，3.x 系列形成持续迭代；
文档与 API 的 Swift 支持持续增强，多数核心接口均提供 Swift 版本；
部分"规划中"的能力以实验特性形态先行落地（见上文 4.2）；
而**"可逆 0-100% 过渡""真正的异步布局""AsyncKit?"等条目至今仍是探索性方向**——这正符合路线图"非刚性承诺、随项目演进调整"的定位。读者在参考本路线图时，应以 CHANGELOG.md 与源码现状为准判断能力是否已落地。

六、如何参与：路线图不是少数人的私事

路线图结尾给出了明确的参与路径，这也是理解该项目治理模式的一部分：

在 GitHub、Slack 与 Twitter 上与社区建立连接；
审查文档：提交或建议改进 docs 目录下的文档（例如 docs/_docs/development/layout-transitions.md 仍标注"Under construction"，正是可以贡献的空白地带）；
分享使用 Texture 的实践经验；
贡献布局示例：仓库的 examples 目录已积累大量布局示例，新增示例可直接帮助后来者；
贡献代码：认领标记为"Needs Volunteer"的 issue。

结语

Texture 的路线图之所以值得细读，在于它把"可靠、熟悉、精简、大胆"四条品质变成了可执行的版本规划：2.1 侧重让现有开发者更顺手（Swift、发布节奏、可逆过渡），2.5+ 则同时押注排版审计、补充节点、真异步布局与声明式能力。而仓库源码告诉我们，这些规划并非空中楼阁——Layout Transition API 已具备完整的测量-过渡-提交闭环，实验特性机制为 Bold 想法提供了安全的灰度通道，调试工具链也在向"极致可调试性"持续演进。理解这份路线图，等于同时理解了 Texture 的现在与它为自己设计的未来。