我正在使用Core Text在iOS中创建自己的文本编辑器。几乎所有东西都有效，只有一个例外：当文本文档“大”时，东西真的开始变慢。我发现iOS正在请求每次更改的整个文档文本，包括选择更改（至少，当我通知UITextInputDelegate选择更改时）。部分问题在于我已经通过将文档拆分为段落并仅渲染更改的段落来优化我的核心文本代码。但这样做也会将文档字符串（NSAttributedString）拆分为单独的“段落对象”。因此，当iOS请求整个文本文档时，我必须将所有这些字符串组合成一个字符串，这需要时间和内存。
我的解决方案是为UITextPosition和beginningOfDocument方法提供不正确endOfDocument的iOS，将这些位置限制为与当前选择相交的段落。这实际上工作得很好。 iOS现在只请求更改的当前段落，这完全消除了减速。
到目前为止，这么好，但我有点担心这可能会破坏某些东西。我已经测试了一下，没有任何东西被打破，但是文本编辑器很难测试（谁知道它是否会在某些边缘条件下破坏）。
我有两个问题：
UITextInput协议方法中的某些其他方法可能会返回错误的值，从某种程度上导致iOS请求整个文档。答案 0 :(得分：0)
好吧，我已经测试了很长一段时间了，我终于找到了一个使用这种技术会打破功能的地方。 UITextInput使用beginningOfDocument和endOfDocument确定当您按蓝牙键盘上的箭头键时是否有“移动”的空间。仅返回当前所选段落的开头和结尾会导致它在该段落的开头或结尾处忽略“箭头”按钮，并且这些箭头表示尝试移出其认为是开头的/文件的结尾。这很容易修复。如果当前选择从段落的开头/结尾开始，我现在也分别返回上一个/下一个段落作为文档的一部分。