0

私はコアテキストを使用してiOSで独自のテキストエディタを作成しています。1つの例外を除いて、ほとんどすべてがうまく機能します。テキストドキュメントが「大きい」場合、スタッフは実際に速度が低下し始めます。私は、iOSが選択の変更を含むすべての変更でドキュメントテキスト全体を要求していることを発見しました（少なくとも、選択の変更をUITextInputDelegateに通知するとき）。問題の一部は、ドキュメントを段落に分割し、変更された段落のみをレンダリングすることで、CoreTextコードをすでに最適化していることです。ただし、これを行うと、ドキュメント文字列（はNSAttributedString）が個別の「段落オブジェクト」に分割されます。そのため、iOSがテキストドキュメント全体を要求する場合、それらすべての文字列を1つの文字列に結合する必要があり、これには時間とメモリがかかります。

私の解決策は、iOSにとメソッドに誤ったを与えUITextPosition、beginningOfDocumentそれらendOfDocumentの位置を現在の選択と交差する段落に制限することです。これは実際には非常にうまく機能しています。iOSは現在、変更の現在の段落のみを要求しているため、速度低下は完全に解消されています。

これまでのところ、とても良いですが、これが何かを壊すかもしれないのではないかと少し心配しています。私はこれを少しテストしましたが、何も壊れていませんが、テキストエディタはテストするのが難しい場合があります（エッジ状態で壊れるかどうかは誰にもわかりません）。

私は2つの質問があります：

  1. iOSは、変更のたびにドキュメントテキスト全体を要求する必要がありますか？そうでない場合は、おそらく私のUITextInputプロトコルメソッド内の他のメソッドが間違った値を返し、iOSがドキュメント全体を要求する原因になっている可能性があります。
  2. これが実際に何かを壊すかどうか誰かが知っていますか？
4

1 に答える 1

0

さて、私はこれをかなり長い間テストしてきましたが、ついにこの手法を使用すると機能が損なわれる場所を見つけました。 とをUITextInput使用して、Bluetooth キーボードの矢印キーを押したときに「移動」する余地があるかどうかを判断します。現在選択されている段落の最初と最後だけを返すと、それがその段落の最初または最後にあるときに「矢印」ボタンを無視し、それらの矢印は最初/ドキュメントの終わり。修正するのは簡単です。現在の選択範囲が段落の先頭/末尾から始まる場合、ドキュメントの前/次の段落もそれぞれ返すようになりました。beginningOfDocumentendOfDocument

于 2012-11-09T15:11:49.543 に答える