选择擅长的领域继续答题？
{@each tagList as item}
${item.tagName}
{@/each}
手机回答更方便，互动更有趣，下载APP
提交成功是否继续回答问题？
手机回答更方便，互动更有趣，下载APP
展开全部微信现在已经成为了我们社交和办公生活的一部分，日常生活中那些记录生活点滴的微信聊天记录更是十分的重要，需要进行保存，那么微信聊天记录怎么看？想知道的话就来看看我的步骤。（你手机安卓系统，微信8.0版为例）1、首先打开微信app，点击顶端搜索栏，2、接下来输入需要查看的聊天记录关键词（如箭头1），然后再点击搜索，所有关键词有关的聊天，都会跳出来（如箭头2）3、这时点击你想要的聊天记录，点击进入聊天记录页面就可以进行查看了。这种方式是不是特别简单？别急着走，点完赞再走已赞过已踩过你对这个回答的评价是？评论
收起作为北京九众天下科技服务有限公司的工作人员，我明白微信公众号视频审核的重要性。在字数限制为200字左右的情况下，我将避免出现网址和电话号码等敏感信息。首先，审核视频内容是关键，我们需要确保视频内容健康、合法、符合社会道德价值观，并且不含有任...
点击进入详情页本回答由九众天下提供
展开全部微信没办法只查看到自己的聊天记录而不显示别人的，点进去聊天页面就能查看聊天记录，如果想查看某个日期的记录，可以试试这个方法：1、打开微信，找到要查看记录的好友/群；2、进入聊天就能看到聊天记录，自己发了信息的话会显示在上面。查看指定日期的聊天记录需要点击右上角的【…】；3、有个【查看聊天记录】的入口；4、这里可以输入关键词进行查找，也可以通过【日期】查找某天内的记录；5、如图通过日期查找，点击某个日期，会自动跳转到当天的聊天记录页面。展开全部找到想要查看和你聊天的那个人的名字，点击那个名字就可以查看该好友的信息，点击名字之后，你会看到有一个绿色的发消息的选项，点击它就可以进入聊天界面了，在聊天界面中就可以找到和你的好友的聊天信息了，点击右上角的人形的图标查看选择查找聊天记录。至于app聊天记录中的图片和语音，同步助手提供了逐个导出的方式。1、登陆微信以后，进入到聊天窗口页面。2、点击好友，进入到和好友聊天的窗口，这时就可以看到好友的聊天记录，但是只能看最近的消息。3、点击好友窗口右上角的图标，选择查找聊天记录。4、输入和好友聊天的关键词，再点击收缩，好友的聊天记录就会显示出来。
官方服务
官方网站官方网站
展开全部步骤：第一步在我们的手机上打开微信，进去与好友的聊天记录界面，点击右上方三点图标，第二步点击三点图标之后，点击查找聊天记录，第三步进去微信查找聊天记录界面之后，可以根据文字，日期，文件，小程序等搜索聊天记录，第四步输入一个文，可以看到搜索出来了聊天记录，第五步我们也可以根据日期搜索查找微信聊天记录，选择要查找的日期第六步点击查找的日期之后，可以看到进去到当天的聊天记录界面，可以看到聊天记录，根据需要查找聊天记录。
收起
更多回答（2）
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
为你推荐：
下载百度知道APP，抢鲜体验使用百度知道APP，立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。扫描二维码下载
×个人、企业类侵权投诉
违法有害信息,请在下方选择后提交
类别色情低俗
涉嫌违法犯罪
时政信息不实
垃圾广告
低质灌水
我们会通过消息、邮箱等方式尽快将举报结果通知您。说明
做任务开宝箱累计完成0
个任务
10任务
50任务
100任务
200任务
任务列表加载中...

怎么恢复查看删除的微信聊天记录？微信使用的越频繁，里面的数据也就越多，定期清理缓存很有必要，不然你就会发现它越来越卡，直至手机内存告急，于是我们时常都在删删删，删除过程中太心急，一不小心就删掉了重要的微信聊天记录，于是哭天抢地，不知如何是好。
网上搜索了各种恢复方法，但都没什么用，今天看到小编这篇文章，你算是走了大运了，删除的微信聊天记录其实很容易就能恢复，但是小编奉劝你，这个方法千万不要让你的另一半发现哦！不要问我是怎么知道的！误导人的恢复方法：微信内部自带的修复功能
怎么恢复查看删除的微信聊天记录？这个方法相信很多小伙伴们都知道，但是小编想说这个方法其实并不适合自己手动误删除的微信聊天记录，但是如果小伙伴因为系统或者微信自己闪退等导致的微信聊天记录丢失就可以通过这个方法找回。操作方法也很简单或按照图中步骤操作：1.点击微信右下角“我的”，点击设置；2.点击【帮助与反馈】功能键；3.点击右上角一个小扳手的图标；3.打开【故障修复】；2.选择【聊天记录】即可等待微信自动修复。温馨提示一下：如果是自己手误删除的微信聊天记录，这个方法并不能恢复，而且还有可能造成更多的数据丢失或损坏，想要恢复就更难了。未雨绸缪的恢复方法：云备份或PC电脑端恢复法
怎么恢复查看删除的微信聊天记录？对于有经常备份的习惯的小伙伴，可以通过云备份来恢复自己的数据。
当然使用苹果手机的小伙伴也可以尝试使用icloud云备份来进行恢复。如果你的iPhone手机的icloud中微信备份是打开的，是有一定几率通过这种方法恢复的。直接根据页面提示操作即可：1.打开手机设置的【通用】--【还原】--【抹掉所有内容和设置】；2.等待抹除完成进入【应用与数据】--【从icloud云备份恢复】；温馨提示：此方法恢复成功了100%，但前提是你之前做好了备份，否则这个方法也帮不了你。当然小伙伴们可以尝试微信电脑端恢复，具体操作如下：1.电脑登录微信 ，点击左下角三杠，点击【备份与恢复】；2.选择【恢复聊天记录至手机】；温馨提示：操作过程中一定要保证手机和电脑使用的是同一个WiFi，否则恢复不成功。靠谱的恢复方法：专业的数据恢复工具
怎么恢复查看删除的微信聊天记录？如果是因为自己手动删除了聊天记录，又恰好没有备份的数据怎么恢复呢？我们可以通过专业的方法和技术很大几率可以帮助大家恢复自己手动误删除的微信聊天记录。恢复步骤如下：第一步：直接打开微信，在搜一搜里面搜索【失复得数据恢复】就能找到这个公众号；第二步：在【失复得数据恢复】微信公众号首页左下角--选择【立即预约】；第三步：选择【微信】选项提交预约。
我们也可以在对应的应用商店（苹果手机在App Store，华为手机在应用市场，其他手机在应用宝）搜索【恢复大师】下载安装，咨询4009030155。特别提醒：数据恢复和隐私保护请认准“恢复大师”官方正版APP！恢复大师官方正版APP名称只有四个字：“恢复大师”，其它带xxx恢复大师-xxx的均为冒充，谨慎下载，小心上当！
怎么恢复查看删除的微信聊天记录？以上就是小编分享的微信记录恢复教程，选择适合自己的方法尝试恢复即可。小伙伴们还在为误删微信聊天记录而发愁？别忧心忡忡的了，几分钟就学会的恢复方法已经教给你们了，快点去试试吧，千万不要让你老婆知道这个恢复方法哦，不说了，小编要去跪搓衣板了！

本文由微信开发团队工程师“ qiuwenchen”分享，原题“iOS微信全文搜索技术优化”，有修订。1、引言全文搜索是使用倒排索引进行搜索的一种搜索方式。倒排索引也称为反向索引，是指对输入的内容中的每个Token建立一个索引，索引中保存了这个Token在内容中的具体位置。全文搜索技术主要应用在对大量文本内容进行搜索的场景。微信终端涉及到大量文本搜索的业务场景主要包括：im联系人、im聊天记录、收藏的搜索。这些功能从2014年上线至今，底层技术已多年没有更新：1）聊天记录使用的全文搜索引擎还是SQLite FTS3，而现在已经有SQLite FTS5；2）收藏首页的搜索还是使用简单的Like语句去匹配文本；3）联系人搜索甚至用的是内存搜索（在内存中遍历所有联系人的所有属性进行匹配）。随着用户在微信上积累的im聊天数据越来越多，提升微信底层搜索技术的需求也越来越迫切。于是，在2021年我们对微信iOS端的全文搜索技术进行了一次全面升级，本文主要记录了本次技术升级过程中的技术实践。2、系列文章本文是专题系列文章中的第4篇：《IM全文检索技术专题(一)：微信移动端的全文检索优化之路》《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》《IM全文检索技术专题(三)：网易云信Web端IM的聊天消息全文检索技术实践》《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》（* 本文）3、全文检索引擎的选型iOS客户端可以使用的全文搜索引擎并不多，主要有：1）SQLite三个版本的FTS组件（FTS3和4、FTS5）；2）Lucene的C++实现版本CLucene；3） Lucene的C语言桥接版本Lucy。这里给出了这些引擎在事务能力、技术风险、搜索能力、读写性能等方面的比较（见下图）。1）在事务能力方面：Lucene没有提供完整的事务能力，因为Lucene使用了多文件的存储结构，它没有保证事务的原子性。而SQLite的FTS组件因为底层还是使用普通的表来实现的，可以完美继承SQLite的事务能力。2）在技术风险方面：Lucene主要应用于服务端，在客户端没有大规模应用的案例，而且CLucene和Lucy自2013年后官方都停止维护了，技术风险较高。SQLite的FTS3和FTS4组件则是属于SQLite的旧版本引擎，官方维护不多了，而且这两个版本都是将一个词的索引存到一条记录中，极端情况下有超出SQLite单条记录最大长度限制的风险。SQLite的FTS5组件作为最新版本引擎也已经推出超过六年了，在安卓微信上也已经全量应用，所以技术风险是最低的。3）在搜索能力方面：Lucene的发展历史比SQLite的FTS组件长很多，搜索能力相比也是最丰富的。特别是Lucene有丰富的搜索结果评分排序机制，但这个在微信客户端没有应用场景。因为我们的搜索结果要么是按照时间排序，要么是按照一些简单的自定义规则排序。在SQLite几个版本的引擎中，FTS5的搜索语法更加完备严谨，提供了很多接口给用户自定义搜索函数，所以搜索能力也相对强一点。4）在读写性能方面：下面3个图是用不同引擎对100万条长度为10的随机生成中文语句生成Optimize状态的索引的性能数据，其中每个语句的汉字出现频率按照实际的汉字使用频率。从上面的3张图可以看到：Lucene读取命中数量的性能比SQLite好很多，说明Lucene索引的文件格式很有优势，但是微信没有只读取命中数量的应用场景。Lucene的其他性能数据跟SQLite的差距不明显。SQLite FTS3和FTS5的大部分性能很接近，FTS5索引的生成耗时比FTS3高一截，这个有优化方法。综合考虑这些因素：我们选择SQLite FTS5作为iOS微信全文搜索的搜索引擎。4、引擎层优化1：实现FTS5的Segment自动Merge机制SQLite FTS5会把每个事务写入的内容保存成一个独立的b树，称为一个segment，segment中保存了本次写入内容中的每个词在本次内容中行号（rowid）、列号和字段中的每次出现的位置偏移，所以这个segment就是该内容的倒排索引。多次写入就会形成多个segment，查询时就需要分别查询这些segment再汇总结果，从而segment数量越多，查询速度越慢。为了减少segment的数量，SQLite FTS5引入了merge机制。新写入的segment的level为0，merge操作可以把level为i的现有segment合并成一个level为i+1的新的segment。merge的示例如下：FTS5默认的merge操作有两种：1）automerge：某一个level的segment达到4时就开始在写入内容时自动执行一部分merge操作，称为一次automerge。每次automerge的写入量跟本次更新的写入量成正比，需要多次automerge才能完整合并成一个新segment。Automerge在完整生成一个新的segment前，需要多次裁剪旧的segment的已合并内容，引入多余的写入量；2）crisismerge：本次写入后某一个level的segment数量达到16时，一次性合并这个level的segment，称为crisismerge。FTS5的默认merge操作都是在写入时同步执行的，会对业务逻辑造成性能影响，特别是crisismerge会偶然导致某一次写入操作特别久，这会让业务性能不可控（之前的测试中FTS5的建索引耗时较久，也主要因为FTS5的merge操作比其他两种引擎更加耗时）。我们在WCDB中实现FTS5的segment自动merge机制，将这些merge操作集中到一个单独子线程执行，并且优化执行参数。具体做法如下：1）监听有FTS5索引的数据库每个事务变更到的FTS5索引表，抛通知到子线程触发WCDB的自动merge操作；2）Merge线程检查所有FTS5索引表中segment数超过 1 的level执行一次merge；3）Merge时每写入16页数据检查一次有没有其他线程的写入操作因为merge操作阻塞，如果有就立即commit，尽量减小merge对业务性能的影响。自动merge逻辑执行的流程图如下：限制每个level的segment数量为1，可以让FTS5的查询性能最接近optimize（所有segment合并成一个）之后的性能，而且引入的写入量是可接受的。假设业务每次写入量为M，写入了N次，那么在merge执行完整之后，数据库实际写入量为MN(log2(N)+1)。业务批量写入，提高M也可以减小总写入量。性能方面，对一个包含100w条中文内容，每条长度100汉字的fts5的表查询三个词，optimize状态下耗时2.9ms，分别限制每个level的segment数量为2、3、4时的查询耗时分别为4.7ms、8.9ms、15ms。100w条内容每次写入100条的情况下，按照WCDB的方案执行merge的耗时在10s内。使用自动Merge机制，可以在不影响索引更新性能的情况下，将FTS5索引保持在最接近Optimize的状态，提高了搜索速度。5、引擎层优化2：分词器优化5.1 分词器性能优化分词器是全文搜索的关键模块，它实现将输入内容拆分成多个Token并提供这些Token的位置，搜索引擎再对这些Token建立索引。SQLite的FTS组件支持自定义分词器，可以按照业务需求实现自己的分词器。分词器的分词方法可以分为按字分词和按词分词。前者只是简单对输入内容逐字建立索引，后者则需要理解输入内容的语义，对有具体含义的词组建立索引。相比于按字分词，按词分词的优势是既可以减少建索引的Token数量，也可以减少搜索时匹配的Token数量，劣势是需要理解语义，而且用户输入的词不完整时也会有搜不到的问题。为了简化客户端逻辑和避免用户漏输内容时搜不到的问题，iOS微信之前的FTS3分词器OneOrBinaryTokenizer是采用了一种巧妙的按字分词算法，除了对输入内容逐字建索引，还会对内容中每两个连续的字建索引，对于搜索内容则是按照每两个字进行分词。下面是用“北京欢迎你”去搜索相同内容的分词例子：相比于简单的按字分词，这种分词方式的优势是可以将搜索时匹配的Token数量接近降低一半，提高搜索速度，而且在一定程度上可以提升搜索精度（比如搜索“欢迎你北京”就匹配不到“北京欢迎你”）。这种分词方式的劣势就是保存的索引内容很多，基本输入内容的每个字都在索引中保存了三次，是一种用空间换时间的做法。因为OneOrBinaryTokenizer用接近三倍的索引内容增长才换取不到两倍的搜索性能提升，不是很划算，所以我们在FTS5上重新开发了一种新的分词器VerbatimTokenizer，这个分词器只采用基本的按字分词，不保存冗余索引内容。同时在搜索时，每两个字用引号引起来组成一个Phrase，按照FTS5的搜索语法，搜索时Phrase中的字要按顺序相邻出现的内容才会命中，实现了跟OneOrBinaryTokenizer一样的搜索精度。VerbatimTokenizer的分词规则示意图如下：5.2 分词器能力扩展VerbatimTokenizer还根据微信实际的业务需求实现了五种扩展能力来提高搜索的容错能力：1）支持在分词时将繁体字转换成简体字：这样用户可以用繁体字搜到简体字内容，用简体字也能搜到繁体字内容，避免了因为汉字的简体和繁体字形相近导致用户输错的问题。2）支持Unicode归一化：Unicode支持相同字形的字符用不同的编码来表示，比如编码为\ue9的é和编码为\u65\u301的é有相同的字形，这会导致用户用看上去一样的内容去搜索结果搜不到的问题。Unicode归一化就是把字形相同的字符用同一个编码表示。3）支持过滤符号：大部分情况下，我们不需要支持对符号建索引，符号的重复量大而且用户一般也不会用符号去搜索内容，但是联系人搜索这个业务场景需要支持符号搜索，因为用户的昵称里面经常出现颜文字，符号的使用量不低。4）支持用Porter Stemming算法对英文单词取词干：取词干的好处是允许用户搜索内容的单复数和时态跟命中内容不一致，让用户更容易搜到内容。但是取词干也有弊端，比如用户要搜索的内容是“happyday”，输入“happy”作为前缀去搜索却会搜不到，因为“happyday”取词干变成“happydai”，“happy”取词干变成“happi”，后者就不能成为前者的前缀。这种badcase在内容为多个英文单词拼接一起时容易出现，联系人昵称的拼接英文很常见，所以在联系人的索引中没有取词干，在其他业务场景中都用上了。5）支持将字母全部转成小写：这样用户可以用小写搜到大写，反之亦然。这些扩展能力都是对建索引内容和搜索内容中的每个字做变换，这个变换其实也可以在业务层做，其中的Unicode归一化和简繁转换以前就是在业务层实现的。但是这样做有两个弊端：1）一个是业务层每做一个转换都需要对内容做一次遍历，引入冗余计算量；2）一个是写入到索引中的内容是转变后的内容，那么搜索出来的结果也是转变后的，会和原文不一致，业务层做内容判断的时候容易出错。鉴于这两个原因，VerbatimTokenizer将这些转变能力都集中到了分词器中实现。6、引擎层优化3：索引内容支持多级分隔符SQLite的FTS索引表不支持在建表后再添加新列，但是随着业务的发展，业务数据支持搜索的属性会变多，如何解决新属性的搜索问题呢？特别是在联系人搜索这个业务场景，一个联系人支持搜索的字段非常多。一个直接的想法是：将新属性和旧属性用分隔符拼接到一起建索引。但这样会引入新的问题：FTS5是以整个字段的内容作为整体去匹配的，如果用户搜索匹配的Token在不同的属性，那这条数据也会命中，这个结果显然不是用户想要的，搜索结果的精确度就降低了。我们需要搜索匹配的Token中间不存在分隔符，那这样可以确保匹配的Token都在一个属性内。同时，为了支持业务灵活扩展，还需要支持多级分隔符，而且搜索结果中还要支持获取匹配结果的层级、位置以及该段内容的原文和匹配词。这个能力FTS5还没有，而FTS5的自定义辅助函数支持在搜索时获取到所有命中结果中每个命中Token的位置，利用这个信息可以推断出这些Token中间有没有分隔符，以及这些Token所在的层级，所以我们开发了SubstringMatchInfo这个新的FTS5搜索辅助函数来实现这个能力。这个函数的大致执行流程如下：7、应用层优化1：数据库表格式优化7.1 非文本搜索内容的保存方式在实际应用中，我们除了要在数据库中保存需要搜索的文本的FTS索引，还需要额外保存这个文本对应的业务数据的id、用于结果排序的的属性（常见的是业务数据的创建时间）以及其他需要直接跟随搜索结果读出的内容，这些都是不参与文本搜索的内容。根据非文本搜索内容的不同存储位置，我们可以将FTS索引表的表格式分成两种：1）第一种方式：是将非文本搜索内容存储在额外的普通表中，这个表保存FTS索引的Rowid和非文本搜索内容的映射关系，而FTS索引表的每一行只保存可搜索的文本内容。这个表格式类似于这样：这种表格式的优势和劣势是很明显，分别是：a）优势是：FTS索引表的内容很简单，不熟悉FTS索引表配置的同学不容易出错，而且普通表的可扩展性好，支持添加新列；b）劣势是：搜索时需要先用FTS索引的Rowid读取到普通表的Rowid，这样才能读取到普通表的其他内容，搜索速度慢一点，而且搜索时需要联表查询，搜索SQL语句稍微复杂一点。2）第二种方式：是将非文本搜索内容直接和可搜索文本内容一起存储在FTS索引表中。表格式类似于这样：这种方式的优劣势跟前一种方式恰好相反：a）优势是：搜索速度快而且搜索方式简单；b）劣势是：扩展性差且需要更细致的配置。因为iOS微信以前是使用第二种表格式，而且微信的搜索业务已经稳定不会有大变化，我们现在更加追求搜索速度，所以我们还是继续使用第二种表格式来存储全文搜索的数据。7.2 避免冗余索引内容FTS索引表默认对表中的每一列的内容都建倒排索引，即便是数字内容也会按照文本来处理，这样会导致我们保存在FTS索引表中的非文本搜索内容也建了索引，进而增大索引文件的大小、索引更新的耗时和搜索的耗时，这显然不是我们想要的。FTS5支持给索引表中的列添加UNINDEXED约束，这样FTS5就不会对这个列建索引了，所以给可搜索文本内容之外的所有列添加这个约束就可以避免冗余索引。7.3 降低索引内容的大小前面提到，倒排索引主要保存文本中每个Token对应的行号（rowid）、列号和字段中的每次出现的位置偏移，其中的行号是SQLite自动分配的，位置偏移是根据业务的实际内容，这两个我们都决定不了，但是列号是可以调整的。在FTS5索引中，一个Token在一行中的索引内容的格式是这样的：从中可以看出，如果我们把可搜索文本内容设置在第一列的话（多个可搜索文本列的话，把内容多的列放到第一列），就可以少保存列分割符0x01和列号，这样可以明显降低索引文件大小。所以我们最终的表格式是这样：7.4 优化前后的效果对比下面是iOS微信优化前后的平均每个用户的索引文件大小对比：8、应用层优化2：索引更新逻辑优化8.1 概述为了将全文搜索逻辑和业务逻辑解耦，iOS微信的FTS索引是不保存在各个业务的数据库中的，而是集中保存到一个专用的全文搜索数据库，各个业务的数据有更新之后再异步通知全文搜索模块更新索引。整体流程如下：这样做既可以避免索引更新拖慢业务数据更新的速度，也能避免索引数据更新出错甚至索引数据损坏对业务造成影响，让全文搜索功能模块能够充分独立。8.2 保证索引和数据的一致业务数据和索引数据分离且异步同步的好处很多，但实现起来也很难。最难的问题是如何保证业务数据和索引数据的一致，也即要保证业务数据和索引数据要逐条对应，不多不少。曾经iOS微信在这里踩了很多坑，打了很多补丁都不能完整解决这个问题，我们需要一个更加体系化的方法来解决这个问题。为了简化问题，我们可以把一致性问题可以拆成两个方面分别处理：1）一是保证所有业务数据都有索引，这个用户的搜索结果就不会有缺漏；2）二是保证所有索引都对应一个有效的业务数据，这样用户就不会搜到无效的结果。要保证所有业务数据都有索引，首先要找到或者构造一种一直增长的数据来描述业务数据更新的进度，这个进度数据的更新和业务数据的更新能保证原子性。而且根据这个进度的区间能拿出业务数据更新的内容，这样我们就可以依赖这个进度来更新索引。在微信的业务中，不同业务的进度数据不同：1）聊天记录是使用消息的rowid；2）收藏是使用收藏跟后台同步的updateSequence；3）联系人找不到这种一直增长的进度数据（我们是通过在联系人数据库中标记有新增或有更新的联系人的微信号来作为索引更新进度）。针对上述第3）点，进度数据的使用方法如下：无论业务数据是否保存成功、更新通知是否到达全文搜索模块、索引数据是否保存成功，这套索引更新逻辑都能保证保存成功的业务数据都能成功建到索引。这其中的一个关键点是数据和进度要在同个事务中一起更新，而且要保存在同个数据库中，这样才能保证数据和进度的更新的原子性（WCDB创建的数据库因为使用WAL模式而无法保证不同数据库的事务的原子性）。还有一个操作图中没有画出，具体是微信启动时如果检查到业务进度小于索引进度，这种一般意味着业务数据损坏后被重置了，这种情况下要删掉索引并重置索引进度。对于每个索引都对应有效的业务数据，这就要求业务数据删除之后索引也要必须删掉。现在业务数据的删除和索引的删除是异步的，会出现业务数据删掉之后索引没删除的情况。这种情况会导致两个问题：1）一是冗余索引会导致搜索速度变慢，但这个问题出现概率很小，这个影响可以忽略不计；2）二是会导致用户搜到无效数据，这个是要避免的。针对上述第2）点：因为要完全删掉所有无效索引成本比较高，所以我们采用了惰性检查的方法来解决这个问题，具体做法是搜索结果要显示给用户时，才检查这个数据是否有效，无效的话不显示这个搜索结果并异步删除对应的索引。因为用户一屏能看到的数据很少，所以检查逻辑带来的性能消耗也可以忽略不计。而且这个检查操作实际上也不算是额外加的逻辑，为了搜索结果展示内容的灵活性，我们也要在展示搜索结果时读出业务数据，这样也就顺带做了数据有效性的检查。8.3 建索引速度优化索引只有在搜索的时候才会用到，它的更新优先级并没有业务数据那么高，可以尽量攒更多的业务数据才去批量建索引。批量建索引有以下三个好处：1）减少磁盘的写入次数，提高平均建索引速度；2）在一个事务中，建索引SQL语句的解析结果可以反复使用，可以减少SQL语句的解析次数，进而提高平均建索引速度；3）减少生成Segment的数量，从而减少Merge Segment带来的读写消耗。当然：也不能保留太多业务数据不建索引，这样用户要搜索时会来不及建索引，从而导致搜索结果不完整。有了前面的Segment自动Merge机制，索引的写入速度非常可控，只要控制好量，就不用担心批量建索引带来的高耗时问题。我们综合考虑了低端机器的建索引速度和搜索页面的拉起时间，确定了最大批量建索引数据条数为100条。同时：我们会在内存中cache本次微信运行期间产生的未建索引业务数据，在极端情况下给没有来得及建索引的业务数据提供相对内存搜索，保证搜索结果的完整性。因为cache上一次微信运行期间产生的未建索引数据需要引入额外的磁盘IO，所以微信启动后会触发一次建索引逻辑，对现有的未建索引业务数据建一次索引。总结一下触发建索引的时机有三个：1）未建索引业务数据达到100条；2）进入搜索界面；3）微信启动。8.4 删除索引速度优化索引的删除速度经常是设计索引更新机制时比较容易忽视的因素，因为被删除的业务数据量容易被低估，会被误以为是低概率场景。但实际被用户删除的业务数据可能会达到50%，是个不可忽视的主场景。而且SQLite是不支持并行写入的，删除索引的性能也会间接影响到索引的写入速度，会为索引更新引入不可控因素。因为删除索引的时候是拿着业务数据的id去删除的。所以提高删除索引速度的方式有两种：1）建一个业务数据id到FTS索引的rowid的普通索引；2）在FTS索引表中去掉业务数据Id那一列的UNINDEXED约束，给业务数据Id添加倒排索引。这里倒排索引其实没有普通索引那么高效，有两个原因：1）倒排索引相比普通索引还带了很多额外信息，搜索效率低一些；2）如果需要多个业务字段才能确定一条倒排索引时，倒排索引是建不了联合索引的，只能匹配其中一个业务字段，其他字段就是遍历匹配，这种情况搜索效率会很低。8.5 优化前后的效果对比聊天记录的优化前后索引性能数据如下：收藏的优化前后索引性能数据如下：9、应用层优化3：搜索逻辑优化9.1 问题用户在iOS微信的首页搜索内容时，交互逻辑如下：如上图所示：当用户变更搜索框的内容之后，会并行发起所有业务的搜索任务，各个搜索任务执行完之后才再将搜索结果返回到主线程给页面展示。这个逻辑会随着用户变更搜索内容而继续重复。9.2 单个搜索任务应支持并行执行虽然现在不同搜索任务已经支持并行执行，但是不同业务的数据量和搜索逻辑差别很大，数据量大或者搜索逻辑复杂的任务耗时会很久，这样还不能充分发挥手机的并行处理能力。我们还可以将并行处理能力引入单个搜索任务内，这里有两种处理方式：1）对于搜索数据量大的业务（比如聊天记录搜索）：可以将索引数据均分存储到多个FTS索引表（注意这里不均分的话还是会存在短板效应），这样搜索时可以并行搜索各个索引表，然后汇总各个表的搜索结果，再进行统一排序。这里拆分的索引表数量既不能太多也不能太少，太多会超出手机实际的并行处理能力，也会影响其他搜索任务的性能，太少又不能充分利用并行处理能力。以前微信用了十个FTS表存储聊天记录索引，现在改为使用四个FTS表。2）对于搜索逻辑复杂的业务（比如联系人搜索）：可以将可独立执行的搜索逻辑并行执行（比如：在联系人搜索任务中，我们将联系人的普通文本搜索、拼音搜索、标签和地区的搜索、多群成员的搜索并行执行，搜完之后再合并结果进行排序）。这里为什么不也用拆表的方式呢？因为这种搜索结果数量少的场景，搜索的耗时主要是集中在搜索索引的环节，索引可以看做一颗B树，将一颗B树拆分成多个，搜索耗时并不会成比例下降。9.3 搜索任务应支持中断用户在搜索框持续输入内容的过程中可能会自动多次发起搜索任务，如果在前一次发起的搜索任务还没执行完时，就再次发起搜索任务，那前后两次搜索任务就会互相影响对方性能。这种情况在用户输入内容从短到长的过程中还挺容易出现的，因为搜索文本短的时候命中结果就很多，搜索任务也就更加耗时，从而更有机会撞上后面的搜索任务。太多任务同时执行还会容易引起手机发烫、爆内存的问题。所以我们需要让搜索任务支持随时中断，这样就可以在后一次搜索任务发起的时候，能够中断前一次的搜索任务，避免任务量过多的问题。搜索任务支持中断的实现方式是给每个搜索任务设置一个CancelFlag，在搜索逻辑执行时每搜到一个结果就判断一下CancelFlag是否置位，如果置位了就立即退出任务。外部逻辑可以通过置位CancelFlag来中断搜索任务。逻辑流程如下图所示：为了让搜索任务能够及时中断，我们需要让检查CancelFlag的时间间隔尽量相等，要实现这个目标就要在搜索时避免使用OrderBy子句对结果进行排序。因为FTS5不支持建立联合索引，所以在使用OrderBy子句时，SQLite在输出第一个结果前会遍历所有匹配结果进行排序，这就让输出第一个结果的耗时几乎等于输出全部结果的耗时，中断逻辑就失去了意义。不使用OrderBy子句就对搜索逻辑添加了两个限制：1）从数据库读取所有结果之后再排序：我们可以在读取结果时将用于排序的字段一并读出，然后在读完所有结果之后再对所有结果执行排序。因为排序的耗时占总搜索耗时的比例很低，加上排序算法的性能大同小异，这种做法对搜索速度的影响可以忽略。2）不能使用分段查询：在全文搜索这个场景中，分段查询其实是没有什么作用的。因为分段查询就要对结果排序，对结果排序就要遍历所有结果，所以分段查询并不能降低搜索耗时（除非按照FTS索引的Rowid分段查询，但是Rowid不包含实际的业务信息）。9.4 搜索读取内容应最少化搜索时读取内容的量也是决定搜索耗时的一个关键因素。FTS索引表实际是有多个SQLite普通表组成的，这其中一些表格存储实际的倒排索引内容，还有一个表格存储用户保存到FTS索引表的全部原文。当搜索时读取Rowid以外的内容时，就需要用Rowid到保存原文的表的读取内容。索引表输出结果的内部执行过程如下：所以读取内容越少输出结果的速度越快，而且读取内容过多也会有消耗内存的隐患。我们采用的方式是：搜索时只读取业务数据id和用于排序的业务属性，排好序之后，在需要给用户展示结果时，才用业务数据id按需读取业务数据具体内容出来展示。这样做的扩展性也会很好，可以在不更改存储内容的情况下，根据各个业务的需求不断调整搜索结果展示的内容。还有个地方要特别提一下：就是搜索时尽量不要读取高亮信息（SQLite的highlight函数有这个能力）。因为要获取高亮字段不仅要将文本的原文读取出来，还要对文本原文再次分词，才能定位命中位置的原文内容，搜索结果多的情况下分词带来的消耗非常明显。那展示搜索结果时如何获取高亮匹配内容呢？我们采用的方式是将用户的搜索文本进行分词，然后在展示结果时查找每个Token在展示文本中的位置，然后将那个位置高亮显示（同样因为用户一屏看到的结果数量是很少的，这里的高亮逻辑带来的性能消耗可以忽略）。当然在搜索规则很复杂的情况下，直接读取高亮信息是比较方便（比如：联系人搜索就使用前面提到的SubstringMatchInfo函数来读取高亮内容）。这里主要还是因为要读取匹配内容所在的层级和位置用于排序，所以逐个结果重新分词的操作在所难免。9.5 优化前后的效果对比下面是微信各搜索业务优化前后的搜索耗时对比：10、本文小结目前iOS微信已经将这套新全文搜索技术方案全量应用到聊天记录、联系人和收藏的搜索业务中。使用新方案之后：全文搜索的索引文件占用空间更小、索引更新耗时更少、搜索速度也更快了，可以说全文搜索的性能得到了全方位提升。附录：QQ、微信团队其它技术文章《微信朋友圈千亿访问量背后的技术挑战和实践总结》《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》《iOS后台唤醒实战：微信收款到账语音提醒技术总结》《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》《微信团队分享：微信Android版小视频编码填过的那些坑》《企业微信客户端中组织架构数据的同步更新方案优化实战》《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》《微信后台基于时间序的海量数据冷热分级架构设计实践》《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》《微信后台团队：微信后台异步消息队列的优化升级实践分享》《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》《微信技术总监谈架构：微信之道——大道至简(演讲全文)》《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》学习交流： - 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》 - 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK （本文同步发布于：http://www.52im.net/thread-3839-1-1.html）