我需要了解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 7创建文本编辑器全部内容,希望文章能够帮你解决为iOS 7创建文本编辑器所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)