@OctWu 我只用text kit帮我留空白 至于图片是用imageview 还是自己画是无所谓的 我不用text kit画图片 因为那样不好控制 我只用text kit画文字和排版 你如果事先知道图片的尺寸 排版就很容易了

怎么什么都是最佳实践啊。。。。。可能跟你使用插件有关，xcode是挺难用的，不过并不会时不时地卡，启动之后需要让xcode做一些准备工作，然后就正常用了，偶尔会有奇怪的问题，但是卡顿很少有。

我是2010年的17寸mbp，没装任何插件，不过我使用ramdisk来放xcode生成的数据，不过源代码是存放在机械硬盘上的，ritina屏幕需要渲染的像素是普通屏幕的四倍，使用IB会有卡顿的可能

@OctWu

1.图片我的处理方法是创建nstextattachment的时候配置bounds属性，给一个非常大的width，比屏幕最大宽度还大，这样text kit就会把绑定图片的那个特殊字符单独放一行，排版完成之后使用layout manager找到图片的位置，然后再设置图片的frame来进行手动排版。之所以要这么做是因为parse html之后得到的只是一个url，在图片下载下来之前不知道图片到底有多大，索性就所有图片使用统一的缩略图尺寸，如果用户想要看一个图片的细节，点击图片之后会使用整个屏幕来单独显示图片，这时候就可以使用图片的原始尺寸。

2. 使用NSCache缓存解压缩过的图片，内存不够的时候NSCache会释放图片对象，只保留图片的url，我使用nsurlsession，这个会做缓存，图片数据会保存在硬盘上，用到的时候如果NSCache里找不到解压缩过的图片，那就重新下载图片，因为有缓存，所以不会从源再次下载，只需要从硬盘读取图片数据然后重新解压缩就可以了，实际效果挺不错的，Image I/O的性能非常出众，图片是很占内存的，必须使用缩略图，只有在需要的时候才会单独显示一张大的图片

我觉得你还是没有整明白text kit到底该怎么用，text kit是一个排版引擎，不是专门用来给text view渲染文字的。你问的这个问题很简单，text kit排版完成之后就可以得到版式相关的数据了，跟排版后的文字是否已经被渲染过没有关系。

你好好看看文档啊，不能指望网上的某个陌生人（v2ex上一个id为jox的家伙）每次在你遇到问题的时候都蹦出来回答你的问题吧？如果我半年才上一次或者对v2ex厌倦了不再上线了怎么办？你的这个问题看看文档很容易就能解决，首先把text kit的核心对象创建好并彼此连接，然后使用ensure....系列的方法强制layout manager进行排版，layout manager在这个过程中会生成字形，然后进行排版，排版完成之后使用boundingRect。。。。那个方法就可以得到某个字形的位置和尺寸。

好好看看文档，顺便了解一下文字的排版过程，相信对你理解text kit的用法会有帮助。不要再@我了，有问题直接去stackoverflow上去问，那个网站我每天都会上线，碰到我了解的问题我会回答的，为了在选择答案的时候的客观性，也别问我的stackoverflow的id了，v2ex这个网站不适合用来提问与回答技术类的问题。

得提供iOS的接口啊

这样做感觉很不错呀

@yellowV2ex 我早就放弃治疗了，嘿嘿，所谓死猪不怕开水烫就是我这样的了。

@yellowV2ex 哈，至今我连一个设计模式的名字都叫不上来，更不确定我是否会用~不过我还是可以写一些垃圾应用的

上这个网站我才意识到，很多人学习编程也许最大的障碍来自于他们不懂英文，懂英文的话就都很简单了。

@satanwoo ?

url encoding 并不

-
选择utf 8或者被（别）的编码方式对“字符”进行编码
-

这是错误的。url encoding真正在做的是将使用某种编码的byte序列进行百分号转换，这是wiki上的资料：

The generic URI syntax mandates that new URI schemes that provide for the representation of character data in a URI must, in effect, represent characters from the unreserved set without translation, and should convert all other characters to bytes according to UTF-8, and then percent-encode those values.

如果你需要传送utf 8编码的数据，在百分换转换之前byte序列如果已经是utf 8编码，只需要按照url encoding的规则做一次百分换转换就可以了，但如果在百分号转换之前不是utf 8序列你是不是要先转换成utf 8序列？

url encoding的规则对应的单元是一个byte，并不是一个字符，一个字符的长度可以是一byte，但是一byte不一定就是一个字符，一个utf 8字符最长可以达到6 bytes，url encoding的规则里没有任何一个规则是用来对字符进行编码的，我觉得你似乎没搞清楚字符和byte的差别。

也可以吧，类似Android的开屏幕锁的那个，touch到哪就把那个地方的照片勾上（如果有的话）。实现之后如果性能可以接受就应该没问题吧。但是如果是scroll view的话就比较麻烦了，iOS里没有内置的画框选择手势，iOS里选择都是用点击的，不像桌面系统，滚动操作和选择操作是分开的，你要想实现这种交互方式得把滚动手势和选择手势区分开来才行啊，可以借鉴table view的edit mode，当用户开启edit mode之后，移动手指就是选择，不能滚动。但这样也挺蛋疼，如果图片特别多，一个屏幕放不下，不滚动怎么选择？我觉得你得好好考虑一下。。。。。

记录touch开始的位置，跟踪touch的位置，touch的位置一变化就计算从起点到当前位置划出的rect与哪些照片的frame相交，把相交的图片勾上，如果没有就不动

@zzutmebwd 这个就看开发者怎么取舍了吧 看你把某个昵称的作用范围定为多大和你想拿@昵称用来干啥了 如果你说你要像微博那样拿一个昵称去@某用户 这个昵称既和发起@的用户没有任何联系同时还存在好多个用户拥有相同昵称 这是不能确定唯一的 同时这种功能也是没有意义的 但如果限定@昵称的作用范围就好办了 比如好友或者同一页面内的评论用户 如果作用域内存在重复 就捕捉用户的输入事件 提供个包含不同个体的菜单 用户必须在菜单内选择某选项@才会生效 否则就视为普通字符串

@dong3580 正则匹配文本的效率不会是问题，从头到尾挨个字符遍历一遍就行了，这个过程可以非常快，疯狂的快，快到让人受不了！现在大点儿的互联网公司，这种操作对他们的服务器来说简直就是可以忽略到使劲掐手指来形容“小”都无法描述出有多么微不足道的那种程度。

@dong3580 应该就是每个用户有个数据结构，类似队列那样的数据结构，被@的用户浏览某个或者某些特定的网页会消耗这个数据结构里的item，比如v2ex只有点开提醒那个页面才会消灭这些提醒，如果用户永远不点开，那么这个数据结构里的item就永远都不会消耗，伴随着用户直到他死去。每个item有自己的数据结构，里面可以保存url之类的数据，至于前端怎么展示，那就是前端的问题了，后端的逻辑应该就是这样的。

@dong3580 他们大概会做严肃的分析吧，也可能不会。我看新浪微博如果是 @@用户名 这样的是不会触发提醒的，也可能他们只是做简单的正则匹配，反正这个东西无所谓的吧，因为如果匹配失败的话发出去的微博就是普通的字符串，用户看见了就知道失败了，如果需要重新@的话就让用户重新弄一遍，我觉得没什么，正则匹配应该就够用了，性能方面也不是问题。腾讯微博我不知道，我因为最近开始使用v2ex才去申请了个新浪微博作为图床。

如果需要验证并且需要严肃处理的话，需要分析字符串，然后用语法规则匹配，匹配得到结果之后验证是否是有效的账户，是的话选择高亮并进入提醒逻辑，不是的话就不管。

如果用户不是很多，也不用考虑验证的问题，直接简单粗暴地用正则表达式去匹配，得到结果就进入提醒逻辑，否则就不管

lz居然会问这种问题，开发iOS想必也会遇到很多困难吧？

第一个问题，自己检索。
第二个问题，语法高亮需要使用相关的javascript插件，你需要分析obj c，然后使用不同的颜色渲染不同的语法单元，网上这类插件很多
三、四、五，我没明白你是啥意思。

要我说，blog就是在互联网上（准确地说是某台通过互联网能够稳定连接的电脑）存的字符串列表，同时你希望别人看到这些数据，最重要的就是数据展示的可读性以及数据的质量，要么你的数据很有娱乐性，比如连载小说，笑话或者美女或者色情图片啥的，要么你的数据的含有高质量的专业信息，能让人从中学到东西，其他的都是无关紧要的。

现在浏览器这么先进，如果使用osx，直接cmd+L就可以在浏览器的地址栏里检索关键词了，你在你的博客站上整个搜索栏别人还得去找然后拿鼠标去点，有意思吗？还有那个category，我不知道你整那个干啥，你如果想要分享数据给英文读者，何不直接另开一个英文的博客站？手机那个，你自己都觉得不重要，那还拿出来说干啥，这不是扯淡呢么？

这个网站上有太多你这样的人了，净整一些没用的

怎么会这样？愁人

@jsq2627 空格会被替换成+，+和非保留字符是不会使用%HH格式来编码的。非保留字符集包括:

. - _ ~ a-z A-Z 0-9

另外w3schools.com这个网站并不是w3c官方的网站，虽然上面的资料很有用，但是有些资料是有误的，还是得看w3c上面的规格以及RFC，嘛，不过w3c感觉就是在打酱油，最终还是各大厂商在主导。

@dopcn url encode不用utf 8来编码字符，url encode只是将字符串里的除保留字符和非保留字符以外的其他字符的byte转化成%HH的格式，HH是该byte的utf-8码，很容易得到的一个例子：空格的utf 8码U+0020，但是百分号转换，即url encoding，之后是'+'，字符串“a b c”经过url encoding之后是"a+b+c"，二进制数据是十六进制码“0061002B0062002B0063”，使用utf 8编码之后的二进制数据是十六进制码"00610020006200200063"，这是完全不同的，如果是中文经过url encoding之后区别就更大了，因为多了个%，你把一个字符串经过url encoding之后再使用utf 8来解码将得不到原来的字符串。

satanwoo 的说法是错误的