專利名稱：在終端上更新索引并基于其對搜索結(jié)果排序的方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及基于移動終端的信息檢索領(lǐng)域，特別是涉及一種移動終端的本地搜 索方法及裝置。
背景技術(shù)：
隨著通訊產(chǎn)業(yè)的不斷發(fā)展，各種移動終端的使用頻度以及廣度都有較大的提 升。并且伴隨硬件設(shè)備價格的下降，各種功能強(qiáng)大的移動終端逐步進(jìn)入百姓家庭，不僅 成為人們?nèi)粘＝涣鞯闹饕ぞ咧?，而且還是娛樂休閑、或者辦公的必備物品。
移動終端的處理能力以及容量都在與日俱增，同時還支持更大容量的存儲卡等 外設(shè)。用戶越來越傾向于將各種文本文件、多媒體數(shù)據(jù)存放在移動終端中；此外，現(xiàn)代 的移動終端大部分都支持用戶將短信、彩信、聯(lián)系人、郵件等內(nèi)容存儲在除SIM空間以 外的存儲空間中，這樣用戶可以將海量的信息存放在移動終端上而不需要進(jìn)行刪除，達(dá) 到永久可用的目的。
正是由于移動終端數(shù)據(jù)存儲容量的提升，即給用戶帶來了更為貼身的用戶體 驗，但同時也使得用戶查找相關(guān)的信息變得相對復(fù)雜和困難。因此，在移動終端上進(jìn)行 桌面搜索將極大地提高用戶查找本地信息的速度。
智能移動終端的處理能力雖然不斷提升，但其固有特點使得現(xiàn)有的網(wǎng)絡(luò)搜索引 擎技術(shù)、以及個人電腦所采用的桌面搜索技術(shù)很難直接應(yīng)用到嵌入式的移動終端中。由 于移動終端的電池容量有限，不能長時間的運(yùn)行某個特別耗能的后臺程序，每次進(jìn)行本 地檢索都完成一次新的全文索引需要耗費(fèi)較大的能源和系統(tǒng)資源。
通常，相關(guān)性是搜索引擎進(jìn)行排序的一個重要依據(jù)。一般搜索得到結(jié)果，都是 按照相關(guān)性進(jìn)行降序排列。這種方式在Web網(wǎng)上非常常見。但在嵌入式系統(tǒng)中，由于 用戶使用的資源本身有限，需要查詢的信息也絕大部分是用戶會反復(fù)使用到的資源，比 如某條短信的發(fā)件人信息，某個郵件的內(nèi)容，某一首經(jīng)常播放的歌曲等等。
因此，一種簡化本地搜索過程的本地索引建立及維護(hù)方法就是亟待解決的問 題。此外，在結(jié)合傳統(tǒng)的按照相關(guān)度對搜索結(jié)果進(jìn)行排序的基礎(chǔ)上，進(jìn)一步按照移動終 端用戶經(jīng)常訪問的頻率來對搜索結(jié)果排序進(jìn)行改進(jìn)，改善檢索效果，使搜索過程更貼近 用戶使用習(xí)慣，增強(qiáng)用戶使用體驗。發(fā)明內(nèi)容
針對目前等問題而提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種的方 法，以解決上述問題。
本發(fā)明提出了一種在終端上更新索引并基于其對搜索結(jié)果排序的方法，包括以 下步驟檢索文件是否有修改；當(dāng)文件存在修改時，對改變的文件進(jìn)行增量索引，生成 新的索引文件，其中增量索引中包含對所述文件的歷史選中次數(shù)；將生成的新的索引文 件合并到原有的索引文件中；獲取用戶輸入的關(guān)鍵字；查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以及所述文件的歷史選中次數(shù)來對搜索結(jié)果進(jìn)行排 序并顯示給用戶。
其中，在根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以及所述文件的歷史選中次數(shù)來 對搜索結(jié)果進(jìn)行排序并顯示給用戶的步驟之后，還包括以下步驟記錄用戶選中所述文 件的次數(shù)，并更新所述文件的歷史選中次數(shù)。
其中，在檢索文件是否有修改的步驟中，具體包括以下步驟將現(xiàn)有文件的時 間戳和前一次建立索引時所保留的文件的時間戳進(jìn)行比較，如果現(xiàn)有文件的時間戳與前 一次建立索引時所保留的文件的時間戳一樣，則判斷文件沒有被修改，如果現(xiàn)有文件的 時間戳與前一次建立索引時所保留的文件的時間戳不一樣，則判斷文件有修改。
其中，在檢索文件是否有修改的步驟中，以預(yù)定的檢索周期檢索文件是否有修 改。
其中，定期地或者在檢測到手機(jī)空閑時或者在新的索引文件達(dá)到預(yù)定數(shù)量時將 新的索引文件合并到原有的索引文件中。
其中，在定期地將新的索引文件合并到原有的索引文件中的過程中，合并周期 與用戶設(shè)定的檢索周期相同。
其中，在生成新的索引文件之后，將所生成的新的索引文件暫存在終端內(nèi)存 中，并在將所生成的新的索引文件合并到原有的索引文件中之后，釋放存儲新的索引文 件的終端內(nèi)存。
本發(fā)明還提出了一種在終端上更新索引并基于其對搜索結(jié)果排序的裝置，包 括檢索單元，檢索文件是否有修改；生成單元，當(dāng)所述文件存在修改時，對改變的文 件進(jìn)行增量索引，生成新的索引文件，其中所述增量索引中包含對所述文件的歷史選中 次數(shù)；合并單元，將生成的新的索引文件合并到原有的索引文件中；獲取單元，獲取用 戶輸入的查詢關(guān)鍵字；查詢單元，查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵 字之間的相關(guān)度以及所述文件的歷史選中次數(shù)來對所述搜索結(jié)果進(jìn)行排序；顯示單元， 將排序的所述搜索結(jié)果顯示給用戶。
其中，裝置還包括記錄單元，記錄用戶選中所述文件的次數(shù)；更新單元，更 新所述文件的所述歷史選中次數(shù)。
其中，裝置還包括比較單元，將現(xiàn)有文件的時間戳和前一次建立索引時所保 留的文件的時間戳進(jìn)行比較，如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件 的時間戳一樣，則判斷所述文件沒有被修改，如果現(xiàn)有文件的時間戳與前一次建立索引 時所保留的文件的時間戳不一樣，則判斷文件有修改。
通過本發(fā)明，可以時時地自動更新手機(jī)本地索引表，以便滿足不時的本地搜索 需求，并且占用較少手機(jī)資源和能源。并且搜索結(jié)果更加人性化。提高了移動終端用戶 的使用體驗。


此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本 發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖 中
圖1是本發(fā)明優(yōu)選實施例的建立本地全文索引的流程示意圖。
圖2是本發(fā)明優(yōu)選實施例的索引文件目錄結(jié)構(gòu)。
圖3是本發(fā)明優(yōu)選實施例的增量索引示意圖。
圖4是本發(fā)明優(yōu)選實施例的索引文件結(jié)構(gòu)。
圖5是本發(fā)明優(yōu)選實施例的搜索結(jié)果排序的流程示意圖。
圖6是根據(jù)本發(fā)明的裝置。
具體實施方式
本發(fā)明的主要目的在于提供一種移動終端的本地搜索的方法。包括索引更新方 法和搜索結(jié)果的排序方法。
本發(fā)明解決其技術(shù)問題采用的技術(shù)方案如下
一種移動終端的索引更新方法，主要包括以下步驟
步驟1，定時進(jìn)行檢索，查看文件是否有修改，通過對比現(xiàn)有文件的時間戳和第 一次建立索引時所保留的文件元信息中的時間戳進(jìn)行對比，如果現(xiàn)有文件的時間戳比第 一次建立索引時所保留的文件元信息中的時間戳更新，那么執(zhí)行步驟2，否則結(jié)束。
步驟2，對新文件進(jìn)行增量索引，生成新的索引文件。
步驟3，將該含有增量信息的索引文件合并到原先的大索引文件中。
一種移動終端的搜索結(jié)果排序方法，主要包括以下步驟
(1)移動終端上的搜索引擎對移動終端存儲介質(zhì)上的文本、短信、聯(lián)系人、郵 件、圖片、視頻、音頻等其它各種包含文本信息的文件進(jìn)行分析，并對其建立全文索 引。
( 移動終端的本地搜索搜索引擎的用戶界面接受用戶的查詢請求，讀取查 詢請求所對應(yīng)的全文索引，將最貼近用戶搜索要求的查詢結(jié)果反饋給用戶。并同時在索 引表中記錄用戶選中某條搜索結(jié)果的次數(shù)。
C3)移動終端的多次搜索搜索引擎的用戶界面接受用戶的查詢請求，讀取查 詢請求所對應(yīng)的全文索引。將搜索結(jié)果與搜索內(nèi)容的相關(guān)度，并對搜索結(jié)果的歷史選中 次數(shù)進(jìn)行排序。將搜索結(jié)果的相關(guān)度為第一優(yōu)先級，歷史選中次數(shù)為第二優(yōu)先級，對結(jié) 果進(jìn)行降序排列，并反饋給用戶。即，當(dāng)搜索到具有相關(guān)性的文件時，才對具有相關(guān)性 的文件將搜索結(jié)果和歷史選中次數(shù)進(jìn)行權(quán)重計算，并根據(jù)結(jié)果進(jìn)行排序。
通過本發(fā)明，可以時時地自動更新手機(jī)本地索引表，以便滿足不時的本地搜索 需求，并且占用較少手機(jī)資源和能源。并且搜索結(jié)果更加人性化。提高了移動終端用戶 的使用體驗。
以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進(jìn)行說明，應(yīng)當(dāng)理解，此處所描述的優(yōu)選 實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。
圖1是根據(jù)本發(fā)明的建立本地全文索引的流程示意圖。具體包括以下步驟
步驟S101，根據(jù)用戶輸入，確認(rèn)需要索引的信息范圍。這樣可以減少不必要的 索引時間，增加有效搜索次數(shù)，并在某些情況下保護(hù)用戶在移動終端上的私密信息不被 搜索。
步驟S102，根據(jù)步驟SlOl所確定的信息范圍，建立文件元信息。包括文件建立或修改的時間戳、以及文件類型等。
步驟S103，根據(jù)步驟SlOl所確定的信息范圍，對文件的文本信息進(jìn)行分析，包 括文件名、文件中的文本信息，以及多媒體文件的文本注釋等信息。并將這些信息和數(shù) 據(jù)存儲在一個純文本或XML文檔結(jié)構(gòu)中，可以很靈活的嵌入到移動設(shè)備的程序中。
步驟S104，建立全文索引，索引過程為讀取文件名，將文件分路徑和內(nèi)容2個 字段進(jìn)行存儲，并對內(nèi)容進(jìn)行全文索引。內(nèi)容包括多個字段，并針對不同字段屬性和數(shù) 據(jù)輸出的續(xù)簽，對字段選擇不同的索引規(guī)則和存儲規(guī)則，比如對標(biāo)題需要進(jìn)行切分詞的 操作，而對日期只存儲而不進(jìn)行切分詞操作。
本發(fā)明中，所更新的不是整個索引文件，而是在需要增加索引中的信息時，不 斷創(chuàng)建新的索引文件，然后在手機(jī)空閑時，定期地將這些新的小索引文件合并到原先的 大索引文件中，即增量索引，這樣在不影響搜索查詢效率的前提下，提高了索引的效 率。創(chuàng)建新的索引文件的優(yōu)勢之一是如果原先的索引文件在意外損壞的情況下，用戶還 可以通過查詢新創(chuàng)建的索引文件得到近期的搜索結(jié)果。另外重新從原始數(shù)據(jù)進(jìn)行索引只 需要索引最近一次創(chuàng)建新索引文件之前的原始數(shù)據(jù)即可，節(jié)省了索引時間。另外，將小 索引文件合并到原先大索引文件的合并周期與用戶設(shè)定的索引周期相同，因為只有在索 引文件有變化的情況下，才有必要將新增的索引文件合并到原先的大索引文件中。并且 保證合并過程不在索引過程中進(jìn)行，因為這樣會消耗大量的CPU時間，使得索引效率低 下，并影響用戶的手機(jī)操作體驗。因此需要在索引過程結(jié)束后，并且用戶在較長一段時 間內(nèi)沒有操作手機(jī)的情況下，進(jìn)行合并操作，這里設(shè)定的合并時間點為用戶停止操作手 機(jī)后的半個小時。在這里，利用了 Lucene自帶的增量索引機(jī)制，通過段的使用，在內(nèi)存 中快速將新的索引信息合并到原先的大索引文件中，然后再將更新后的大索引文件寫入 磁盤，接著刪除不需要的小索引文件。
具體而言，本發(fā)明的更新維護(hù)方法包括
步驟S105，定時進(jìn)行檢索，查看文件是否有修改，通過對比現(xiàn)有文件的時間戳 和第一次建立索引時所保留的文件元信息中的時間戳進(jìn)行對比，如果現(xiàn)有文件的時間戳 比第一次建立索引時所保留的文件元信息中的時間戳更新，那么執(zhí)行步驟S106，否則根 據(jù)檢索周期繼續(xù)執(zhí)行S105步驟。
步驟S106，對新文件進(jìn)行增量索引，生成新的索引文件。
步驟S107，將該含有增量信息的索引文件合并到原先的大索引文件中。
進(jìn)一步地，步驟S105中的檢索周期可以由用戶設(shè)定，也可以是每小時，每日，每周，每月。
進(jìn)一步地，步驟S106中所述增量索引形成的索引文件可以暫存在內(nèi)存中，以減 少CPU讀取和處理的工作量與時間。
進(jìn)一步地，步驟S107中所述的合并工作，在手機(jī)空閑時進(jìn)行。
進(jìn)一步地，索引文件合并完之后釋放原本占用的內(nèi)存空間。
圖2是本發(fā)明優(yōu)選實施例的索引文件目錄結(jié)構(gòu)
201索引文件的讀寫權(quán)限。
202索引文件的創(chuàng)建者。
203索引文件的最后修改者。
204索引文件大小，單位是字節(jié)。
205索引文件最后的修改日期。
206索引文件最后的修改時間。
207索引文件的名稱。
索引由一個或多個段組成。而每個段又由多個索引文件組成。屬于同一個段的 索引文件具有相同的前綴名以及不同的后綴名。在圖3中索引文件目錄由2個段組成， 分另1J 為 _movie 禾口 _email。
圖3是本發(fā)明優(yōu)選實施例的增量索引示意圖
301是索引目錄中含有2個段的示意圖，分別為_m0Vie*_m0Vie2。在索引合 并周期到來時，可以對相同類別的段進(jìn)行合并，減少索引文件，以此減少IO次數(shù)，提高 搜索性能。
302是合并_movie和_movie2以后的索引目錄結(jié)構(gòu)?？梢钥吹街饕乃饕募愋捅３植蛔?。但每個文件的大小已經(jīng)增大，并且在索引文件完全合并后，原先的小索 引文件將被刪除。
圖4是根據(jù)本發(fā)明的索引文件結(jié)構(gòu)示意圖。在本實施例中專門針對嵌入式設(shè)備 的本地搜索特性和特定的搜索結(jié)果，對4個索引文件中的內(nèi)容進(jìn)行了一定的定制。
在本實施例中，采用了 4個子索引文件來存儲索引信息，這樣的粒度劃分有利 于性能的最大化和資源利用的最小化。例如，如果某個域沒有被索引，通過操作可以很 快地基于.fom文件中的索引標(biāo)記從查詢中完全去除整個域。而如果項本身不出現(xiàn)，則不 需要查找位置信息。
其中.fom文件存儲了段中相關(guān)的文檔包含的所有的域名。其中每個域都被標(biāo)記 過，以此來反映它是否被索引過。本實施例中所采用的域包括修改時間，是否被修改 過，文件標(biāo)題，文件路徑，文件所屬類別，文件內(nèi)容等信息。
.tis文件保存了段中的所有項(由域名和值構(gòu)成的元組)，即分詞后的詞條。每 個項條目包含了它的文檔頻率，即Value所對應(yīng)的條目在多少個文檔中出現(xiàn)過。這里以 Value為“中興”為例，表示“中興”在5篇文檔中出現(xiàn)過。
.frq文件保存了每個項在文檔中的出現(xiàn)頻率。這里以.tis文件中的“中興”為 例，結(jié)合.frq文件，表示“中興”分別出現(xiàn)在“3G在中國.txt”、"Sina.html"、“中 興宣傳信息”、“來自小新.txt”，“XX的歌詞.txt”這5個文件中；而在“3G在中 國.txt”中出現(xiàn)了 12次“中興”，在“Stea.html”中出現(xiàn)了 15次“中興”，依次類推。 對應(yīng)“3G在中國.txt”文件，被用戶歷史選中的次數(shù)為5次，而在“S:ina.htmr’中，被 用戶歷史選中的次數(shù)100。
.prx文件列出了文檔中每個項的位置，以及顯示在搜索結(jié)果列表中被用戶選中后 的次數(shù)。這里以“中興”為例，表示“中興”在“來自小新.txt”中，以二元分詞劃 分后的分詞列表中，排在第3位和第8位。
圖5是根據(jù)本發(fā)明的搜索結(jié)果排序的流程示意圖。具體包括以下步驟
步驟陽01，根據(jù)用戶輸入的信息，在全文索引中進(jìn)行檢索，并得到檢索結(jié)果集。
步驟陽02，根據(jù)文件中出現(xiàn)搜索項的頻率來對檢索結(jié)果進(jìn)行權(quán)重計算。設(shè)搜索8項在文件η中出現(xiàn)的次數(shù)為Wn，總次數(shù)為WF。本發(fā)明以搜索項“中興”為例。文件 1為“3G在中國.txt”，文件2為“S:ina.htmr’，文件3為“中興宣傳信息.wmv”，文 件4為“來自小新.txt”，文件5為“XX的歌詞.txt”，對應(yīng)的Wn分別為W1 = 12，W2=15，W3 = 36，W4 = 2，W5 = 3。\￥產(chǎn)|> =\￥+\￥2+\￥3+\￥4+\￥5=68。那么ι每個文件對應(yīng)的權(quán)重Wnf = Wn/WF。在本發(fā)明實施例中，Wlf= 12/68，W2f= 15/68， W3f = 36/68，依此類推。初步得到的排序為W3f > W2f > Wlf > W5f > W4fo
步驟陽03，根據(jù)用戶歷史選中文件的次數(shù)進(jìn)行權(quán)重計算。設(shè)用戶歷史選中某個 文件η的次數(shù)為Hn，歷史選中搜索項的總次數(shù)為Hf。在本發(fā)明實施例中，以搜索項“中 興”為例。文件所對應(yīng)的Hn分別為H1 = 5，H2 = 100，H3 = 6，H4 = 7，H5 = 4。11產(chǎn)|；// =氏+場+113+^^1^=122。那么每個文件被歷史選中的權(quán)重為 =Hn/ιHf。在本發(fā)明實施例中，Hnl = 5/122，Hn2 = 100/122, Hn3 = 6/122，依此類推。以此得到的排序為H2f > H4f > H3f > Hlf > H5fo
步驟S504，根據(jù)搜索項在文件中出現(xiàn)頻率得到的權(quán)重Wdn文件被用戶歷史選中 次數(shù)的權(quán)重Hn，計算該文件的總權(quán)重Sn。計算公式為Sn = Wnf+Hnf。根據(jù)此公式得到的 Sn 分別為 S1 = 0.217，S2 =1.041，S3 = 0.578，S4 = 0.086，S5 = 0.077，其降序排序為 S2 > S3 > Sl > S4 > S5。
S505,根據(jù)Sn的降序順序，將搜索結(jié)果以列表方式反饋給用戶。在本發(fā)明實施 例中，其順序依次為“S:ina.htmr’， “中興宣傳信息.wmv”， “3G在中國.txt”， “來 自小新.txt”， “XX的歌詞.txt”。
S506,根據(jù)用戶選擇，將其選中的文件在.frq表格中的SelectFrequency這個字段數(shù)值增加1。
從以上分析可以看到，最終的排序結(jié)果，與單獨按照搜索項在文件中出現(xiàn)的頻 率進(jìn)行排序，或者以用戶歷史選中文件的次數(shù)進(jìn)行排序，都不一樣。從排序結(jié)果可以看 到，雖然文件“中興宣傳信息.wmv”包含搜索項的頻率很高，但是由于用戶平時查看文 件“S:ina.htmr’的次數(shù)更多，可以推測用戶是想通過搜索“中興”來查找自己以往最感 興趣、最喜歡瀏覽的文件和內(nèi)容是“Simditml”，而不是“中興宣傳信息.wmv”。
通過本發(fā)明，可以時時地自動更新手機(jī)本地索引表，以便滿足不時的本地搜索 需求，并且占用較少手機(jī)資源和能源。提高了移動終端用戶的使用體驗。
此外，對于搜索結(jié)果的處理方式，除了考慮了一般情況下的相關(guān)度算法，即搜 索項在文件中出現(xiàn)頻率這個因素；此外還考慮到了移動終端用戶的使用習(xí)慣，考慮其歷 史選中某個文件的次數(shù)，并作為相關(guān)度需要考察的因素之一。使得搜索結(jié)果更貼近用戶 所需。
另外，本發(fā)明還提出了一種在終端上更新索引并基于其對搜索結(jié)果排序的裝 置。圖6示出了根據(jù)本發(fā)明的裝置。如圖6所示，該裝置包括檢索單元，檢索文件 是否有修改；生成單元，當(dāng)文件存在修改時，對改變的文件進(jìn)行增量索引，生成新的索 引文件，其中所述增量索引中包含對文件的歷史選中次數(shù)；合并單元，將生成的新的索 引文件合并到原有的索引文件中；獲取單元，獲取用戶輸入的查詢關(guān)鍵字；查詢單元，查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以及文件的歷史選 中次數(shù)來對所述搜索結(jié)果進(jìn)行排序；顯示單元，將排序的搜索結(jié)果顯示給用戶；記錄單 元，記錄用戶選中文件的次數(shù)；更新單元，更新文件的所述歷史選中次數(shù)。
該裝置還包括比較單元，將現(xiàn)有文件的時間戳和前一次建立索引時所保留的 文件的時間戳進(jìn)行比較，如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件的時 間戳一樣，則判斷所述文件沒有被修改，如果現(xiàn)有文件的時間戳與前一次建立索引時所 保留的文件的時間戳不一樣，則判斷所述文件有修改。
檢索單元以預(yù)定的檢索周期檢索文件是否有修改。
合并單元定期地或者在檢測到手機(jī)空閑時或者在新的索引文件達(dá)到預(yù)定數(shù)量時 將所述新的索引文件合并到原有的索引文件中。
領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算 裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng) 絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲 在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊，或者將它 們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特 定的硬件和軟件結(jié)合。
以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的 技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的 任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種在終端上更新索引并基于其對搜索結(jié)果排序的方法，其特征在于，所述方法 包括以下步驟檢索文件是否有修改；當(dāng)所述文件存在修改時，對改變的文件進(jìn)行增量索引，生成新的索引文件，其中所 述增量索引中包含對所述文件的歷史選中次數(shù)；將生成的新的索引文件合并到原有的索引文件中； 獲取用戶輸入的關(guān)鍵字；查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以及所述文件 的歷史選中次數(shù)來對所述搜索結(jié)果進(jìn)行排序并顯示給用戶。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度 以及所述文件的歷史選中次數(shù)來對所述搜索結(jié)果進(jìn)行排序并顯示給用戶的步驟之后，還 包括以下步驟記錄用戶選中所述文件的次數(shù)，并更新所述文件的所述歷史選中次數(shù)。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，在檢索文件是否有修改的步驟中，具體 包括以下步驟將現(xiàn)有文件的時間戳和前一次建立索引時所保留的文件的時間戳進(jìn)行比較， 如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件的時間戳一樣，則判斷所 述文件沒有被修改，如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件的時間戳不一樣，則判斷 所述文件有修改。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，在檢索文件是否有修改的步驟中，以預(yù) 定的檢索周期檢索文件是否有修改。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，定期地或者在檢測到手機(jī)空閑時或者在 新的索引文件達(dá)到預(yù)定數(shù)量時將所述新的索引文件合并到原有的索引文件中。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，在定期地將所述新的索引文件合并到原 有的索引文件中的過程中，合并周期與用戶設(shè)定的檢索周期相同。
7.根據(jù)權(quán)利要求1所述的方法，其特征在于，在生成新的索引文件之后，將所生成的 新的索引文件暫存在終端內(nèi)存中，并在將所生成的新的索引文件合并到原有的索引文件 中之后，釋放存儲新的索引文件的終端內(nèi)存。
8.—種在終端上更新索引并基于其對搜索結(jié)果排序的裝置，其特征在于，包括 檢索單元，檢索文件是否有修改；生成單元，當(dāng)所述文件存在修改時，對改變的文件進(jìn)行增量索引，生成新的索引文 件，其中所述增量索引中包含對所述文件的歷史選中次數(shù)；合并單元，將生成的新的索引文件合并到原有的索引文件中； 獲取單元，獲取用戶輸入的查詢關(guān)鍵字；查詢單元，查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以 及所述文件的歷史選中次數(shù)來對所述搜索結(jié)果進(jìn)行排序； 顯示單元，將排序的所述搜索結(jié)果顯示給用戶。
9.根據(jù)權(quán)利要求8所述的裝置，其特征在于，所述裝置還包括記錄單元，記錄用戶選中所述文件的次數(shù)；更新單元，更新所述文件的所述歷史選中次數(shù)。
10.根據(jù)權(quán)利要求9所述的裝置，其特征在于，所述裝置還包括比較單元，將現(xiàn)有文件的時間戳和前一次建立索引時所保留的文件的時間戳進(jìn)行比較，如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件的時間戳一樣，則判斷所 述文件沒有被修改，如果現(xiàn)有文件的時間戳與前一次建立索引時所保留的文件的時間戳不一樣，則判斷 所述文件有修改。
全文摘要
本發(fā)明提供了一種在終端上更新索引并基于其對搜索結(jié)果排序的方法，包括以下步驟檢索文件是否有修改；當(dāng)文件存在修改時，對新文件進(jìn)行增量索引，生成新的索引文件，其中增量索引中包含對所述文件的歷史選中次數(shù)；將生成的新的索引文件合并到原有的索引文件中；獲取用戶輸入的關(guān)鍵字；查詢與關(guān)鍵字有關(guān)的搜索結(jié)果，根據(jù)搜索結(jié)果與關(guān)鍵字之間的相關(guān)度以及所述文件的歷史選中次數(shù)來對所述搜索結(jié)果進(jìn)行排序并顯示給用戶，通過本發(fā)明，可以時時地自動更新手機(jī)本地索引表，占用較少手機(jī)資源和能源，搜索結(jié)果更加人性化，提高了移動終端用戶的使用體驗。
文檔編號G06F17/30GK102023991SQ20091017567
公開日2011年4月20日 申請日期2009年9月21日 優(yōu)先權(quán)日2009年9月21日
發(fā)明者李斌, 白洛, 紀(jì)中偉, 翁儒復(fù) 申請人:中興通訊股份有限公司