本發(fā)明涉及計算機(jī)技術(shù)領(lǐng)域，特別是涉及一種軟件更新方法及裝置。

背景技術(shù)：

在軟件研發(fā)領(lǐng)域，版本熱更新為必不可少的功能，版本熱更新是指軟件可在線更新，無需重新下載客戶端，只需下載資料包，即可完成版本更新。對于游戲軟件，其版本更新通常包括游戲數(shù)據(jù)、美術(shù)資源及功能代碼，游戲數(shù)據(jù)是指游戲中需要使用到的各類型定義數(shù)據(jù)，如物品信息、角色屬性等，美術(shù)資源是指游戲中的地圖、人物模型及各種UI畫面，功能代碼是指游戲中各種功能的實現(xiàn)代碼。

對于游戲軟件版本熱更新功能，其設(shè)計、操作、管理難度較高，具體原因如下：版本熱更新頻率較高，為讓玩家保持新鮮感，在游戲運(yùn)營過程中，會按照一定的周期進(jìn)行內(nèi)容更新，不斷推出新的游戲內(nèi)容，另外，會根據(jù)游戲過程中的反饋進(jìn)行數(shù)據(jù)方面的優(yōu)化調(diào)整；版本熱更新主要用于生成環(huán)境，每次更新都是直接面對玩家，因此需要保證熱更新的流程準(zhǔn)確無誤，尤其要確保流程的可控性，避免熱更新流程中因人為錯誤而導(dǎo)致的問題；版本熱更新牽涉的人員較廣，熱更新涉及多個部分，如游戲數(shù)據(jù)、美術(shù)資源、功能代碼，在開發(fā)過程中，各部分分屬不同的人員進(jìn)行開發(fā)管理。

如何采用統(tǒng)一的更新提交接口提交更新數(shù)據(jù)，且簡便、可控地進(jìn)行軟件更新，是游戲軟件版本熱更新亟待解決的問題之一。

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

本發(fā)明主要解決的技術(shù)問題是提供一種軟件更新方法及裝置，能夠采用統(tǒng)一的更新提交接口提交更新數(shù)據(jù)，且簡便、可控地進(jìn)行軟件熱更新。

為解決上述技術(shù)問題，本發(fā)明提供一種軟件更新方法，包括以下步驟：獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)；將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件；將存在差異的文件進(jìn)行分割打包；將分割打包后的包文件發(fā)送至緩存端，并記錄存在差異的文件的文件信息；根據(jù)發(fā)布指令更新軟件版本號，軟件版本號與包文件對應(yīng)；當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新。

其中，更新后的軟件數(shù)據(jù)采用SVN服務(wù)器的提交接口進(jìn)行數(shù)據(jù)提交。

其中，緩存端為內(nèi)容分發(fā)網(wǎng)絡(luò)。

其中，待更新端為客戶端或服務(wù)器端。

其中，當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新的步驟包括：當(dāng)軟件版本號更新后，發(fā)送軟件版本號更新消息至服務(wù)器端；根據(jù)服務(wù)器端的請求返回軟件版本號、文件信息及包文件，以實現(xiàn)服務(wù)器端軟件的熱更新。

為解決上述技術(shù)問題，本發(fā)明提供一種軟件更新裝置，包括：獲取模塊，用于獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)；比對模塊，用于將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件；打包模塊，用于將存在差異的文件進(jìn)行分割打包；發(fā)送記錄模塊，用于將分割打包后的包文件發(fā)送至緩存端，并記錄存在差異的文件的文件信息；更新模塊，用于根據(jù)發(fā)布指令更新軟件版本號，軟件版本號與包文件對應(yīng)；發(fā)送模塊，用于當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新。

其中，更新后的軟件數(shù)據(jù)采用SVN服務(wù)器的提交接口進(jìn)行數(shù)據(jù)提交。

其中，待更新端為客戶端或服務(wù)器端。

其中，發(fā)送模塊包括：發(fā)送單元，用于當(dāng)軟件版本號更新后，發(fā)送軟件版本號更新消息至服務(wù)器端；返回單元，用于根據(jù)服務(wù)器端的請求返回軟件版本號、文件信息及包文件，以實現(xiàn)服務(wù)器端軟件的熱更新。

為解決上述技術(shù)問題，本發(fā)明提供一種軟件更新系統(tǒng)，包括上述軟件更新裝置和用于存儲更新后的軟件數(shù)據(jù)的SVN服務(wù)器。

本發(fā)明的有益效果是：區(qū)別于現(xiàn)有技術(shù)的情況，本發(fā)明的軟件更新方法具體為：首先獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)，其中，更新后的軟件數(shù)據(jù)采用SVN服務(wù)器的提交接口進(jìn)行數(shù)據(jù)提交；然后將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件，將存在差異的文件進(jìn)行分割打包，將分割打包后的包文件發(fā)送至緩存端，并記錄存在差異的文件的文件信息；最后根據(jù)發(fā)布指令更新軟件版本號，其中，軟件版本號與包文件對應(yīng)，當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新。通過上述方式，本發(fā)明軟件更新簡便、可控，滿足游戲軟件版本熱更新頻率高的要求，減少熱更新過程中的人為操作；利用SVN服務(wù)器的提交接口進(jìn)行更新后的軟件數(shù)據(jù)的提交，由于提交接口統(tǒng)一，可確保更新后的軟件數(shù)據(jù)的可靠性。

附圖說明

圖1是本發(fā)明軟件更新方法一實施例的流程示意圖；

圖2是本發(fā)明軟件更新裝置一實施例的結(jié)構(gòu)示意圖。

具體實施方式

下面結(jié)合附圖和實施例對本發(fā)明進(jìn)行詳細(xì)說明。

請參閱圖1，圖1是本發(fā)明軟件更新方法一實施例的流程示意圖，如圖1所示，包括以下步驟：

S11，獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)。

本實施例方法由游戲軟件版本熱更新平臺實現(xiàn)，為基于SVN (Subversion )管理的游戲軟件版本熱更新方法。在本實施例中，更新后的軟件數(shù)據(jù)采用SVN服務(wù)器的提交接口進(jìn)行數(shù)據(jù)提交。

對于軟件版本熱更新，其首要要求為低出錯率，因為生成環(huán)境上的錯誤，都會導(dǎo)致重大的運(yùn)營事故。利用SVN作為更新資料的管理，可避免更新資料的出錯，原因主要有：不同資料提供者均對SVN的使用非常熟悉，減少因為使用不熟悉的工具所造成的人為錯誤；利用SVN同步機(jī)制，可防止不同資料提供者對同一份資料修改導(dǎo)致的信息覆蓋錯誤；利用SVN版本控制特性，可以很方便的進(jìn)行歷史版本的回溯，對于資料更新錯誤，可以很方便地進(jìn)行查找；SVN作為成熟的版本管理，穩(wěn)定性非常高，可增加版本熱更新的穩(wěn)定性。

對于更新后的軟件數(shù)據(jù)，其提交過程具體為：資料發(fā)布者通過本地的SVN客戶端連接到SVN服務(wù)器，首先更新最新的資料庫到本地，以確保本地和SVN服務(wù)器資料的同步，然后把需要更新的資料文件拷貝到本地資料存放目錄，根據(jù)預(yù)先設(shè)定好的目錄進(jìn)行存放，該目錄可根據(jù)游戲的不同自行設(shè)定，再者利用SVN客戶端的比對功能，進(jìn)行資料檢查，確認(rèn)資料更新的正確性，最后確認(rèn)更新資料正確后，向SVN服務(wù)器進(jìn)行提交，SVN服務(wù)器對更新后的軟件數(shù)據(jù)進(jìn)行存儲。在提交過程中，若部分資料無法提交，則表明有資料文件沖突，需重新更新資料，并自行進(jìn)行資料的合并。

S12，將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件。

S13，將存在差異的文件進(jìn)行分割打包。

S14，將分割打包后的包文件發(fā)送至緩存端，并記錄存在差異的文件的文件信息。

游戲軟件的版本發(fā)布由管理者進(jìn)行管理，當(dāng)更新資料提交完畢，管理者發(fā)出版本生成指令，此時生成的版本為可發(fā)布版本，但不立即發(fā)布。版本生成的過程具體為：當(dāng)管理者發(fā)出版本生成指令后，游戲軟件版本熱更新平臺獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)；將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件，即篩選出所有有變更的文件，該篩選出來的文件為后續(xù)版本包生成材料；存在差異的文件篩選出來后，自動對其進(jìn)行分割打包，具體打包成便于下載的壓縮文件；將打包后的包文件傳輸至緩存端，以備下載；包文件傳輸至緩存端后，記錄存在差異的文件的文件信息。

在本實施例中，緩存端為內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Network，CDN)。

S15，根據(jù)發(fā)布指令更新軟件版本號，軟件版本號與包文件對應(yīng)。

管理者接收到版本生成完成的消息后，具體為通過郵件的方式接收，可根據(jù)游戲的需要進(jìn)行版本發(fā)布。管理者登錄游戲軟件版本熱更新平臺，可查看所有版本信息列表，選擇需發(fā)布的版本，發(fā)出發(fā)布指令，則平臺根據(jù)發(fā)布指令更新軟件版本號。對于發(fā)布，只能發(fā)布最新的版本，發(fā)布舊版本無效。

管理者可對版本信息列表進(jìn)行操作，具體為可以進(jìn)行版本的刪除、信息修改、發(fā)布等操作。

S16，當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新。

當(dāng)更新軟件版本號后，則表示進(jìn)入新版本的待更新狀態(tài)，在本實施例中，待更新端為客戶端或服務(wù)器端。

對于游戲客戶端，屬于主動更新模式，當(dāng)玩家通過游戲客戶端登入游戲時，獲取更新后的軟件版本號，若獲取的軟件版本號比客戶端記錄的版本更高，則請求獲取文件信息和包文件，進(jìn)行軟件的熱更新。

對于游戲服務(wù)器端，屬于被動更新模式，當(dāng)軟件版本號更新后，游戲軟件版本熱更新平臺發(fā)送軟件版本號更新消息至服務(wù)器端，服務(wù)器端接收到消息后，請求獲取軟件版本號、文件信息及包文件，進(jìn)行軟件的熱更新。

以上所述，本實施例軟件更新方法簡便、可控，滿足游戲軟件版本熱更新頻率高的要求，減少熱更新過程中的人為操作；利用SVN服務(wù)器的提交接口進(jìn)行更新后的軟件數(shù)據(jù)的提交，由于提交接口統(tǒng)一，可確保更新后的軟件數(shù)據(jù)的可靠性。

請參閱圖2，圖2是本發(fā)明軟件更新裝置一實施例的結(jié)構(gòu)示意圖，如圖2所示，包括：獲取模塊21、比對模塊22、打包模塊23、發(fā)送記錄模塊24、更新模塊25及發(fā)送模塊26。

上述各模塊的功能具體如下：

獲取模塊21用于獲取SVN服務(wù)器中更新后的軟件數(shù)據(jù)；比對模塊22用于將更新后的軟件數(shù)據(jù)與本地軟件數(shù)據(jù)進(jìn)行比對，以篩選與本地軟件數(shù)據(jù)存在差異的文件；打包模塊23用于將存在差異的文件進(jìn)行分割打包；發(fā)送記錄模塊24用于將分割打包后的包文件發(fā)送至緩存端，并記錄存在差異的文件的文件信息；更新模塊25用于根據(jù)發(fā)布指令更新軟件版本號，軟件版本號與包文件對應(yīng)；發(fā)送模塊26用于當(dāng)軟件版本號更新后，根據(jù)待更新端的請求發(fā)送文件信息和包文件，以實現(xiàn)待更新端軟件的熱更新。

在本實施例中，更新后的軟件數(shù)據(jù)采用SVN服務(wù)器的提交接口進(jìn)行數(shù)據(jù)提交。對于更新后的軟件數(shù)據(jù)，其提交過程具體為：資料發(fā)布者通過本地的SVN客戶端連接到SVN服務(wù)器，首先更新最新的資料庫到本地，以確保本地和SVN服務(wù)器資料的同步，然后把需要更新的資料文件拷貝到本地資料存放目錄，根據(jù)預(yù)先設(shè)定好的目錄進(jìn)行存放，該目錄可根據(jù)游戲的不同自行設(shè)定，再者利用SVN客戶端的比對功能，進(jìn)行資料檢查，確認(rèn)資料更新的正確性，最后確認(rèn)更新資料正確后，向SVN服務(wù)器進(jìn)行提交，SVN服務(wù)器對更新后的軟件數(shù)據(jù)進(jìn)行存儲。在提交過程中，若部分資料無法提交，則表明有資料文件沖突，需重新更新資料，并自行進(jìn)行資料的合并。

在本實施例中，游戲軟件的版本發(fā)布由管理者進(jìn)行管理，當(dāng)更新資料提交完畢，管理者發(fā)出版本生成指令，當(dāng)管理者發(fā)出版本生成指令后，獲取模塊21、比對模塊22、打包模塊23、發(fā)送記錄模塊24依次進(jìn)行工作，以完成軟件版本的生成。軟件版本生成后，管理者發(fā)出發(fā)布指令，更新模塊25根據(jù)發(fā)布指令更新軟件版本號，當(dāng)更新軟件版本號后，則表示進(jìn)入新版本的待更新狀態(tài)。在本實施例中，待更新端為客戶端或服務(wù)器端，由發(fā)送模塊26發(fā)送文件信息和包文件至待更新端，以實現(xiàn)待更新端軟件的熱更新。

對于游戲客戶端，屬于主動更新模式，當(dāng)玩家通過游戲客戶端登入游戲時，獲取更新后的軟件版本號，若獲取的軟件版本號比客戶端記錄的版本更高，則請求獲取文件信息和包文件，進(jìn)行軟件的熱更新。

對于游戲服務(wù)器端，屬于被動更新模式，其更新過程為：發(fā)送模塊26包括發(fā)送單元(圖未示)和返回單元(圖未示)；發(fā)送單元用于當(dāng)軟件版本號更新后，發(fā)送軟件版本號更新消息至服務(wù)器端；返回單元用于根據(jù)服務(wù)器端的請求返回軟件版本號、文件信息及包文件，以實現(xiàn)服務(wù)器端軟件的熱更新。

在本實施例中，緩存端為內(nèi)容分發(fā)網(wǎng)絡(luò)。

本發(fā)明的軟件更新系統(tǒng)包括圖2所示實施例的裝置和用于存儲更新后的軟件數(shù)據(jù)的SVN服務(wù)器。

下面通過一具體實施例來詳細(xì)闡述本發(fā)明的軟件更新系統(tǒng)。

軟件更新系統(tǒng)包括SVN系統(tǒng)、版本生成系統(tǒng)、版本管理系統(tǒng)、版本分發(fā)系統(tǒng)，其中，SVN系統(tǒng)對應(yīng)SVN服務(wù)器，版本生成系統(tǒng)、版本管理系統(tǒng)、版本分發(fā)系統(tǒng)對應(yīng)游戲軟件版本熱更新平臺或圖2所示實施例的裝置。

SVN系統(tǒng)用于做資料的存儲和管理，其為資料上傳提交的入口，也為版本生成系統(tǒng)的入口。

版本生成系統(tǒng)由比對子系統(tǒng)、打包子系統(tǒng)、版本記錄子系統(tǒng)組成。對比子系統(tǒng)的作用是完成2個不同版本之間的文件差異性比對，篩選出差異性文件，該差異性文件是用于更新的元素。打包子系統(tǒng)則是把篩選出的差異性文件進(jìn)行分割打包，分割打包的作用是提供更好的下載服務(wù)，因為過小的更新包會給更新帶來大量的連接損耗，而過大的更新包則容易出現(xiàn)下載失敗。版本記錄子系統(tǒng)則是為后續(xù)版本發(fā)布做準(zhǔn)備，提供更新信息給待更新端。版本生成系統(tǒng)生成的版本為預(yù)發(fā)布，使得軟件更新系統(tǒng)有足夠的時間完成發(fā)布部署。版本生成系統(tǒng)利用自動比對機(jī)制，替代一般使用人工進(jìn)行更新文件的篩選，極大地減少人工操作可能帶來的錯誤。

版本管理系統(tǒng)用于管理者對已發(fā)布和未發(fā)布的版本進(jìn)行管理，管理者還可進(jìn)行其他操作，如小包管理等。

版本分發(fā)系統(tǒng)用于面向待更新端，包括版本獲取接口和緩存端，版本獲取接口提供軟件版本號、文件信息獲取功能，緩存端為內(nèi)容分發(fā)網(wǎng)絡(luò)。版本獲取接口可統(tǒng)一對接不同異構(gòu)裝置的更新信息獲取接口，能夠?qū)尤魏伍_發(fā)語言或系統(tǒng)。

對于待更新端為游戲服務(wù)器端的情況，版本分發(fā)系統(tǒng)還包括更新通知接口，用于服務(wù)器端獲取軟件版本更新消息。

本發(fā)明軟件更新系統(tǒng)高效有序，解決了當(dāng)前游戲研發(fā)領(lǐng)域版本熱更新流程復(fù)雜、效率低下、容易出錯的問題，使得版本熱更新簡便、高效、容錯性高。

以上所述僅為本發(fā)明的實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運(yùn)用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護(hù)范圍內(nèi)。