本申請涉及電子技術領域，尤其涉及一種信息處理方法及系統(tǒng)。

背景技術：

當前，通過手機App打車已經(jīng)成為一種趨勢，為了使用App打車，用戶需要對該應用進行一系列操作，從而完成網(wǎng)上打車服務。

在使用打車軟件的過程中，若是打車軟件需要更新時，客戶端需要到服務器重新下載安裝包，比如說之前的安裝包為15M，那更新時，客戶端還需要再到服務器重新在15M以上的安裝包重新安裝，這樣就減少了客戶端的流量損耗。

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

本發(fā)明實施例提供了一種信息處理方法及系統(tǒng)，用以解決現(xiàn)有技術中軟件更新時，都需要重新在安裝包，導致客戶端流量損耗的問題。

其具體的技術方案如下：

一種信息處理方法，所述方法包括：

客戶端生成應用程序更新請求，并將所述更新請求發(fā)送至服務器；

接收所述服務器返回的安裝包差量的存儲地址，其中，所述安裝包差量為兩個版本的安裝包之間的差異數(shù)據(jù)；

根據(jù)所述存儲地址，獲取對應的安裝包差量；

根據(jù)所述安裝包差量，更新所述應用程序。

可選的，客戶端生成應用程序更新請求，包括：

客戶端獲取所述應用程序的版本號，其中，所述版本號用于服務器確定是否對所述應用程序進行更新；

將所述版本號添加至所述更新請求中，生成包含所述版本號的所述更新請求。

可選的，根據(jù)所述存儲地址，獲取對應的安裝包差量，包括：

接收服務器返回的基于所述更新請求中的版本號對應的存儲地址；

根據(jù)所述存儲地址，獲取存儲地址對應的存儲空間中的所述安裝包差量。

可選的，根據(jù)所述安裝包差量，更新所述應用程序，包括：

獲取本地已有安裝包；

將所述本地安裝包與所述安裝包差量進行合并，得到更新安裝包；

根據(jù)所述更新安裝包，更新所述應用程序。

可選的，在獲取對應的安裝包差量之后，并且在更新所述應用程序之前，所述方法還包括：

通過指定校驗方式，對生成的所述安裝包差量進行校驗；

若校驗通過，則根據(jù)所述安裝差量包，更新所述應用程序。

一種信息處理方法，所述方法包括：

服務器接收客戶端發(fā)送的應用程序的更新請求；

在所述更新請求中獲取所述應用程序的版本號，并根據(jù)所述版本號判定所述應用程序是否升級；

若是，則根據(jù)所述版本號，確定出對應的安裝包差量，并將所述安裝包差量發(fā)送至所述客戶端，其中，所述安裝包差量表征兩個版本的安裝包之間的差異數(shù)據(jù)；

若否，則忽略所述更新請求。

可選的，在服務器接收客戶端發(fā)送的應用程序的更新請求之前，所述方法還包括：

檢測所述應用程序是否存在版本更新；

若是，則根據(jù)更新數(shù)據(jù)包以及當前數(shù)據(jù)包，獲取所述安裝包差量，并建立當前數(shù)據(jù)包的版本號與安裝包差量的存儲地址之間的對應關系，其中，所述更新數(shù)據(jù)包為更新版本對應的安裝包數(shù)據(jù)，所述當前數(shù)據(jù)包為當前版本對應的安裝包數(shù)據(jù)；

若否，則維持當前狀態(tài)。

一種信息處理系統(tǒng)，所述系統(tǒng)包括：

請求生成模塊，用于生成應用程序更新請求，并將所述更新請求發(fā)送至服務器；

接收模塊，用于接收所述服務器返回的安裝包差量的存儲地址，其中，所述安裝包差量為兩個版本的安裝包之間的差異數(shù)據(jù)；

處理模塊，用于根據(jù)所述存儲地址，獲取安裝包差量；根據(jù)所述安裝包差量，更新所述應用程序。

一種服務器，所述服務器包括：

接收器，用于接收客戶端發(fā)送的應用程序的更新請求；

處理器，用于在所述更新請求中獲取所述應用程序的版本號，并根據(jù)所述版本號判定所述應用程序是否升級；若是，則根據(jù)所述版本號，確定出對應的安裝包差量，并將所述安裝包差量數(shù)據(jù)發(fā)送至所述客戶端，其中，所述安裝包差量表征兩個版本的安裝包之間的差異數(shù)據(jù)；若否，則忽略所述更新請求。

可選的，所述處理器，還用于檢測所述應用程序是否存在更新數(shù)據(jù)包；若是，則根據(jù)更新數(shù)據(jù)包以及當前數(shù)據(jù)包，獲取所述安裝包差量，并建立當前數(shù)據(jù)包的版本號與安裝包差量之間的對應關系；若否，則維持當前狀態(tài)。

在本發(fā)明技術方案中，客戶端在需要更新時，只需要下載對應的安裝包差量，而不再需要重新下載完整的安裝包，這樣就為客戶端減少了流量損耗，并且也為服務器減少了數(shù)據(jù)流量，使得軟件更新更加的快捷方便，提升了用戶的使用體驗。

附圖說明

圖1為本發(fā)明實施例中一種信息處理方法的流程圖；

圖2為本發(fā)明實施例中另一種信息處理方法的流程圖；

圖3為本發(fā)明實施例中一種信息處理系統(tǒng)的結構示意圖；

圖4為本發(fā)明實施例中一種服務器的結構示意圖。

具體實施方式

下面通過附圖以及具體實施例對本發(fā)明技術方案做詳細的說明，應當理解，本發(fā)明實施例及實施例中的具體技術特征只是對本發(fā)明技術方案的說明，而不是限定，在不沖突的情況下，本發(fā)明實施例以及實施例中的具體技術特征可以相互組合。

實施例一：

如圖1所示為本發(fā)明實施例中一種信息處理方法的流程圖，該方法包括：

S101，客戶端生成應用程序更新請求，并將更新請求發(fā)送至服務器；

首先，在本發(fā)明實施例中，為了使得客戶端在進行軟件更新時，不需要每次都重新完整下載安裝包，所以在服務器中需要生成每個版本對應的安裝包差量，此處安裝包差量包含了應用程序不同版本之間的差異。

比如說，版本1.0為一個版本，在版本1.0的基礎更新到1.1，由于版本更新時，主要的數(shù)據(jù)都不會存在差異，只是部分數(shù)據(jù)會存在差異，所以更新之后，應用軟件的安裝包中就只是存在一定的差量，所以本發(fā)明實施例中，服務器將生成應用程序各個版本之間的安裝包差量，比如說，版本1.0的整個安裝包的15M，重新下載版本1.1為15.5M，而安裝包差量為3M。

在服務器生成各個安裝包差量之后，服務器將各個安裝包差量與版本號之間形成一個對應關系，這樣服務器就可以根據(jù)客戶端的版本號來確定對應的安裝包差量。

基于上述的內容，在應用程序需要更新時，客戶端將生成更新請求。在客戶端生成應用更新請求時，客戶端會在該更新請求中添加應用程序的版本號，從而使得服務器能夠根據(jù)該版本號確定出對應的安裝包差量。

S102，接收服務器返回的安裝包差量的存儲地址；

在客戶端將包含了應用程序的版本號的更新請求發(fā)送至服務器之后，服務器將從該更新請求中獲取到版本號，并根據(jù)版本號確定出對應的安裝包差量的存儲地址，該存儲地址表征了安裝包差量所存儲的位置。然后服務器將該安裝包差量的存儲地址發(fā)送至對應的客戶端。

S103，根據(jù)存儲地址，獲取對應的安裝包差量；

在客戶端獲取到服務器返回的安裝包差量的存儲地址之后，客戶端將根據(jù)該存儲地址到指定位置獲取到對應的安裝包差量，這里需要說明的是，該安裝包差量可以存儲在服務器中，還可以存儲在云端服務器中。

S104，根據(jù)安裝包差量，更新應用程序。

由于客戶端獲取到該安裝包差量只是兩個版本之間需要更新的內容，所以客戶端還需要對本地已有的安裝包進行復制，在本進行本地安裝包復制時會存在兩種情況。

情況一：

若是能夠對本地已有安裝包進行復制時，將直接對本地已有安裝包進行復制，并且將本地安裝包與安裝包差量進行合并，從而得到更新安裝包。

這里的合并過程可以是將安裝包差量中的數(shù)據(jù)內容增加到本地安裝包中，或者是將安裝包差量中的數(shù)據(jù)內容替換本地安裝包中的原有內容。

在將本地安裝包與安裝包差量進行合并之后，將通過指定校驗方式，對生成的安裝包差量進行校驗，這里的指定校驗可以是sha1sum校驗。

在校驗通過時，將根據(jù)新生成的安裝包，更新應用程序。

通過上述的方式，客戶端在需要更新時，只需要下載對應的安裝包差量，而不再需要重新下載完整的安裝包，這樣就為客戶端減少了流量損耗，并且也為服務器減少了數(shù)據(jù)流量，使得軟件更新更加的快捷方便，提升了用戶的使用體驗。

情況二：

若是不能夠對本地已有安裝包進行復制時，客戶端將生成用于提示客戶端重新下載完整安裝包的提示信息。

也就是說，在本地已有的安裝包不能拷貝的條件下，無法完成安裝包與安裝包差量的合并，從而不能進行差量更新。從而客戶端通過生成提示信息的方式來引導客戶端的進行安裝包的重新下載。

綜上來講，在本發(fā)明實施例中，客戶端在需要更新時，只需要下載對應的安裝包差量，而不再需要重新下載完整的安裝包，這樣就為客戶端減少了流量損耗，并且也為服務器減少了數(shù)據(jù)流量，使得軟件更新更加的快捷方便，提升了用戶的使用體驗。

實施例二：

本發(fā)明實施例提供了一種信息處理方法，如圖2所示為本發(fā)明實施例中一種信息處理方法的流程圖，該方法包括：

S201，接收客戶端發(fā)送的應用程序的更新請求；

S202，在更新請求中獲取應用程序的版本號，并根據(jù)版本號判定應用程序是否升級；

若是，則執(zhí)行S203，若否，則執(zhí)行S204。

S203，根據(jù)版本號，確定出對應的安裝包差量，并將安裝包差量發(fā)送至客戶端；

S204，忽略更新請求。

在本發(fā)明實施例中，為了使得客戶端在進行軟件更新時，不需要每次都重新完整下載安裝包，所以在服務器中需要生成每個版本對應的安裝包差量，此處安裝包差量包含了應用程序不同版本之間的差異。也就是，在服務器檢測到應用程序存在版本更新時，服務器將根據(jù)更新數(shù)據(jù)包以及當前數(shù)據(jù)包，獲取安裝包差量，并建立裝包差量的存儲地址與版本號之間的對應關系，這里版本號為應用程序當前使用的版本的版本號。

比如說，版本1.0為應用程序一個版本，在版本1.0的基礎更新到1.1，由于版本更新時，主要的數(shù)據(jù)都不會存在差異，只是部分數(shù)據(jù)會存在差異，所以更新之后，應用軟件的安裝包中就只是存在一定的差量，所以本發(fā)明實施例中，服務器將生成應用程序各個版本之間的安裝包差量，比如說，版本1.0的整個安裝包的15M，重新下載版本1.1為15.5M，而安裝包差量為3M。

在服務器得到各個安裝包差量之后，服務器將各個安裝包差量與版本號之間形成一個對應關系，比如，上述的安裝差量包為A，并且存儲A的地址為aaa，那么對應關系為1.0—aaa。這樣服務器就可以根據(jù)客戶端的版本號來確定對應的安裝包差量。

所以，在服務器獲取到客戶端的更新請求時，服務器從更新請求中獲取到應用程序的版本號，通過版本號判定應用程序是否需要更新，若應用程序需要更新，則根據(jù)版本號確定出對應的安裝包差量的存儲地址，并將該安裝包差量的存儲地址發(fā)送至客戶端；若是應用程序不需要更新，則維持應用程序當前的狀態(tài)。

通過上述的方法，應用程序在更新時，并不需要下載完整的安裝包，而是主要直接獲取基于安裝包差量進行更新，從而節(jié)省了客戶端的流量以及更新時間，并且也減輕的服務器端的數(shù)據(jù)處理壓力。

實施例三：

對應本發(fā)明實施例一中的一種信息處理方法，本發(fā)明實施例中還提供了一種信息處理系統(tǒng)，如圖3所示為本發(fā)明實施例中一種信息處理系統(tǒng)的結構示意圖，該系統(tǒng)包括：

請求生成模塊301，用于生成應用程序更新請求，并將所述更新請求發(fā)送至服務器；

接收模塊302，用于接收所述服務器返回的安裝包差量的存儲地址，其中，所述安裝包差量為兩個版本的安裝包之間的差異數(shù)據(jù)；

處理模塊303，用于根據(jù)所述存儲地址，獲取安裝包差量；根據(jù)所述安裝包差量，更新所述應用程序。

進一步，在本發(fā)明實施例中，所述請求生成模塊301，具體用于客戶端獲取所述應用程序的版本號，將所述版本號添加至更新請求中，生成包含所述版本號的所述更新請求，其中，所述版本號用于服務器確定對應的安裝包差量地址。

進一步，在本發(fā)明實施例中，所述處理模塊303，還用于接收服務器返回的基于更新請求中的版本號對應的存儲地址，根據(jù)存儲地址，獲取存儲地址對應的存儲空間中的安裝包差量。

實施例四：

對應本發(fā)明實施例二中的一種信息處理方法，本發(fā)明實施例中還提供了一種服務器，如圖4所示為本發(fā)明實施例中一種信息處理系統(tǒng)的結構示意圖，該系統(tǒng)包括：

接收器401，用于接收客戶端發(fā)送的應用程序的更新請求；

處理器402，用于在所述更新請求中獲取所述應用程序的版本號，并根據(jù)所述版本號判定所述應用程序是否升級；若是，則根據(jù)所述版本號，確定出對應的安裝包差量，并將所述安裝包差量數(shù)據(jù)發(fā)送至所述客戶端，其中，所述安裝包差量表征兩個版本的安裝包之間的差異數(shù)據(jù)；若否，則忽略所述更新請求。

進一步，在本發(fā)明實施例中，所述處理器402，還用于檢測所述應用程序是否存在更新數(shù)據(jù)包；若是，則根據(jù)更新數(shù)據(jù)包以及當前數(shù)據(jù)包，獲取所述安裝包差量，并建立當前數(shù)據(jù)包的版本號與安裝包差量之間的對應關系；若否，則維持當前狀態(tài)。

盡管已描述了本申請的優(yōu)選實施例，但本領域內的普通技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的改進和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本申請范圍的所有改進和修改。

顯然，本領域的技術人員可以對本申請進行各種改動和變型而不脫離本申請的精神和范圍。這樣，倘若本申請的這些修改和變型屬于本申請權利要求及其等同技術的范圍之內，則本申請也意圖包含這些改動和變型在內。