为iOS 7创建文本编辑器

前端之家收集整理的这篇文章主要介绍了为iOS 7创建文本编辑器前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
问题

我需要了解TextKit的工作原理,以及如何使用它来构建文本编辑器.我需要弄清楚如何仅绘制最终用户与之交互的可见文本,或者确定如何将属性延伸到可视文本中,而不是在processEditing方法中对整个更改的文本范围应用属性.

背景

iOS 7出来了TextKit.我有一个完全实现TextKit的tokenizer和代码(参考Apple的TextKitDemo项目 – 下面提供了一个链接)…它的工作原理.但是,它真的很慢.当文本被解析时,由NSTextStorage,它需要您在同一个线程上将editEditing方法中的编辑文本的ENTIRE范围进行着色.将工作卸载到线程没有帮助.这太慢了我得到了我可以重新归类修改的范围的点,但是如果范围太大,则过程将会很慢.在某些情况下,整个文档可能在更改后无效.

这里有一些想法.请让我知道,如果有任何这些工作,或者可能推动我正确的方向.

1)多个NSTextContainers

阅读文档,我可以在NSLayoutManager中添加多个NSTextContainers.我假设通过这样做,我应该能够定义不仅可以在NSTextContainer中绘制的行数,而且我还应该能够知道最终用户可以看到哪个NSTextContainer.我知道如果我去这条路线,我需要投入大量的时间来看看是否可行.初始测试表明您只需要一个NSTextContainer.所以我必须对NSLayout进行子类化,或者创建一个包装器,其中布局管理器确定哪个文本在哪个文本容器中.呸.此外,我不知道TextKit如何让我知道是时候画一个特定的NSTextContainer …也许这不是它的工作原理!

2)无效的范围与NSLayoutManager

无效的layoutManager使用invalidateLayoutForCharacterRange:actualCharacterRange :.但是,这实际上是做什么的,如何卸载文本归属阶段?什么时候让我知道一个特定的文本需要突出显示?另外,我看到NSLayoutManager会懒洋洋地画字形…怎么样?什么时候?这如何帮助我?如何点击这个调用,以便我可以在支持字符串实际放置文本之前对其进行归属?

3)超越NSLayoutManager drawGlyphsForGlyphRange:atPoint:方法.

我真的不想这样做话虽如此,在Mac OS X中,NSAttributedStrings具有临时属性的概念,其中样式信息仅用于呈现.这加快了突出重点的过程!问题是,它在iOS 7 TextKit框架中不存在(或者它在那里,我只是不知道).我相信,通过超越这种方法,它将给我相同类型的速度,你会得到使用临时属性…因为我可以回答所有的布局,颜色和格式化问题在这种方法,而不用触摸NSTextStorage归因串.唯一的问题是,我不知道这个方法如何与NSLayoutManager类中提供的其他方法相关.它是否保持宽度和高度的状态?当NSTextContainer太小时会修改它的大小吗?此外,它只为文本缓冲区中添加的字符绘制字形.它不会重绘整个屏幕.只有它的一小部分…这是非常好的.我有一些想法,我可以如何工作这个…但我真的不想排列字形.这是太多的工作,我没有找到一个很好的例子,这样做.

我非常感谢您提供的任何帮助.

感谢您,我列出了过去几年中使用过的所有框架和参考资料,帮助我了解了现在我希望他们对您有所帮助.

语法高亮框架:

> http://colorer.sourceforge.net/
> https://github.com/MikeJ1971/Glint(不支持字符串,注释等)
> https://projects.gnome.org/gtksourceview/features.html(为令牌生成提供了一个体面的lib),与GTK配合使用,但可能会为不同的布局管理员重新编写)
> http://parsekit.com/(很好的解析器,但是,当需要修复范围时,必须打包API来创建状态机)
> http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/LanguageKit/
> https://github.com/CodaFi/IDEKit(AMAZING工作,这个代码中有很多好的想法,我的问题是我完全不知道它如何修复范围,甚至是这样)
> http://www.crimsoneditor.com/(一个旧的Windows代码编辑器,它有一个非常好的tokenizer – 虽然有点难以阅读,它不使用正则表达式,也就是说,我基于我的令牌逻辑从这个代码,它是更快比上述任何框架)

资源:

> http://cocoafactory.com/blog/2012/10/29/how-to-use-custom-nsattributedstring-attributes/
> https://github.com/objcio/issue-5-textkit
> http://alexgorbatchev.com/SyntaxHighlighter/
> http://docs.xamarin.com/samples/TextKitDemo/(Apple的演示)
> http://cocoadev.com/ImplementSyntaxHighlighting(一定要阅读所有的小孩子文章,好东西)

大多数框架是相同的.他们或者不考虑上下文切换(或者你必须编写包装器以提供上下文)范围,或者当用户修改文本(例如字符串,多行注释等)时,它们不会修复上下文范围.最后一个要求是非常重要的.因为如果一个记分器不能确定哪个范围受到一个变化的影响,那么你最终将必须解析并再次对整个字符串进行归属.唯一的例外是Crimson Editor.该标记器的问题是它不会在标记化时保存状态.在绘制时,算法使用令牌来确定绘图状态.它从文档的顶部开始,直到它到达可见的文本范围.不用说,我通过在文档的某些部分缓存文档的状态来优化.

另一个问题是框架不符合Apple所做的相同MVC模式 – 这是预期的.具有完整工作编辑器的框架都使用由它们构建的API(即GTK,Windows等)提供的钩子,为他们提供何时以及何时绘制到屏幕的哪个部分的信息.在我的情况下,TextKit似乎要求您在processEditing中归因整个更改的范围.

也许我的观点是错误的. (我希望他们是!!)也许,例如ParseKit,将为我需要做的工作,我根本不明白如何使用它.如果是这样,请让我知道!再次感谢

解决方法

我想到了.我没有使用上面的建议.话虽如此,我现在得到的表现是令人难以置信的.请记住,YMMV.标记和缓存有关字符串的元数据的方式可能与我不同.但是,我可以输入一个1400行的PHP文件,只需0.015秒即可完成任何一个更改.简直令人难以置信

这是我采取的方法

我的UIViewController是UITextViewDelegate和UIScrollViewDelegate的委托.

当UITextViewDelegate.textViewDidChange:被调用时,我确定最终用户当前可以看到哪个文本范围.我通过使用我现有的分类的UITextView来添加这个方法

- (NSRange)visibleRangeOfText
{
    CGRect bounds = self.bounds;
    UITextPosition *start = [self characterRangeAtPoint:bounds.origin].start;
    UITextPosition *end = [self characterRangeAtPoint:CGPointMake(CGRectGetMaxX(bounds),CGRectGetMaxY(bounds))].end;
    return NSMakeRange([self offsetFromPosition:self.beginningOfDocument toPosition:start],[self offsetFromPosition:start toPosition:end]);
}

之后,我将范围传递给子类的NSTextStorage对象,然后它将执行魔术来确定哪些行需要突出显示.

UIScollViewDelegate方法调用也一样.根据视图的哪个部分,我将可见范围传递到我的子类NSTextStorage调用,并确定行是否已被归因等.

我意识到我要留下很多读者.我最终使用了我目前所做的,并调整了一些工作与上述实现.

我想分享一些我发现有趣的发现:

1)如果您尝试突出显示当前行中的任何文本,光标所在的位置,您可能会看到光标在视图中“跳转”,然后返回到原始位置.我几乎是积极的,这是由NSTextStorage.processEditing方法调用引起的.我能够把它弄到哪里,系统只突出显示修改的行,所以这个问题现在已经不复存在了.

2)最初我这样做是为了防止光标跳动:

NSRange selectedRange = [textView selectedTextRange];
[textView setScrollEnabled:NO];
NSRange visibleRange = [textView visibleRangeOfText];
[textStorage applyAttributesToRange:visibleRange];
[textView setScrollEnabled:YES];

它工作…但是[textView setScrollEnabled:NO]调用性能有很大的影响.这个命令单独花了近3/4的时间才能完成1400线文件.我不知道是什么原因是缓慢,但我认为值得一提.

猜你在找的iOS相关文章