本發(fā)明涉及信息處理技術領域，尤其涉及一種通訊錄存儲同步的方法及裝置。

背景技術：

一些終端的APP通過收集分析用戶的通訊錄列表，從而查詢注冊關系，進而推薦建立關系。例如終端的社交化類APP，該類APP通過分析用戶通訊錄列表中的好友關系，進而起到推薦好友關系的作用。因此，如何有效地在終端的APP中對用戶通訊錄進行存儲同步，是這些終端APP更好發(fā)揮其功能的基礎。

在現(xiàn)有技術中，終端的APP一般將用戶的通訊錄列表存儲于本地，在APP啟動時或者在APP使用過程中對用戶的通訊錄列表進行拉取。但是，將用戶的通訊錄列表存儲于本地存在被竊取的風險，會給用戶帶來安全隱患。并且，這種通訊錄列表存儲方式使得在基于通訊錄列表推薦建立關系時，僅能夠基于客戶端進行，當用戶在不同設備上使用客戶端時，無法有效地進行不同終端客戶端的通訊錄同步，因此基于通訊錄列表推薦的建立關系并不完整。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明提供了一種通訊錄存儲同步的方法及裝置，提高基于通訊錄服務的完整性。

本發(fā)明為解決技術問題而采用的技術方案是提供一種通訊錄存儲同步的方法，所述方法包括：服務器端根據(jù)用戶標識UID建立通訊錄存儲列表；接收客戶端上傳的通訊錄數(shù)據(jù)，確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述根據(jù)用戶標識UID建立通訊錄存儲列表包括：在用戶注冊獲取UID時，針對該UID建立存儲列表；或者，在首次接收到客戶端上傳通訊錄數(shù)據(jù)時根據(jù)客戶端所采用的UID建立存儲列表。

根據(jù)本發(fā)明一優(yōu)選實施例，所述存儲列表包含UID、終端設備號、通訊錄數(shù)據(jù)以及數(shù)據(jù)產(chǎn)生時間。

根據(jù)本發(fā)明一優(yōu)選實施例，所述接收客戶端上傳的通訊錄數(shù)據(jù)，確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置包括：根據(jù)客戶端采用的UID和客戶端所在終端設備號，將用戶的通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述將用戶的通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置包括：利用所述用戶的通訊錄數(shù)據(jù)，覆蓋確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置中已有的通訊錄數(shù)據(jù)。

根據(jù)本發(fā)明一優(yōu)選實施例，所述方法還包括：接收到客戶端發(fā)送的同步請求時，將該客戶端所采用UID對應的存儲列表中的通訊錄數(shù)據(jù)進行合并和去重后，發(fā)送給該客戶端。

本發(fā)明為解決技術問題提供的另一種通訊錄存儲同步的方法，所述方法包括：客戶端啟動時獲取配置參數(shù)；根據(jù)獲取的配置參數(shù)，上傳通訊錄數(shù)據(jù)，以供服務器確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述啟動時獲取配置參數(shù)包括：從參數(shù)配置系統(tǒng)獲取配置參數(shù)；或者，從本地讀取預先從參數(shù)配置系統(tǒng)獲取的配置參數(shù)。

根據(jù)本發(fā)明一優(yōu)選實施例，所述根據(jù)獲取的配置參數(shù)，上傳通訊錄數(shù)據(jù)包括：若當前時間距離通訊錄的前次上傳時間的時長大于上傳時間間隔M，則按照每次N條的順序將用戶的通訊錄數(shù)據(jù)上傳；否則不上傳用戶的通訊錄數(shù)據(jù)；其中所述M和N從所述配置參數(shù)中獲取。

根據(jù)本發(fā)明一優(yōu)選實施例，所述方法還包括：向服務器端發(fā)送同步請求；利用服務器端返回的通訊錄數(shù)據(jù)對本地存儲的通訊錄數(shù)據(jù)進行更新。

本發(fā)明還提供了一種通訊錄存儲同步的裝置，其特征在于，所述裝置包括：

建立單元，用于服務器端根據(jù)用戶標識UID建立通訊錄存儲列表；

存儲單元，用于接收客戶端上傳的通訊錄數(shù)據(jù)，確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述建立單元在根據(jù)用戶標識UID建立通訊錄存儲列表時執(zhí)行：在用戶注冊獲取UID時，針對該UID建立存儲列表；或者，在首次接收到客戶端上傳通訊錄數(shù)據(jù)時根據(jù)客戶端所采用的UID建立存儲列表。

根據(jù)本發(fā)明一優(yōu)選實施例，所述建立單元建立的存儲列表包含UID、終端設備號、通訊錄數(shù)據(jù)以及數(shù)據(jù)產(chǎn)生時間。

根據(jù)本發(fā)明一優(yōu)選實施例，所述存儲單元在接收客戶端上傳的通訊錄數(shù)據(jù)，確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置時，具體執(zhí)行：根據(jù)客戶端采用的UID和客戶端所在終端設備號，將用戶的通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述存儲單元在將用戶的通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置后，進一步執(zhí)行：利用所述用戶的通訊錄數(shù)據(jù)，覆蓋確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置中已有的通訊錄數(shù)據(jù)。

根據(jù)本發(fā)明一優(yōu)選實施例，所述存儲單元還包括：第二同步單元，接收到客戶端發(fā)送的同步請求時，將該客戶端所采用UID對應的存儲列表中的通訊錄數(shù)據(jù)進行合并和去重后，發(fā)送給該客戶端。

本發(fā)明提供了另一種通訊錄存儲同步的裝置，其特征在于，所述裝置包括：

獲取單元，用于在客戶端啟動時獲取配置參數(shù)；

上傳單元，用于根據(jù)獲取的配置參數(shù)，上傳通訊錄數(shù)據(jù)，以供服務器確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

根據(jù)本發(fā)明一優(yōu)選實施例，所述獲取單元在啟動時獲取配置參數(shù)時執(zhí)行：從參數(shù)配置系統(tǒng)獲取配置參數(shù)；或者，從本地讀取預先從參數(shù)配置系統(tǒng)獲取的配置參數(shù)。

根據(jù)本發(fā)明一優(yōu)選實施例，所述上傳單元在根據(jù)獲取的配置參數(shù)，上傳通訊錄數(shù)據(jù)時，具體執(zhí)行：若當前時間距離通訊錄的前次上傳時間的時長大于上傳時間間隔M，則按照每次N條的順序將用戶的通訊錄數(shù)據(jù)上傳；否則不上傳用戶的通訊錄數(shù)據(jù)；其中所述M和N從所述配置參數(shù)中獲取。

根據(jù)本發(fā)明一優(yōu)選實施例，所述上傳單元還包括：第一同步單元，向服務器端發(fā)送同步請求；利用服務器端返回的通訊錄數(shù)據(jù)對本地存儲的通訊錄數(shù)據(jù)進行更新。

由以上技術方案可以看出，本發(fā)明通過利用客戶端用戶的UID，在服務器端構建用戶通訊錄的存儲列表，并結合配置參數(shù)對當前時間距離通訊錄的前次上傳時間的時長進行判斷，從而準確快速地對用戶通訊錄進行上傳存儲的操作，減少系統(tǒng)流量的浪費，并且能夠有效地進行不同終端客戶端的通訊錄同步，提高基于通訊錄服務的完整性。

【附圖說明】

圖1為本發(fā)明實施例提供的方法流程圖。

圖2為本發(fā)明另一實施例提供的方法流程圖。

圖3為本發(fā)明實施例提供的裝置結構示意圖。

【具體實施方式】

為了使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖和具體實施例對本發(fā)明進行詳細描述。

在本發(fā)明實施例中使用的術語是僅僅出于描述特定實施例的目的，而非旨在限制本發(fā)明。在本發(fā)明實施例和所附權利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。

應當理解，本文中使用的術語“和/或”僅僅是一種描述關聯(lián)對象的關聯(lián)關系，表示可以存在三種關系，例如，A和/或B，可以表示：單獨存在A，同時存在A和B，單獨存在B這三種情況。另外，本文中字符“/”，一般表示前后關聯(lián)對象是一種“或”的關系。

取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“響應于確定”或“響應于檢測”。類似地，取決于語境，短語“如果確定”或“如果檢測(陳述的條件或事件)”可以被解釋成為“當確定時”或“響應于確定”或“當檢測(陳述的條件或事件)時”或“響應于檢測(陳述的條件或事件)”。

圖1為本發(fā)明一實施例提供的方法流程圖，如圖1所示，該方法可以主要包括以下步驟：

在101中，服務器端根據(jù)用戶標識UID建立通訊錄存儲列表。

可選地，在本實施例的一個具體實現(xiàn)過程中，服務器端根據(jù)用戶標識UID建立通訊錄存儲列表，可以為在用戶注冊獲取UID時，針對該UID建立存儲列表。也可以為在首次接收到客戶端上傳通訊錄數(shù)據(jù)時，根據(jù)客戶端所采用的UID建立存儲列表。

由用戶標識UID生成的存儲列表，如表1所示，該存儲列表包含UID、Cuid、Phone-Number、Add-time。其中，UID表示通訊錄主人的UID，Cuid表示終端設備號，Phone-Number表示通訊錄數(shù)據(jù)，Add-time則表示數(shù)據(jù)產(chǎn)生時間。

更具體來說，存儲列表中的UID(通訊錄主人UID)用于表明該存儲列表屬于哪一個用戶；Cuid(終端設備號)用于表明用戶的通訊錄數(shù)據(jù)由哪一個終端所上傳，例如，Cuid-A表示A終端，Cuid-B表示B終端，以此類推；Phone-Number(通訊錄數(shù)據(jù))用于表明由不同終端上傳的用戶通訊錄數(shù)據(jù)；Add-time(數(shù)據(jù)產(chǎn)生時間)則用于記錄每個終端上傳用戶通訊錄數(shù)據(jù)的時間。

表1通訊錄存儲列表

在102中，客戶端啟動時獲取配置參數(shù)。

在本步驟中，客戶端啟動時獲取的配置參數(shù)由參數(shù)配置系統(tǒng)下發(fā)，參數(shù)配置系統(tǒng)可以位于服務器端，也可以位于其他位置，本發(fā)明對此不進行限定。

可選地，在本實施例的一個具體實現(xiàn)過程中，客戶端啟動時獲取的配置參數(shù)可以直接從參數(shù)配置系統(tǒng)處獲取配置參數(shù)；或者，還可以從本地讀取預先從參數(shù)配置系統(tǒng)獲取的配置參數(shù)。

在本步驟中，客戶端在啟動時獲取配置參數(shù)還進一步包括：參數(shù)配置系統(tǒng)對配置參數(shù)進行更改，可以為參數(shù)配置系統(tǒng)接收用戶的請求后進行更改，也可以為參數(shù)配置系統(tǒng)自動進行更改。若由參數(shù)配置系統(tǒng)下發(fā)的配置參數(shù)發(fā)生變化時，客戶端則會根據(jù)新的配置參數(shù)對用戶的通訊錄數(shù)據(jù)進行操作。

在103中，根據(jù)獲取的配置參數(shù)，客戶端確定是否上傳用戶的通訊錄數(shù)據(jù)。

在根據(jù)獲取的配置參數(shù)，客戶端確定是否上傳用戶的通訊錄數(shù)據(jù)還包括：在客戶端生成用戶通訊錄讀取授權的界面，用于申請獲得讀取用戶通訊錄的授權。該步驟主要是為了保證獲取通訊錄是經(jīng)過用戶的同意，減少用戶隱私泄露的風險，提高用戶通訊錄的安全系數(shù)。

在本步驟中，由客戶端記錄每次上傳通訊錄數(shù)據(jù)的時間，并將其存儲在客戶端的KV存儲結構中，進而根據(jù)所存儲的通訊錄上傳時間得到當前時間距離通訊錄的前次上傳時間的時長。

可選地，在本實施例的一個具體實現(xiàn)過程中，若客戶端進行首次上傳用戶通訊錄數(shù)據(jù)的操作時，可以在獲得用戶對客戶端讀取通訊錄的授權后直接上傳用戶的通訊錄數(shù)據(jù)，并由客戶端記錄首次上傳的時間。

若客戶端不是首次上傳，則在獲得用戶對客戶端讀取通訊錄的授權后，根據(jù)配置參數(shù)，客戶端對當前時間距離通訊錄的前次上傳時間的時長進行判斷，確定是否上傳用戶的通訊錄數(shù)據(jù)。

可選地，在本實施例的一個具體實現(xiàn)過程中，若當前時間距離通訊錄的前次上傳時間的時長大于上傳時間間隔M，則對用戶的通訊錄數(shù)據(jù)進行上傳，將用戶的通訊錄數(shù)據(jù)按照每次N條的順序上傳。若當前時間距離通訊錄的前次上傳時間的時長小于上傳時間間隔M，則不進行對通訊錄數(shù)據(jù)上傳的操作。其中的上傳時間間隔M和單次上傳數(shù)量N從配置參數(shù)中獲取，M和N的值可以為任意值，本發(fā)明對此不進行限定。

舉例來說，若配置參數(shù)中的上傳時間間隔M為1周，客戶端當前時間距離通訊錄的前次上傳時間的時長為2周，則大于配置參數(shù)中的M，需要將用戶的通訊錄數(shù)據(jù)進行上傳，進而按照每次N條的順序將用戶的通訊錄數(shù)據(jù)上傳。

再舉例來說，若配置參數(shù)中的上傳時間間隔M為1周，當前時間距離通訊錄的前次上傳時間的時長為3天，則小于配置參數(shù)中的M，就不需要對用戶的通訊錄數(shù)據(jù)進行上傳。

在104中，若客戶端確定上傳用戶的通訊錄數(shù)據(jù)，則進行上傳用戶通訊錄數(shù)據(jù)的操作。

在本步驟中，采用數(shù)據(jù)加密和數(shù)據(jù)壓縮的方式對用戶的通訊錄數(shù)據(jù)進行上傳，以保證用戶的通訊錄數(shù)據(jù)在上傳過程中的安全性，并能夠節(jié)省通訊錄數(shù)據(jù)上傳的流量。

并且在本步驟中上傳通訊錄數(shù)據(jù)的同時，還需要攜帶上傳通訊錄數(shù)據(jù)的客戶端所采用的UID和客戶端所在終端的設備號。

在105中，服務器端確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

在本步驟中，由于在上傳用戶通訊錄數(shù)據(jù)的同時，攜帶有客戶端所采用的UID和客戶端所在終端的設備號，其中客戶端所采用的UID用于尋找以該UID建立的存儲列表，而客戶端所在終端的設備號則用于確定通訊錄數(shù)據(jù)的在存儲列表中的存儲位置。即根據(jù)客戶端所采用的UID和客戶端所在終端的設備號，將用戶的通訊錄數(shù)據(jù)存儲在以該UID建立的存儲列表中的對應位置。也就是說，對應于不同終端的通訊錄數(shù)據(jù)分別在由同一個UID建立的存儲列表中的不同位置進行存儲，如表1中Cuid-A和Cuid-B所示，即將由A終端客戶端上傳的用戶通訊錄數(shù)據(jù)存儲在Cuid-A下面，將由B終端客戶端上傳的用戶通訊錄數(shù)據(jù)存儲在Cuid-B下面。

在本步驟中，對用戶通訊錄數(shù)據(jù)進行存儲的過程中，還包括對存儲于服務器端存儲列表中的通訊錄數(shù)據(jù)進行糾正的操作，即利用用戶的通訊錄數(shù)據(jù)，覆蓋確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置中已有的通訊錄數(shù)據(jù)。

服務器端無法對已存儲的通訊錄數(shù)據(jù)進行更改，因此當用戶在終端對通訊錄數(shù)據(jù)進行增加或刪除時，相對應的用戶通訊錄就發(fā)生了變化，則利用客戶端后一次上傳的通訊錄數(shù)據(jù)，也就是最新的通訊錄數(shù)據(jù)，覆蓋在存儲列表對應位置上已有的通訊錄數(shù)據(jù)。

舉例來說，終端A客戶端在上傳通訊錄數(shù)據(jù)的同時上傳該終端的設備號，記為Cuid-A，表明所上傳的通訊錄數(shù)據(jù)屬于終端A。當終端A客戶端在下次上傳通訊錄數(shù)據(jù)時，同樣攜帶該終端的設備號Cuid-A，并在通訊錄存儲列表中找到對應該設備號的通訊錄數(shù)據(jù)，將由終端A客戶端在本次上傳的通訊錄數(shù)據(jù)覆蓋前一次上傳的通訊錄數(shù)據(jù)，以此完成數(shù)據(jù)的更新。并且根據(jù)終端設備號進行該操作，能夠保證只針對屬于同一個終端的通訊錄數(shù)據(jù)進行糾正更新，不會發(fā)生錯刪現(xiàn)象。

圖2為本發(fā)明另一實施例提供的方法流程圖，如圖2所示，客戶端1和客戶端2分別表示位于終端A與終端B中的客戶端，兩個客戶端的用戶標識UID相同。

在201中，服務器端根據(jù)用戶標識UID建立存儲列表。

在本步驟中，根據(jù)用戶標識UID建立存儲列表的過程與101相同，在此不再贅述。

可選地，在本實施例的一個具體實現(xiàn)過程中，服務器端可以由客戶端1中的用戶標識UID建立存儲列表?？蛻舳?和客戶端1所采用的UID相同，則客戶端2不需要再建立存儲列表，根據(jù)UID在服務器端尋找由該UID生成的存儲列表即可。也可以為服務器端由客戶端2中的用戶標識UID建立存儲列表，則客戶端1就不需要再建立存儲結構，根據(jù)UID在服務器端尋找即可。本發(fā)明對此不進行限定，生成的存儲列表如表2所示。其中UID代表客戶端1和客戶端2的用戶標識UID，Cuid-A代表位于終端A的客戶端，Cuid-B代表位于終端B的客戶端，Phone-number代表通訊錄數(shù)據(jù)，Add-time代表通訊錄數(shù)據(jù)的上傳時間。

表2實施例2的存儲列表

在202中，客戶端1和客戶端2在啟動時獲取配置參數(shù)。

在本步驟中，客戶端1和客戶端2啟動時獲取配置參數(shù)的過程與102相同，在此不進行贅述。在本實施例中，參數(shù)配置系統(tǒng)將配置參數(shù)分別下發(fā)給客戶端1和客戶端2。

在203中，根據(jù)獲取的配置參數(shù)，客戶端1和客戶端2確定是否上傳用戶的通訊錄數(shù)據(jù)。

本步驟中確定上傳操作與103相同，分別根據(jù)存儲在客戶端1和客戶端2中的上傳時間確定當前時間距離通訊錄的前次上傳時間的時長，再根據(jù)下發(fā)的配置參數(shù)，客戶端對終端A和終端B中用戶的通訊錄數(shù)據(jù)進行上傳操作，在此不再贅述。

在204中，若客戶端1和客戶端2確定上傳用戶的通訊錄數(shù)據(jù)，則進行上傳用戶通訊錄數(shù)據(jù)的操作，客戶端1和客戶端2分別將各自終端用戶的通訊錄數(shù)據(jù)進行上傳。

本步驟中的上傳操作與104相同，在此不再贅述。

在205中，客戶端1和客戶端2將兩個終端用戶的通訊錄數(shù)據(jù)進行上傳后，服務器端確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

在本步驟中，在上傳通訊錄數(shù)據(jù)的同時，客戶端1和客戶端2分別攜帶所采用UID和各自終端的設備號，并根據(jù)所采用的UID和各自終端設備號將不同終端的通訊錄數(shù)據(jù)在以UID建立的存儲結構中的對應位置存儲。如表2所示，將由終端A客戶端上傳的通訊錄數(shù)據(jù)存儲在Cuid-A下的Phone-Number中，在Add-time中記錄上傳上傳時間，由終端B客戶端上傳的通訊錄數(shù)據(jù)存儲在Cuid-B下的Phone-Number中，在Add-time中記錄上傳時間。

在206中，客戶端向服務器端發(fā)送同步請求。

在207中，服務器端接收到客戶端發(fā)送的同步請求時，將該客戶端所采用UID對應的存儲列表中的通訊錄數(shù)據(jù)進行合并和去重后，發(fā)送給該客戶端。而客戶端則利用服務器端返回的通訊錄數(shù)據(jù)對本地存儲的通訊錄數(shù)據(jù)進行更新。

可選地，在本實施例的一個具體實現(xiàn)過程中，客戶端1向服務器端發(fā)送同步請求，服務器端在接收到客戶端1發(fā)送的同步請求時，將該客戶端采用UID對應的存儲列表中的全部通訊錄數(shù)據(jù)進行合并和去重后，發(fā)送給客戶端1，客戶端1則利用由服務器端返回的通訊錄數(shù)據(jù)對終端A本地存儲的通訊錄數(shù)據(jù)進行更新，即終端A客戶端1中的本地數(shù)據(jù)包含有服務器端對應該客戶端采用的UID建立的存儲列表中的全部通訊錄數(shù)據(jù)。同樣的道理，若客戶端2向服務器發(fā)送同步請求的操作與上述類似，在此不進行贅述。

需要說明的是，在圖2所示實施例中，僅僅表明了服務器端與客戶端1和客戶端2之間上傳通訊錄數(shù)據(jù)的交互示意圖，圖中的步驟標號并不是對客戶端1和客戶端2所執(zhí)行操作的時間順序進行限制。即客戶端1與服務器端之間的交互可以按照圖2所示步驟標號，客戶端2與服務器端之間的交互也可以按照圖2所示步驟標號，但客戶端1與客戶端2并非同步執(zhí)行圖2中所示步驟。例如，客戶端1和客戶端2可以在不同時間進行配置參數(shù)的獲取，也可以在不同時間進行通訊錄數(shù)據(jù)的上傳，也可以在不同時間進行通訊錄數(shù)據(jù)的同步。

利用本發(fā)明提供的技術方案，客戶端能夠對用戶通訊錄數(shù)據(jù)的上傳操作進行分析，減少不必要上傳通訊錄數(shù)據(jù)造成的流量浪費，還能夠避免APP在啟動或者在APP使用時獲取用戶的通訊錄數(shù)據(jù)導致APP的啟動速度變慢、不利于實時處理等問題，并且在服務器端根據(jù)用戶的UID建立存儲列表對用戶的通訊錄數(shù)據(jù)存儲，能夠有效地進行不同終端客戶端的通訊錄同步，提高基于通訊錄服務的完整性。

下面對本發(fā)明實施例提供的裝置進行詳述。如圖3中所示，設置于服務器端的裝置主要包括：建立單元31和存儲單元34，還可以包括第二同步單元36。

建立單元31在服務器端根據(jù)用戶標識UID建立通訊錄存儲列表，可以為在用戶注冊獲取UID時，針對該UID建立存儲列表。也可以為在首次接收到客戶端上傳通訊錄數(shù)據(jù)時，根據(jù)客戶端所采用的UID建立存儲列表。

由用戶標識UID生成的存儲列表，如表1所示，該存儲列表包含UID、Cuid、Phone-Number、Add-time。其中，UID表示通訊錄主人的UID，Cuid表示終端設備號，Phone-Number表示通訊錄數(shù)據(jù)，Add-time則表示數(shù)據(jù)產(chǎn)生時間。

更具體來說，存儲列表中的UID(通訊錄主人UID)用于表明該存儲列表屬于哪一個用戶；Cuid(終端設備號)用于表明用戶的通訊錄數(shù)據(jù)由哪一個終端所上傳，例如，Cuid-A表示A終端，Cuid-B表示B終端，以此類推；Phone-Number(通訊錄數(shù)據(jù))用于表明由不同終端上傳的用戶通訊錄數(shù)據(jù)；Add-time(數(shù)據(jù)產(chǎn)生時間)則用于記錄每個終端上傳用戶通訊錄數(shù)據(jù)的時間。

存儲單元34，服務器端確定該客戶端采用的UID并將該通訊錄數(shù)據(jù)存儲在確定出的UID對應的所述存儲列表中的對應位置。

在本步驟中，由于在上傳用戶通訊錄數(shù)據(jù)的同時，攜帶有客戶端所采用的UID和客戶端所在終端的設備號，其中客戶端所采用的UID用于尋找存儲以該UID建立的存儲列表，而客戶端所在終端的設備號用于確定通訊錄數(shù)據(jù)的存儲位置。即根據(jù)客戶端所采用的UID和客戶端所在終端的設備號，將某一終端用戶的通訊錄數(shù)據(jù)存儲在以該UID建立的存儲列表中的對應位置。也就是說，將對應于不同終端的通訊錄數(shù)據(jù)分別在由同一個UID建立的存儲列表中進行存儲，如表1中Cuid-A和Cuid-B所示，即將由A終端客戶端上傳的用戶通訊錄數(shù)據(jù)存儲在Cuid-A下面，將由B終端客戶端上傳的用戶通訊錄數(shù)據(jù)存儲在Cuid-B下面。

在本步驟中，對用戶的通訊錄數(shù)據(jù)進行存儲的過程中，還包括對存儲于服務器端存儲列表中的通訊錄數(shù)據(jù)進行糾正的操作，即利用用戶的通訊錄數(shù)據(jù)，覆蓋確定出的UID對應的所述存儲列表中客戶端所在終端設備號對應的位置中已有的通訊錄數(shù)據(jù)。

服務器端無法對已存儲的通訊錄數(shù)據(jù)進行更改，因此當用戶在終端對通訊錄數(shù)據(jù)進行增加或刪除時，相對應的用戶通訊錄就發(fā)生了變化，則利用客戶端后一次上傳的通訊錄數(shù)據(jù)，也就是最新的通訊錄數(shù)據(jù)，覆蓋在存儲列表對應位置上已有的通訊錄數(shù)據(jù)。

舉例來說，終端A客戶端在上傳通訊錄數(shù)據(jù)的同時上傳該終端的設備號，記為Cuid-A，表明所上傳的通訊錄數(shù)據(jù)屬于終端A。當終端A客戶端在下次上傳通訊錄數(shù)據(jù)時，同樣攜帶該終端的設備號Cuid-A，并在通訊錄存儲列表中找到對應該設備號的通訊錄數(shù)據(jù)，將由終端A客戶端在本次上傳的通訊錄數(shù)據(jù)覆蓋前一次上傳的通訊錄數(shù)據(jù)，以此完成數(shù)據(jù)的更新。并且根據(jù)終端設備號進行該操作，能夠保證只針對屬于該終端的通訊錄數(shù)據(jù)進行糾正更新，不會發(fā)生誤刪現(xiàn)象。

第二同步單元36，接收客戶端發(fā)送的同步請求，將該客戶端所采用UID對應的存儲列表中的通訊錄數(shù)據(jù)進行合并和去重后，發(fā)送給該客戶端。

繼續(xù)如圖3所示，設置于客戶端的裝置主要包括：獲取單元32和上傳單元33，還可以包括第一同步單元35。

獲取單元32，在客戶端啟動時獲取配置參數(shù)。

在本步驟中，客戶端啟動時獲取的配置參數(shù)由參數(shù)配置系統(tǒng)下發(fā)，參數(shù)配置系統(tǒng)可以位于服務器端，也可以位于其他位置，本發(fā)明對此不進行限定。

可選地，在本實施例的一個具體實現(xiàn)過程中，客戶端啟動時獲取的配置參數(shù)可以直接從參數(shù)配置系統(tǒng)處獲取配置參數(shù)；或者，還可以從本地讀取預先從參數(shù)配置系統(tǒng)獲取的配置參數(shù)。

在本步驟中，客戶端在啟動時獲取配置參數(shù)還進一步包括：參數(shù)配置系統(tǒng)對配置參數(shù)進行更改，可以為參數(shù)配置系統(tǒng)接收用戶的請求后進行更改，也可以為參數(shù)配置系統(tǒng)自動進行更改。若由參數(shù)配置系統(tǒng)下發(fā)的配置參數(shù)發(fā)生變化時，客戶端則會根據(jù)新的配置參數(shù)對用戶的通訊錄數(shù)據(jù)進行操作。

上傳單元33，首先根據(jù)獲取的配置參數(shù)，確定是否對用戶的通訊錄數(shù)據(jù)進行上傳。若客戶端確定上傳用戶的通訊錄數(shù)據(jù)，則進行上傳用戶通訊錄數(shù)據(jù)的操作。

在根據(jù)獲取的配置參數(shù)，客戶端確定是否對用戶的通訊錄數(shù)據(jù)進行上傳之前還包括：在客戶端生成用戶通訊錄讀取授權的界面，用于申請獲得讀取用戶通訊錄的授權。主要是為了保證獲取通訊錄是經(jīng)過用戶的同意，減少用戶隱私泄露的風險，提高用戶通訊錄的安全系數(shù)。

在本步驟中，由客戶端記錄每次上傳通訊錄數(shù)據(jù)的時間，并將其存儲在客戶端的KV存儲結構中，進而根據(jù)所存儲的通訊錄上傳時間得到當前時間距離通訊錄的前次上傳時間的時長。

可選地，在本實施例的一個具體實現(xiàn)過程中，若客戶端進行首次上傳用戶通訊錄數(shù)據(jù)的操作，在獲得用戶對客戶端讀取通訊錄的授權后直接進行對用戶的通訊錄數(shù)據(jù)上傳的操作，并由客戶端記錄首次上傳的時間。

若客戶端不是首次上傳，則在獲得用戶對客戶端讀取通訊錄的授權后，根據(jù)配置參數(shù)，客戶端對當前時間距離通訊錄的前次上傳時間的時長進行判斷，確定是否對用戶的通訊錄數(shù)據(jù)進行上傳。

可選地，在本實施例的一個具體實現(xiàn)過程中，若當前時間距離通訊錄的前次上傳時間的時長大于上傳時間間隔M，則對用戶的通訊錄數(shù)據(jù)進行上傳，將用戶的通訊錄數(shù)據(jù)按照每次N條的順序上傳。若當前時間距離通訊錄的前次上傳時間的時長小于上傳時間間隔M，則不進行對通訊錄數(shù)據(jù)上傳的操作。其中的上傳時間間隔M和單次次上傳數(shù)量N從配置參數(shù)中獲取，M和N的值可以為任意值，本發(fā)明對此不進行限定。

舉例來說，若配置參數(shù)中的上傳時間間隔M為1周，客戶端當前時間距離通訊錄的前次上傳時間的時長為2周，則大于配置參數(shù)中的M，需要將用戶的通訊錄數(shù)據(jù)進行上傳，進而按照每次N條的順序將用戶的通訊錄數(shù)據(jù)上傳。

再舉例來說，若配置參數(shù)中的上傳時間間隔M為1周，當前時間距離通訊錄的前次上傳時間的時長為3天，則小于配置參數(shù)中的M，就不需要對用戶的通訊錄數(shù)據(jù)進行上傳。

當確定要上傳用戶通訊錄數(shù)據(jù)時，采用數(shù)據(jù)加密和數(shù)據(jù)壓縮的方式對用戶的通訊錄數(shù)據(jù)進行上傳，以保證用戶的通訊錄數(shù)據(jù)在上傳過程中的安全性，并能夠節(jié)省通訊錄數(shù)據(jù)上傳的流量。

并且在本步驟中上傳通訊錄數(shù)據(jù)的同時，還需要攜帶上傳通訊錄數(shù)據(jù)的客戶端所采用的UID和客戶端所在終端的設備號。

第一同步單元35，向服務器端發(fā)送同步請求，并利用服務器端返回的通訊錄數(shù)據(jù)對本地存儲的通訊錄數(shù)據(jù)進行更新。

利用本發(fā)明提供的技術方案，客戶端能夠對用戶通訊錄數(shù)據(jù)的上傳操作進行分析，減少不必要上傳通訊錄數(shù)據(jù)造成的流量浪費，還能夠避免APP在啟動或者在APP使用時獲取用戶的通訊錄數(shù)據(jù)導致APP的啟動速度變慢、不利于實時處理等問題，并且在服務器端根據(jù)用戶的UID建立存儲列表對用戶的通訊錄數(shù)據(jù)存儲，能夠有效地進行不同終端客戶端的通訊錄同步，提高基于通訊錄服務的完整性。

在本發(fā)明所提供的幾個實施例中，應該理解到，所揭露的裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用硬件加軟件功能單元的形式實現(xiàn)。

上述以軟件功能單元的形式實現(xiàn)的集成的單元，可以存儲在一個計算機可讀取存儲介質中。上述軟件功能單元存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)或處理器(processor)執(zhí)行本發(fā)明各個實施例所述方法的部分步驟。而前述的存儲介質包括：U盤、移動硬盤、只讀存儲器(Read-Only Memory，ROM)、隨機存取存儲器(Random Access Memory，RAM)、磁碟或者光盤等各種可以存儲程序代碼的介質。

以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發(fā)明保護的范圍之內。