回忆了一下Foxmail内置的全文搜索那点事，于是有了此文

我相信如今这一代混迹网络的大小神仙们已经很少有人使用独立的email客户端了。包括纯办公环境，都有大量的在线Email系统，甚至我自己都至少2年没有启动过Foxmail这类pc版的客户端软件。只有一些极度在意移动能力和完美编辑能力的同学才会保留使用outlook、foxmail的习惯。毕竟，Foxmail这个号称一个U盘就能全世界都乱用的鼻祖还是不如web mail来的方便。

单纯对于Foxmail来说，有太多故事可以讲，但是清楚当初那些软件实现细节的大神有些去创业或者去干别的去了，少数还健在的又不愿意多说，如果再不总结一下，我都担心有些事情就没人记得了~所以，斗胆先说说本人经手过的一个特性的来龙去脉。

先蹲地上画个timeline，用力地往回拉，反正大约是至少10年前就对了。话说10几年前，小马哥买了Foxmail整个团队，没几年就打造了让丁三石郁闷不已的QQMail产品出来。唯一令人遗憾的是，Foxmail Server团队被解散了，每年静悄悄地就能完成销售额几百万的东西，说不见就不见了。原因只是，赚的太少，不差那点钱。有点扯远了，说回正题。具体时间，大概Foxmail 6-6.5这个版本发布前后几个月那时候。

那时候，大概也就是在gmail推出来没多久，gmail内置的搜索功能好用到令人发指。相比之下，Foxmail虽然也能搜索，但是那个搜索弱到爆，实现上使用的是类似用notepad打开全文，grep一次的做法。弱到开发自己都不好意思说那种，反正能用而已。

大概就在我上一个项目，修改完Foxmail垃圾邮件过滤引擎以后，没过多久，龙哥看我好像又没啥事做了，喊我顺便聊聊内置搜索引擎，比如对搜索这事怎么看之类的。已经不记得当时自己具体说过些啥，大致过程无非就是，这东西很有必要，而且要做起来也不难。具体要实现会遇到的技术细节啥的也顺便聊过一些，关键点是要足够小巧，足够快之类的。

总之，聊完就领了任务，这事有的搞。

技术调研过程啥的，其实没什么细节可提的，无非是体验一些当时pc版软件里面带搜索引擎的东西罢了。各种体验，各种分析，乱七八糟分析报告则能省则省，但阶段总结邮件少不了就行了，反正懒这一点上，那时候已经是地球人都知道的事情，不怕不怕。

说实话，因为这东西做起来并不难，我当时是没太把这事看的太重，毕竟本人上上一份工作就是在一家搜索引擎公司里混个开发职位。反而，在PC产品体验上的要求，比如小巧稳定才是个难题。于是，花了几个星期，用VC++做了个直接解析Foxmail存储文件的demo，盯着惨不忍睹的UI demo窗口，能完成索引建立和搜索展示出邮件的功能而已。

老家伙们肯定知道Foxmail是Delphi实现的，那我为啥用C++去做demo？其实原因很简单，懒啊，当年学过的一点点Delphi早就忘光了，千万不能给他们知道我其实学过Delphi，否则又要重新学一次，嘿嘿嘿~

当时的组长倒是对这事看得很重，还特意联系了远在深圳的soso开发团队，要我过去跟他们学习调研一段时间。soso那时候基本上是第一代刚发布完前后不久，实现的搜索效果我觉得是可以用基本无法忍受，只能说是能搜到东西来形容。

于是，我就兴高采烈的去大深圳出差了差不多个把月，整天跟soso的开发泡在一起，讨论各种实现细节啥的。高高兴兴的在大sz混了些日子，基本上把汇报文档该写啥都弄清楚了，立刻拍拍屁股回了大省城。汇报围绕着下面这几个展开：

1. soso的实现方式无法抄过来，服务器和pc在本质上完全不同；

2. PC软件上没有现成的东西可用，得自己开发；

3. 索引得支持即时生效，也就是新到一封邮件就得能立刻搜到；

4. pc版要保证100%查全率，不能容忍经典搜索的漏过情况；

至于为啥会漏过，也就是找不到，这事解释起来也很简单，搜索引擎并不需要保证每一个结果都能搜到，除去索引技术实现上带来的原生态漏过以外，搜索本质上只要有结果返回就行了。也就是说如果给人发现有一个网页找不到，可以归结为访问人太少而没有收录，大家也不会去深究。但是在Foxmail客户端的情况下，如果出现了一个邮件存在，但是搜一个词就是找不到，那就无法忍受了。区别不大，但是这是根本性上的区别。

总之，就是只需要抓住1、4两个点，其他都不重要。

既然提到了soso，那就顺便多说几句。当年的soso后台的搜索引擎实现的其实非常简略，我记得是基于Lucene做的一套包装接口（也许不是Lucene，请相关同学指正哈）。soso服务器的索引更新的代价又非常高，用采用了整体文件替换的形式做的可搜索内容更新，也就是在半夜得停机cp几个容量上T的文件过去，然后重启服务就能用了，一天更新一次。哎，又扯远了，收~

总结下回来的汇报，结论也很简单：无法抄袭(借鉴），自己重新写一个就行了，这事能做而且不难~

然后就是找Foxmail的开发兼产品同学聊天。这个也值得多说2句。

Foxmail其实并没有专职的产品，一直都是开发自己负责产品特性，负责的老大(vic)是一个很有想法的家伙，无论开发技术还是产品特性，vic都是当年跟谁聊天能聊到一个坑的家伙。其实，还有很多老家伙，比如leo、alex等都是非常有趣有个性的。

那时候的事，我只记得几个细节了，开发同学对搜索技术的神圣感是很强烈的，觉得这玩意应该小心地学习并认真地研究一下才行。当前的grep式的搜索实现方式虽然丑陋但是能用，新版本除了要保证一个不漏地查到结果以外，消耗资源还要足够小而且非常小。

什么叫消耗足够小呢？当时的windows pc经典硬件环境是1G左右的内存，几十G容量的机械式硬盘，那性能现在看可是惨不忍睹，更不用提办公环境下，Foxmail遇到的经典使用环境：主流笔记本电脑的硬盘和内存那才是要多坑爹就有多坑爹。

Foxmail的开发同学一听我说经典的索引实现需要容量最少得1.5倍左右，就立刻翻脸：这怎么可以啊！一个使用场景一天也就几次的东西，坚决不能占用那么多磁盘空间和内存（Foxmail的存储文件格式不带压缩，就已经很浪费空间了）！硬盘占用能不能压缩到1倍以下啊，内存能不能最多用10M啊，不用的时候内存能不能给我释放出来啊...反正，我当时回答是说，这些啊，都能做到啊，这几个要求都能做到，无非是做个取舍而已。

总之，功能特性上面的调研就算做完了。几个核心指标一出，我反倒是高兴了不少。因为，原本我也没打算用"正经"的中文搜索技术去做这事啊。分词？分词根本不需要，直接基于字就行了，上BDB（Berkeley DB开源了，大Linux上系统核心都在用的东西，错不了）。简单几个BDB的表，再把索引弄进内存，足够小了，无非是检索结果取交集的小问题而已。（这里其实埋了个大坑，这个坑后面有机会再说）

反正，几下子，demo是做出来了，VC++直接解析Foxmail的存储文件，在几十万的邮件情况下，建立索引、启动/重启、查找、展示结果邮件都足够快，跑起来也足够稳定。

拿去给vic,leo同学体验，也给龙哥看了下。大家觉得很开心，貌似不错。当然，技术实现细节我肯定是不多说的。印象中，还因为没有使用"正经"搜索技术这个事，跟我的开发组长吵了一次，他觉得做搜索就得用传统搜索技术，你这个实现的非常不专业之类的，当时我怎么反驳的已经不记得了，反正最终结果是并没有因为这次争吵而改掉实现方式。（因为这次争吵，又埋下了一个大坑，以后有机会再说）嘿嘿嘿~

然后，就是认真讨论怎么融入Delphi实现的Foxmail里面的问题了，要做个内置搜索引擎的Foxmail测试版出来。由于我"不懂"Delphi，也不方便直接切入Delphi客户端开发(我当时的职务是后台架构开发)，leo大神就被指派跟我合作。分配结论就是我继续用VC++做DLL，leo用Delphi调用并实现搜索入口和结果展示相关功能等等。

用不用分词技术这事，又反复pk了几次，产品同学认为分词必不可少，当我解释用最烂的分词技术，准确率也能轻松达到97%，但是要进一步解决用了分词以后带来的查不全的问题，单独的分词引擎就需要几十M的资源，还得增加好多处理逻辑，各种不划算啊不划算啊，总之解释了不下3次，如果一定要实现分词，soso当时在用的分词技术也还不够完美地。要完美的化，我们得招一个专门维护这玩意的人才行。在不能消耗过多硬件资源的大要求面前，这事就必须让步了。

进而，又因为这个讨论，写出了一个分析邮件，里面对当时国内中文语言处理(NLP)的技术和可用人才做了一个简单分析，还带了个列表，里面又不小心提到有个家伙很牛，今年应该要毕业了。SZ总部在看到后，不久就果断招了我的一位师弟。该师弟入职后做的一个重要产品好像就是QQ拼音输入法。不过，这又是题外话了。收~

反正，经过个把月的开发联调，解决了几个自己测试就发现的重大问题，比如：

1. 搜索功能被线程独立出来了，跟主程序逻辑结合在一起会分分钟卡死的，因为原本的Foxmail主界面逻辑已经很多了，自己的界面更新性能都卡(好像7.0版才解决掉主逻辑过多的问题)，更何况要调用大量的外部处理接口；

2. 软件崩溃或系统蓝屏会导致频繁的文件数据丢失问题，windows文件系统这个大坑真是巨大无比。好在BDB自己就有索引修复能力，再增加一个独立线程，启动时先检查一下索引完整性，能修复就修复，修复不了就悄悄地重建呗；

3. 搜索到的邮件结果展示上，增加了一系列贴心的高亮提示功能，比如收发件人和标题命中了目标词，列表上就直接高亮出来，立刻好看了很多；

4. 内存占用上面pk无效，依然被卡死在最多只能使用10M左右内存的情况，于是，搜索性能下降不少，只要不是几十万上百万邮件，区别倒不是特别大；

5. 支持了全部资源释放能力，目标是在不用搜索功能的时候，要能够把这10M的巨量内存都还给系统，吐血；

6. 人为构造了很多文件损坏的场景，大家都认为重建对磁盘的冲击太大，磁盘卡顿会导致windows卡顿，windows卡顿会导致Foxmail卡顿，Foxmail卡顿会导致搜索功能卡顿...
   对这里的资源消耗人为降低了系统处理的优先级，自然结果就是慢，无比的慢了，甚至有时候完全重建需要花几个小时之久；

7. 还有一些乱七八糟的优化记不清楚了，反正是搜索入口上跟原来方式一样，还能无缝切换回老grep模式的能力；

然后就是不停的测试、修改、小规模释放beta版本给外部用户体验，再修改、再测试的循环套路。

也许是Foxmail的测试群体又可爱，又特别富有，他们的笔记本和pc性能都非常好，结果是竟然没遇到什么大问题，以至于正式发布的时候才收到一些认真的批评和改进意见，这又是后话了。

主要的大问题集中在：

1. 搜不到结果，添加索引的时候软件/windows崩溃了，邮件根本就没有送去建立索引，校验也没发现，改~

2. 系统严重卡顿，大量用户的pc内存特别少，那继续降低内存和磁盘占用资源，改~；

3. 重建索引太慢，甚至重建无效，因为总有人发现用不了就杀了Foxmail重启，重启发现还是不行，就再杀，上帝啊耶稣佛祖拉登川普啊~；

总之，一系列哭笑不得的事情都发生了，但是好在大家都认同了必须在搜索功能必不可少的大方向继续走下去。而要想彻底解决这些，得重新用Delphi再实现一个更加简化的引擎，BDB在这个情况下还是太重了一点，本质上来说，只需要一个index而已。所以，再后来的版本，就放弃了BDB的DLL部分，Foxmail的开发同学完全消化了需要的BDB少量功能后，大概在7.0版左右重新实现了一套更简单的版本，也就是现在大家还在用的这套方案。

总之，在充满了各种欢乐而祥和的pk和修改过程之后，全文搜索功能一直在修改和进步中。而且这过程里，还有个小笑话很好玩，值得讲讲。

在带全文搜索功能的版本正式公开后没几天，一个大学同学突然发消息给我，上来就直接问：foxmail里面带的这个搜索功能是你做的吧，是不是？快说！我立刻震惊了，尼玛，这也能被认出来，我可从来没公开说过这玩意是我做的啊！立刻反问，你怎么知道的？该同学丢了一句：IndexLib有个奇葩的文件叫：tcpip.db的东西，我估计全世界也只有你才会无聊到起这个名字。我~~~无语~~

其实Foxmail在资源命名上面的各种类似人性化方面，这可是有着优良地、悠久地历史传统的，我才不会告诉你，原始代码里面还充斥着大量的aa，bb，x，yy这样的变量呢，至少这个文件我还把他叫.db了，已经算很好了~

再然后就是QQMail也决定要做全文搜索了，只不过这次不需要我动手了，老大调了一个新入职的实习生，责令我手把手教了一段时间（前面自己挖的坑自己填哈）。这次，终于把“正经”搜索引擎改用的技术实现要点，从头到尾教一边，这位同学当时基本全程蹲在我座位旁边拿个小本子记，每次都要我给他拉个座位过来才坐。然后这位同学顺利做了出来QQMail的后台搜索服务模块，再往后，又顺利做了个总监，自然这是又是后话。

故事先讲这么多，还有很多好玩的事情，以后想来再说。更多的关于Foxmail的细节必须得期待当年做Foxmail的大神（包括UI艺术大神bobo）和现还在维护代码的大神们动手才行，希望本文可以抛砖引玉，大家不妨先看个热闹~