四年前，苹果在WWDC21大会上高调发布了TextKit 2（NSTextLayoutManager）API，这个被寄予厚望的文本布局引擎承诺将取代老旧的TextKit 1（NSLayoutManager），提供更简单、更快速、整体更优秀的API。
作为一名深耕macOS/iOS文本处理领域多年的开发者，Marcin Krzyżanowski最初对TextKit 2充满热情，甚至基于它开发了STTextView项目——一个为macOS（AppKit）和iOS（UIKit）重新实现的TextView组件。然而经过四年的实践，作者发现这个"银弹"技术远非完美，在某些场景下甚至可能不是合适的工具选择。
架构理想与实现缺陷
理论上的优雅设计
TextKit 2的架构设计确实有其精妙之处。它采用了渐进式复杂度的抽象模型，各个组件分工明确：NSTextContentManager作为布局引擎的抽象接口，NSTextLayoutManager负责文本布局，NSTextViewportLayoutController管理视口优化。这种分层设计理论上允许开发者灵活替换各个模块，实现高度定制化的文本处理流程。
实践中的刚性限制
然而在实际使用中，这种理论上的灵活性几乎不存在。NSTextContentManager虽然被设计为抽象接口，但实际上只有NSTextContentStorage这一个官方实现可用。更令人沮丧的是，NSTextContentStorage底层仍然依赖于老旧的NSTextStorage，这意味着TextKit 1时代的所有存储问题都被继承到了TextKit 2中。这种实现方式使得UITextView/NSTextView根本无法脱离NSTextContentStorage工作，严重限制了框架的扩展性。
在文本元素处理方面同样存在这种矛盾。虽然API设计了NSTextElement作为基础抽象，但实际可用的只有NSTextParagraph这一种实现。任何尝试创建自定义文本元素的开发者都会遭遇运行时断言错误。这种表面开放实则封闭的设计模式，暴露出TextKit 2本质上只是为系统原生UITextView服务的本质，与其宣称的通用文本引擎定位相去甚远。
视口管理的双刃剑
视口优化的设计初衷
TextKit 2引入的视口（viewport）概念确实是一项创新设计。其核心理念是通过仅对可见区域进行文本布局，大幅减少内存占用和计算开销。当用户滚动文档时，视口会动态移动，系统智能地管理缓存、区间和无效范围，确保流畅的滚动体验同时保持高效性能。这种机制理论上可以让开发者无需关心整个文档布局，只需聚焦当前显示内容。
实际应用中的棘手问题
但在真实场景中，视口优化却成为了噩梦的开始。由于文档非可见区域仅进行估算布局，导致NSTextLayoutManager.usageBoundsForTextContainer返回的文档总高度值极不稳定。在滚动过程中，这个估算值会频繁发生剧烈波动，直接反映为滚动条位置的"抖动"现象。虽然苹果官方论坛确认这是"符合设计"的行为，但这种体验在文本编辑器等对稳定性要求高的场景中完全不可接受。
更糟糕的是跳转文档末尾的操作。开发者首先需要获取一个可能严重失真的估算高度，然后调整视图内容尺寸，强制对文档末尾进行布局，再将视口定位到估算位置。这一系列操作后，滚动条位置往往仍然不准确。目前唯一的"解决方案"是通过不断人工调整视口位置来掩盖问题，但这种做法极其脆弱且难以完美实现。
讽刺的是，就连苹果自家的TextEdit应用也饱受同样问题困扰。在特定操作下，TextEdit会出现明显的布局错乱和滚动异常，这充分证明即使是苹果第一方团队也难以完美驾驭TextKit 2的视口管理机制。
稳定性与兼容性挑战
层出不穷的布局缺陷
除了视口问题外，TextKit 2还存在大量影响实际使用的bug。作者报告中提到的"额外行片段"（extra line fragment）布局错误尤为典型——这是文本编辑器在文档末尾处理换行时必不可少的特性。更令人担忧的是版本兼容性问题，某些bug只在特定系统版本出现，而修复后又可能在新版本中复发，给开发者带来沉重的适配负担。
响应迟缓的修复周期
苹果对已报告问题的处理速度也令人失望。许多关键bug报告长期得不到回应，部分问题虽然被标记为已修复，但在实际测试中仍然存在。这种状况迫使开发者不得不自行寻找workaround，进一步增加了开发成本。
谨慎的技术选型
经过四年的实践验证，TextKit 2展现出的真实面貌与其最初承诺相去甚远。虽然其架构设计理念先进，但实现质量和使用体验却难以令人满意。特别是在文本编辑器这类对稳定性和精确性要求极高的场景中，TextKit 2的视口估算机制和布局缺陷成为了难以逾越的障碍。
对于正在评估文本技术的开发者，作者的建议是保持谨慎态度。如果你的项目需要高度可靠的文本布局，特别是涉及复杂编辑功能时，可能需要重新考虑TextKit 1或其他解决方案。当然，我们也期待苹果未来能够改进TextKit 2的实现质量，使其真正成为文本处理领域的"应许之地"。在此之前，开发者们可能还需要在理想与现实之间继续寻找平衡点。