基于BREW的手机全局搜索方案

 

一、   概述：

随着3G时代的到来，用户可以通过手机获得海量信息。如何在此海量信息中快速搜索用户想要的内容，成为一个重要的功能。全局搜索因此而生。

二、   整体框架

整体框架必须低耦合，可扩展。以便任何一部分的变化都能独立运作，能适应将来的变化。

整体框架图如下（见下页）。

工作流程为：

1.          全局搜索模块启动时，解析SearchComponentConfig.ini文件获得有哪些提供搜索功能的组件。

2.          根据每个组件的Mime Type，通过BREW API查询出相应的Handler CLSID，并创建其。然后调用_GetString , GetIcon获得每个Search组件的名称和图标。在UI的可选择搜索组件框中显示之，可供用户选择。

3.          用户输入关键字，并选择在哪些组件/模块中搜索。然后开始搜索。

4.          全局搜索模块分别调用每个已选择Search组件接口的StartSearch API。该过程实现为异步。用户在任何时刻可以取消之。

5.          搜索得到结果，Search组件通过回调返回结果。结果使用一致格式，包含2部分：结果字串（高亮内容，位置，等等），UserData（透明数据，用于Execute API）。

6.          全局搜索模块显示搜索结果，并关联，存储UserData于每个结果记录。

7.          当用户在结果中点击某记录时，调用相应Search组件的Execute API，并传入保存的透明数据UserData(UserData的含义由各Search组件定义，并对外不可见)。

 

 

 

 

 

 

 

三、   搜索效率问题

1.      通过Cache Result提高重复搜索效率

每个Search组件内部实现中，应该支持将搜索结果Cache起来，以便重复搜索时，快速返回结果。

Cache可以定一个最大存储容量，当达到该容量时，基于LRU策略删除Oldest Cache Record。

此外，手机关机时，也需要清除Cache。

关于是否需要实时同步Cache（相应模块读写数据时，是否需要更新Cache相关记录，还是直接清除Cache）的问题，需权衡复杂度和带来的效率改善来决定。

2.      基于Index搜索提高效率

主要是使用基于倒排序索引文件的方法，来替代全文搜索。这样，当进行关键字搜索时，可以只在关键字索引文件中搜索，并可快速获得结果。但由于占用存储空间较大（当索引记录非常多时），且关键字分割需要使用到分词器。所以，当前可能无法实现。