0

我正在使用 Core Text 在 iOS 中创建自己的文本编辑器。几乎所有东西都很好，除了一个例外：当文本文档“大”时，东西真的开始变慢。我发现 iOS 在每次更改时都请求整个文档文本，包括选择更改（至少，当我通知 UITextInputDelegate 选择更改时）。部分问题是我已经优化了我的核心文本代码，将文档拆分为段落并仅呈现更改的段落。但是这样做也会将文档字符串（即 a NSAttributedString）拆分为单独的“段落对象”。因此，当 iOS 请求整个文本文档时，我必须将所有这些字符串组合成一个字符串，这需要时间和内存。

我的解决方案是为 iOS 提供不正确UITextPosition的 'beginningOfDocument和endOfDocument方法，将这些位置限制在与当前选择相交的段落中。这实际上工作得很好。iOS 现在只请求更改当前段落，这完全消除了减速。

到目前为止，一切都很好，但我有点担心这可能会破坏某些东西。我对此进行了一些测试，没有任何问题，但是文本编辑器可能很难测试（谁知道它是否会在某些边缘条件下中断）。

我有两个问题：

  1. iOS 是否应该在每次更改时请求整个文档文本？如果不是，那么可能是我的协议方法中的其他方法UITextInput返回了错误的值，从而导致 iOS 请求整个文档。
  2. 有谁知道这是否真的会破坏任何东西？
4

1 回答 1

0

好吧，我已经对此进行了一段时间的测试，我终于找到了一个使用这种技术会破坏功能的地方。 UITextInput使用beginningOfDocument和endOfDocument确定当您按下蓝牙键盘上的箭头键时它是否有空间“移动”。仅返回当前所选段落的开头和结尾会导致它在该段落的开头或结尾处忽略“箭头”按钮，并且这些箭头表示试图移出它认为的开头/文件的结尾。很容易修复。如果当前选择从段落的开头/结尾开始，我现在也分别返回上一个/下一个段落作为文档的一部分。

于 2012-11-09T15:11:49.543 回答