本發(fā)明涉及用戶界面領(lǐng)域，具體而言，涉及一種資源加載方法和裝置。

背景技術(shù)：

UI資源是一種特殊的美術(shù)資源，其負(fù)責(zé)游戲與玩家的交互，是最直接影響游戲運(yùn)行性能體驗和內(nèi)存占用的資源。其管理和優(yōu)化在各個手游項目中享有“公認(rèn)的大坑”的美譽(yù)。其相對于其他美術(shù)資源主要有以下特點(diǎn)：對運(yùn)行時加載性能要求較高、資源數(shù)量多而尺寸小。

目前為了優(yōu)化UI資源的加載速度，普遍采用的方式是將同一個功能模塊所用到的所有資源壓縮在一張plist圖片中，這樣在加載UI資源時只需將這張plist圖片讀取到內(nèi)存中，該功能模塊需要用到的UI資源都可以直接從內(nèi)存中讀取，這樣就極大的提高了UI界面的加載速度，從而消除玩家在該功能模塊下切換界面時的卡頓感。

但是由于移動端內(nèi)存資源非常有限，這種方法對UI資源管理提出了很高要求。例如，如果一個功能模塊的UI資源管理不善，運(yùn)行該功能模塊時可能需要從多個plist圖片中獲取UI資源，那么這將造成巨大的內(nèi)存浪費(fèi)。以2048×2048的png圖片為例，其加載進(jìn)內(nèi)存占用的空間是16M，而cocos2d-x加載png圖時會通過一個臨時變量解析出紋理，因此其加載時的內(nèi)存峰值將達(dá)到32M，對于一個UI資源管理不善的功能模塊，它將同時加載多張plist文件，使內(nèi)存瞬間消耗100M以上，造成了內(nèi)存的巨大浪費(fèi)。

針對相關(guān)技術(shù)中某一個模塊UI資源加載需要同時加載多個模塊的模塊資源造成內(nèi)存浪費(fèi)的技術(shù)問題，目前尚未提出有效的解決方案。

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

本發(fā)明的主要目的在于提供一種資源加載方法和裝置，以解決相關(guān)技術(shù)中某一個模塊UI資源加載需要同時加載多個模塊的模塊資源造成內(nèi)存浪費(fèi)的技術(shù)問題。

為了實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種資源加載方法，包括：獲取預(yù)定模塊對應(yīng)的模塊資源，其中，所述模塊資源僅被所述預(yù)定模塊加載，每個模塊對應(yīng)的模塊資源僅被該模塊加載；加載所述預(yù)定模塊對應(yīng)的用戶界面UI資源，其中，所述UI資源至少包括所述模塊資源。

進(jìn)一步地，所述UI資源還包括以下至少之一：公共資源、特殊資源，其中，所述公共資源為能夠被多個模塊共同使用的資源，所述特殊資源為資源的屬性超過第一閾值的資源。

進(jìn)一步地，在獲取預(yù)定模塊對應(yīng)的模塊資源之前，所述方法還包括：將所述UI資源劃分為所述模塊資源、所述公共資源和所述特殊資源。

進(jìn)一步地，將所述UI資源劃分為所述公共資源包括：按照預(yù)定的周期判斷使用相同預(yù)定資源的模塊數(shù)量是否超過第二閾值，在超過所述第二閾值的情況下，將所述預(yù)定資源劃分為所述模塊對應(yīng)的所述公共資源；和/或，將所述UI資源劃分為所述特殊資源包括：判斷資源的屬性是否超過所述第一閾值，在超過所述第一閾值的情況下，將該資源劃分為所述模塊對應(yīng)的特殊資源；和/或，將所述UI資源劃分為所述模塊資源包括：將既不屬于所述公共資源又不屬于所述特殊資源的UI資源劃分為所述模塊資源。

進(jìn)一步地，在加載所述UI資源之前，所述方法還包括：將工程目錄中的用于UI的資源按照預(yù)定規(guī)范導(dǎo)出到引擎目錄中，得到所述引擎目錄中的所述UI資源，其中，所述引擎目錄以及所述引擎目錄中的UI資源禁止被開發(fā)者修改。

進(jìn)一步地，將所述預(yù)定資源劃分為所述模塊對應(yīng)的所述公共資源包括：在按照預(yù)定的周期判斷出使用相同預(yù)定資源的模塊數(shù)量超過所述第二閾值的情況下，判斷該資源是否是通過配置工具配置的，如果判斷出該資源不是通過所述配置工具配置的，將該資源劃分為所述模塊對應(yīng)的所述公共資源。

進(jìn)一步地，在將所述UI資源劃分為所述公共資源之后，所述方法還包括：更新所述UI資源的加載路徑。

進(jìn)一步地，更新所述UI資源的加載路徑包括：判斷所述UI資源是否為程序中動態(tài)加載的UI資源；如果判斷出所述UI資源為程序中動態(tài)加載的UI資源，查找引用所述UI資源的文件，并對查找到的文件進(jìn)行修改。

進(jìn)一步地，更新所述UI資源的加載路徑包括：判斷所述UI資源是否為程序中動態(tài)加載的UI資源；如果判斷出所述UI資源不是程序中動態(tài)加載的UI資源，判斷所述UI資源是否是通過配置工具配置的；如果判斷出所述UI資源不是通過所述配置工具配置的，對引用所述UI資源的所有工程的第一文件進(jìn)行修改，其中，通過所述第一文件能夠靜態(tài)加載所述UI資源。

進(jìn)一步地，所述預(yù)定模塊包括第一模塊和第二模塊，所述第二模塊與所述第一模塊的資源有重合，所述方法還包括：計算重合部分與所述第一模塊的資源的比值，并將結(jié)果作為第一預(yù)設(shè)比例；判斷所述第一預(yù)設(shè)比例是否大于或等于第三閾值；如果判斷出所述第一預(yù)設(shè)比例大于或等于所述第三閾值，將所述第二模塊作為所述第一模塊的子界面進(jìn)行開發(fā)，或新建工程對所述第二模塊進(jìn)行開發(fā)。

為了實現(xiàn)上述目的，根據(jù)本發(fā)明的另一方面，還提供了一種資源加載裝置，該裝置包括：獲取單元，用于獲取預(yù)定模塊對應(yīng)的模塊資源，其中，所述模塊資源僅被所述預(yù)定模塊加載，每個模塊對應(yīng)的模塊資源僅被該模塊加載；加載單元，用于加載所述預(yù)定模塊對應(yīng)的用戶界面UI資源，其中，所述UI資源至少包括所述模塊資源。

進(jìn)一步地，所述UI資源還包括以下至少之一：公共資源、特殊資源，其中，所述公共資源為能夠被多個模塊共同使用的資源，所述特殊資源為資源的屬性超過第一閾值的資源。

進(jìn)一步地，所述裝置還包括：劃分單元，用于在所述獲取單元獲取預(yù)定模塊對應(yīng)的模塊資源之前，將所述UI資源劃分為所述模塊資源、所述公共資源和所述特殊資源。

進(jìn)一步地，所述劃分單元包括：第一劃分子單元，用于按照預(yù)定的周期判斷使用相同預(yù)定資源的模塊數(shù)量是否超過第二閾值，在超過所述第二閾值的情況下，將所述預(yù)定資源劃分為所述模塊對應(yīng)的所述公共資源；和/或，第二劃分子單元，用于判斷資源的屬性是否超過所述第一閾值，在超過所述第一閾值的情況下，將該資源劃分為所述模塊對應(yīng)的特殊資源；和/或，第三劃分子單元，用于將既不屬于所述公共資源又不屬于所述特殊資源的UI資源劃分為所述模塊資源。

進(jìn)一步地，所述裝置還包括：導(dǎo)出單元，用于在加載所述UI資源之前，將工程目錄中的用于UI的資源按照預(yù)定規(guī)范導(dǎo)出到引擎目錄中，得到所述引擎目錄中的所述UI資源，其中，所述引擎目錄以及所述引擎目錄中的UI資源禁止被開發(fā)者修改。

進(jìn)一步地，所述第一劃分子單元包括：第一判斷模塊，用于在按照預(yù)定的周期判斷出使用相同預(yù)定資源的模塊數(shù)量超過所述第二閾值的情況下，判斷該資源是否是通過配置工具配置的，劃分模塊，用于當(dāng)所述第一判斷模塊判斷出該資源不是通過所述配置工具配置時，將該資源劃分為所述模塊對應(yīng)的所述公共資源。

進(jìn)一步地，所述裝置還包括：更新單元，用于在將所述UI資源劃分為所述公共資源之后，更新所述UI資源的加載路徑。

進(jìn)一步地，所述更新單元包括：第二判斷模塊，用于判斷所述UI資源是否為程序中動態(tài)加載的UI資源；查找模塊，用于當(dāng)所述第二判斷模塊判斷出所述UI資源為程序中動態(tài)加載的UI資源時，查找引用所述UI資源的文件，并對查找到的文件進(jìn)行修改。

進(jìn)一步地，所述更新單元包括：第三判斷模塊，用于判斷所述UI資源是否為程序中動態(tài)加載的UI資源；第四判斷模塊，用于當(dāng)所述第三判斷模塊判斷出所述UI資源不是程序中動態(tài)加載的UI資源時，判斷所述UI資源是否是通過配置工具配置的；修改模塊，用于當(dāng)所述第四判斷模塊判斷出所述UI資源不是通過所述配置工具配置時，對引用所述UI資源的所有工程的第一文件進(jìn)行修改，其中，通過所述第一文件能夠靜態(tài)加載所述UI資源。

進(jìn)一步地，所述預(yù)定模塊包括第一模塊和第二模塊，所述第二模塊與所述第一模塊的資源有重合，所述裝置還包括：計算單元，用于計算重合部分與所述第一模塊的資源的比值，并將結(jié)果作為第一預(yù)設(shè)比例；判斷單元，用于判斷所述第一預(yù)設(shè)比例是否大于或等于第三閾值；第一開發(fā)單元，用于當(dāng)所述判斷單元判斷出所述第一預(yù)設(shè)比例大于或等于所述第三閾值時，將所述第二模塊作為所述第一模塊的子界面進(jìn)行開發(fā)，或第二開發(fā)單元，用于新建工程對所述第二模塊進(jìn)行開發(fā)。

在本發(fā)明實施例中，每個模塊都有對應(yīng)的模塊資源，每個模塊在加載時，只能加載自身對應(yīng)的模塊資源，而不能加載其他模塊對應(yīng)的模塊資源，由于某一個模塊UI資源加載時只需要加載該模塊對應(yīng)的模塊資源，這就達(dá)到了節(jié)約內(nèi)存的技術(shù)效果，解決了相關(guān)技術(shù)中某一個模塊UI資源加載需要同時加載多個模塊的模塊資源造成內(nèi)存浪費(fèi)的技術(shù)問題。

附圖說明

構(gòu)成本申請的一部分的附圖用來提供對本發(fā)明的進(jìn)一步理解，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1是根據(jù)本發(fā)明實施例的資源加載方法的流程圖；

圖2是根據(jù)本發(fā)明實施例的開發(fā)時UI資源與運(yùn)行時UI資源分離的示意圖；

圖3是根據(jù)本發(fā)明實施例的某一個模塊UI資源加載的資源分類的示意圖；

圖4是根據(jù)本發(fā)明實施例的大圖對plist布局的影響的示意圖；

圖5-1是根據(jù)本發(fā)明實施例的UI工程目錄結(jié)構(gòu)的示意圖；

圖5-2是根據(jù)本發(fā)明實施例的UI工程目錄結(jié)構(gòu)的示意圖；

圖6是根據(jù)本發(fā)明實施例的UI資源開發(fā)的流程圖；

圖7是根據(jù)本發(fā)明實施例的導(dǎo)出工具目錄結(jié)構(gòu)的示意圖；

圖8-1是根據(jù)本發(fā)明實施例的Json文件預(yù)加載字段自動化修改前的示意圖；

圖8-2是根據(jù)本發(fā)明實施例的Json文件預(yù)加載字段自動化修改后的示意圖；

圖9-1是根據(jù)本發(fā)明實施例的Json文件圖片加載路徑、模式自動化修改前的示意圖；

圖9-2是根據(jù)本發(fā)明實施例的Json文件圖片加載路徑、模式自動化修改后的示意圖；

圖10-1是根據(jù)本發(fā)明實施例的白名單的示意圖；

圖10-2是根據(jù)本發(fā)明實施例的黑名單的示意圖；

圖11是根據(jù)本發(fā)明實施例的Common圖片和bg圖片提取的流程圖；

圖12-1是使用現(xiàn)有技術(shù)方法時，某個場景的UI加載情況的示意圖；

圖12-2是根據(jù)本發(fā)明實施例的某個場景的UI加載情況的示意圖；

圖13是根據(jù)本發(fā)明實施例的資源加載裝置的示意圖。

具體實施方式

需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。下面將參考附圖并結(jié)合實施例來詳細(xì)說明本發(fā)明。

為了使本技術(shù)領(lǐng)域的人員更好地理解本申請方案，下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分的實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├绢I(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應(yīng)當(dāng)屬于本申請保護(hù)的范圍。

需要說明的是，本申請的說明書和權(quán)利要求書及上述附圖中的術(shù)語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。應(yīng)該理解這樣使用的數(shù)據(jù)在適當(dāng)情況下可以互換，以便這里描述的本申請的實施例。此外，術(shù)語“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統(tǒng)、產(chǎn)品或設(shè)備不必限于清楚地列出的那些步驟或單元，而是可包括沒有清楚地列出的或?qū)τ谶@些過程、方法、產(chǎn)品或設(shè)備固有的其它步驟或單元。

名詞解釋：

plist文件：plist文件通常用于儲存用戶設(shè)置，也可以用于存儲捆綁的信息，該功能在舊式的Mac OS中是由資源分支提供的。由于plist中存儲的數(shù)據(jù)是抽象的，其采用的文件格式可以不止一種。

UI：用戶界面，英文全稱為User’s Interface。

本發(fā)明實施例提供了一種資源加載方法。

圖1是根據(jù)本發(fā)明實施例的資源加載方法的流程圖，如圖1所示，該資源加載方法包括以下步驟：

步驟S102，獲取預(yù)定模塊對應(yīng)的模塊資源，其中，模塊資源僅被預(yù)定模塊加載，每個模塊對應(yīng)的模塊資源僅被該模塊加載。

步驟S104，加載預(yù)定模塊對應(yīng)的用戶界面UI資源，其中，UI資源至少包括模塊資源。

每個模塊都有對應(yīng)的模塊資源，每個模塊在加載時，只能加載自身對應(yīng)的模塊資源，而不能加載其他模塊對應(yīng)的模塊資源，解決了相關(guān)技術(shù)中某一個模塊UI資源加載需要同時加載多個模塊的模塊資源造成內(nèi)存浪費(fèi)的技術(shù)問題，達(dá)到了節(jié)約內(nèi)存的技術(shù)效果。

每個程序在開發(fā)UI時習(xí)慣差異可能很大，而引擎目錄下的UI資源是經(jīng)過優(yōu)化過的遵守某種管理規(guī)范的資源，如果引擎目錄下的UI資源是按照不同習(xí)慣開發(fā)出來的，則將造成UI資源管理的混亂。在本發(fā)明實施例中，開發(fā)時UI資源與運(yùn)行時UI資源分離，具體地說，程序在開發(fā)某個UI界面時，UI工程目錄的資源與最終引擎目錄下的UI資源不同，從UI工程目錄到引擎目錄的UI資源需要按照統(tǒng)一的規(guī)則進(jìn)行遷移，不遵守規(guī)則的UI資源無法進(jìn)入到引擎目錄下。在加載UI資源之前，將工程目錄中的用于UI的資源按照預(yù)定規(guī)范導(dǎo)出到引擎目錄中，得到引擎目錄中的UI資源，其中，引擎目錄以及引擎目錄中的UI資源禁止被開發(fā)者修改。從開發(fā)目錄向引擎目錄遷移UI資源，可以借助導(dǎo)出工具完成，這樣就可以保證引擎目錄下的UI資源是統(tǒng)一且符合規(guī)范的，如圖2所示，導(dǎo)出工具的具體作用將在后面詳細(xì)介紹。

在本發(fā)明實施例中，每個模塊UI資源獨(dú)立。模塊之間UI資源的獨(dú)立是指，一個模塊的不得從其他模塊的plist中獲取資源。主要有兩方面規(guī)定，首先是開發(fā)界面的靜態(tài)Json文件時，不可以加載別的模塊的plist中的資源。其次是代碼里不可以加載別的模塊的plist中的內(nèi)容。

因此，一個界面的UI應(yīng)當(dāng)只包括以下三種資源中的任意一種或多種：模塊資源、公共資源和特殊資源。公共資源為能夠被多個模塊共同使用的資源，特殊資源為資源的屬性超過第一閾值的資源。下面提到的Common資源即為公共資源，模塊本身的plist資源即為模塊資源，零散圖片即為特殊資源。如圖3所示，模塊A加載的UI資源包括Common資源、A模塊的plist、零散圖片。

模塊之間UI資源的獨(dú)立，不僅可以避免前面提到的混亂引用plist造成的內(nèi)存暴漲的問題，也為后續(xù)UI的進(jìn)一步優(yōu)化墊定了基礎(chǔ)。

零散圖片是一些不壓入plist圖中的圖片，其中最主要的一類是bg文件夾中的大圖，我們規(guī)定圖片邊長超過一定閾值，則該圖片被稱為大圖，大圖主要是一些背景圖，這些背景圖如果被壓入plist中會嚴(yán)重影響plist圖的布局，造成資源的浪費(fèi)，如圖4所示，圖片1即為bg大圖，圖片1的邊長遠(yuǎn)大于其他圖片的邊長，因此將圖片1壓入plist中之后嚴(yán)重影響了plist圖的布局。在本發(fā)明實施例中，這些bg大圖被單獨(dú)放在bg文件夾中，以零散圖片的形式加載。后面介紹的Common圖片和bg圖片自動提取工具會自動檢測工程目錄中的大圖，并把它放入bg文件夾中。

實際開發(fā)中可根據(jù)實際情況，在遵守模塊之間UI獨(dú)立的原則的基礎(chǔ)上進(jìn)行靈活調(diào)整。當(dāng)預(yù)定模塊有多個時，假設(shè)第一模塊是已有的預(yù)定模塊，第二模塊是新的預(yù)定模塊。當(dāng)?shù)诙K與第一模塊的資源有重合時，計算重合部分與第一模塊的資源的比值，并將結(jié)果作為第一預(yù)設(shè)比例；判斷第一預(yù)設(shè)比例是否大于或等于第三閾值；如果判斷出第一預(yù)設(shè)比例大于或等于第三閾值，將第二模塊作為第一模塊的子界面進(jìn)行開發(fā)，或新建工程對第二模塊進(jìn)行開發(fā)。

例如，假定A模塊為已有的預(yù)定模塊(第一模塊)，模塊C為新的預(yù)定模塊(第二模塊)，假定第三閾值為60％。模塊C用到了A模塊70％的資源(即第一預(yù)設(shè)比例為70％)，剩下的30％是新資源或是其他模塊的資源。由于第一預(yù)設(shè)比例70％大于第三閾值60％，這時可以將A模塊和C模塊合并，并將那30％的資源合并到A模塊中，C模塊作為A模塊的一個子界面進(jìn)行開發(fā)，也可以重新新建一個C模塊自己的工程進(jìn)行開發(fā)。

基于模塊之間UI資源獨(dú)立的原則，以Cocos Studio中的UI編輯工具為例，結(jié)合UI編輯工具的特點(diǎn)，本發(fā)明實施例提供了如圖5-1和圖5-2所示的UI工程目錄結(jié)構(gòu)。

每個文件夾是一個Cocos UI工程，通常對應(yīng)一個功能模塊，例如對應(yīng)于游戲系統(tǒng)中的戰(zhàn)斗模塊、交易模塊、人物模塊、裝備模塊等等。每個文件夾內(nèi)包含Export、Json、Resources目錄，是Cocos UI工程的標(biāo)準(zhǔn)目錄形式。Resources目錄負(fù)責(zé)存儲Cocos UI工程所需的所有資源，這些資源是一些零散的原始UI資源，開發(fā)時可根據(jù)需要任意拖進(jìn)拖出。Json目錄存儲工程的子界面。Export目錄是開發(fā)完成后某個界面后，利用CocosUI編輯器導(dǎo)出并存儲的界面的Json文件。

在這樣的工程目錄結(jié)構(gòu)下，開發(fā)者可按照如圖6所示的步驟進(jìn)行某個界面的開發(fā)。

UI開發(fā)者只需要把所需要的所有UI資源，從美術(shù)提供的原始資源池里拖進(jìn)自己負(fù)責(zé)的UI工程目錄的Resources下面，既可進(jìn)行UI界面開發(fā)。開發(fā)完畢后，必須按Ctrl+E導(dǎo)出開發(fā)完畢的界面到Export文件夾中。最后運(yùn)行Export_uiProject.bat既可完成從UI工程目錄到引擎目錄的一鍵導(dǎo)出。隨著項目的推進(jìn)，UI資源的迭代，必然產(chǎn)生新的Common資源，UI資源管理員可在一定時間，運(yùn)行Common資源提取工具，自動按照UI資源的支持度，提取出Common資源。

導(dǎo)出工具和Common資源提取工具將在下面做詳細(xì)介紹。

本發(fā)明實施例提供了3個管理工具，分別是(1)程序開發(fā)時使用的導(dǎo)出工具，(2)UI資源管理員使用的Common圖片和bg圖片自動提取工具，在本發(fā)明實施例中，UI資源主要指UI圖片，Common資源主要指Common圖片，因此，Common圖片和bg圖片自動提取工具即為上述Common資源提取工具。(3)輔助的掃描UI資源是否是動態(tài)加載的工具。下面分別對這3個管理工具進(jìn)行詳細(xì)說明。

(1)導(dǎo)出工具：

導(dǎo)出工具是程序開發(fā)UI時最常用的工具，它位于每個模塊的UI工程的根目錄下面。在如圖7所示的標(biāo)準(zhǔn)的Cocos UI工程目錄結(jié)構(gòu)下面，使用者無需做任何配置，即可一鍵導(dǎo)出本工程的plist和json文件。

導(dǎo)出工具功能如下：以md5碼為關(guān)鍵值，與Common文件夾和bg文件中的圖片進(jìn)行比對，將不屬于Common文件夾和bg文件夾的圖片壓縮成plist圖片；自動化修改Export文件夾中的Json文件。將界面的Json文件中的圖片加載路徑和加載方式進(jìn)行自動化修改；將壓縮后的plist圖片和修改過的Json文件自動拷貝到引擎目錄。

具體來說，導(dǎo)出工具在把某個UI工程內(nèi)部的零散圖片壓成一張plist圖片前，工具將掃描UI工程目錄下Resources的所有圖片，并掃描Common文件夾和bg文件夾目錄下的所有圖片，提取出圖片的md5碼，將UI工程的Resources圖片與Common文件夾和bg文件夾中的圖片進(jìn)行比對，將重合的部分進(jìn)行過濾，即過濾與Common文件夾和bg文件夾的交集。

自動化修改界面Json文件，主要是將Export文件夾中通Cocos UI編輯器導(dǎo)出的Json文件，修改為通過模塊plist、Common文件夾和bg文件夾路徑讀取資源的Json文件。圖8-1是根據(jù)本發(fā)明實施例的Json文件預(yù)加載字段自動化修改前的示意圖；圖8-2是根據(jù)本發(fā)明實施例的Json文件預(yù)加載字段自動化修改后的示意圖。將圖8-2與圖8-1進(jìn)行對比，能夠看出，預(yù)加載字段發(fā)生了變化。圖9-1是根據(jù)本發(fā)明實施例的Json文件圖片加載路徑、模式自動化修改前的示意圖；圖9-2是根據(jù)本發(fā)明實施例的Json文件圖片加載路徑、模式自動化修改后的示意圖。將圖9-2與圖9-1進(jìn)行對比，能夠看出，加載路徑“path”和模式“resourceType”都發(fā)生了變化。

下面對導(dǎo)出工具使用做具體說明。

導(dǎo)出工具的使用者為需要開發(fā)UI的程序員。使用方法如下：在符合本發(fā)明實施例的UI工程目錄規(guī)范的情況下，導(dǎo)出工具可在每個Cocos UI的工程目錄下面直接運(yùn)行Export_uiProject.bat，實現(xiàn)一鍵導(dǎo)出。

如果工程目錄結(jié)構(gòu)有變，可在Export_uiProject.py中自行配置，具體路徑可參看Export_uiProject.py的代碼注釋。

需要注意的是，使用導(dǎo)出工具前，需要在Cocos UI編輯器中使用Ctrl+E導(dǎo)出所開發(fā)的Json文件，到本工程目錄下的Export文件夾中。注意，僅能選擇導(dǎo)出當(dāng)前畫布選項，因為導(dǎo)出全部畫布選項在目前版本的Cocos UI編輯器中存在bug。

(2)Common圖片和bg圖片自動提取工具

Common圖片和bg圖片自動提取工具是一個較為復(fù)雜的工具，因為在自動提取Common圖片和bg圖片時必須保證資源在移動時的魯棒性。該工具的復(fù)雜主要體現(xiàn)在兩個方面，首先是對UI資源的完全監(jiān)控，其次是該工具是一個UI工程的全局性優(yōu)化工具。

Common圖片和bg圖片自動提取工具的功能是自動從所有UI工程中提取出Common圖片和bg圖片。Common圖片和bg圖片自動提取工具的使用者為UI資源管理員。一般情況下，開發(fā)單獨(dú)某個UI模塊的程序員最好不要使用，因為該工具是針對UI工程全局優(yōu)化的工具。

為了保證Common圖片和bg圖片自動提取工具的魯棒性，該工具必須兼容某些UI資源管理不善的情況。這里將UI資源細(xì)分為3大類：通過Json文件靜態(tài)加載的UI圖片(約占90％以上)；通過py代碼動態(tài)加載的UI圖片(占比較小)；通過csv策劃配置的UI圖片(占比極少，本質(zhì)上不屬于UI資源)。

為了保證提取工具的魯棒性，必須兼容上述三種情況下的UI資源。為此針對本發(fā)明實施例所應(yīng)用于的游戲系統(tǒng)的UI管理，引入了一個輔助的資源掃描工具(即上述(3)輔助的掃描UI資源是否是動態(tài)加載的工具)和黑白名單機(jī)制。資源掃描工具和黑白名單機(jī)制是為了監(jiān)控項目中用到的第二和第三類UI資源，及代碼動態(tài)加載的UI資源和策劃配置的UI資源。用白名單存儲程序中動態(tài)加載的UI資源的名稱和代碼文件路徑，用黑名單存儲策劃配置的圖片資源，圖10-1示出了白名單，圖10-2示出了黑名單。例如，黑白名單本可以是兩個Json文件，Json文件中存儲的是一個以圖片名稱為Key值的字典，Value值是引用圖片的文件路徑，例如.csv文件表示策劃的配表文件，.py表示程序的代碼文件。掃描工具通過掃描代碼文件夾和策劃配表文件夾得出黑白名單，從而將代碼中動態(tài)加載的UI資源和策劃配置的UI資源完全監(jiān)控起來，為提取工具運(yùn)行的魯棒性打下堅實基礎(chǔ)。

在獲取預(yù)定模塊對應(yīng)的模塊資源之前，先將UI資源劃分為模塊資源、公共資源和特殊資源。其中，公共資源為能夠被多個模塊共同使用的資源，特殊資源為資源的屬性超過第一閾值的資源，其余的則為模塊資源。

將UI資源劃分為公共資源的過程如下：按照預(yù)定的周期判斷使用相同預(yù)定資源的模塊數(shù)量是否超過第二閾值，在超過第二閾值的情況下，判斷該資源是否是通過配置工具配置的，如果判斷出該資源不是通過配置工具配置的，將預(yù)定資源劃分為模塊對應(yīng)的公共資源。例如，以某張圖片的md5碼作為key值，統(tǒng)計該圖片在各個UI工程中出現(xiàn)的次數(shù)作為圖片的支持度，當(dāng)圖片的支持度大于某個閾值(第二閾值)時認(rèn)為該圖片是頻繁使用的，即該圖片是公共資源，把它移入Common文件夾，同時修改相應(yīng)文件的加載路徑和加載方式。

將UI資源劃分為特殊資源的過程如下：判斷資源的屬性是否超過第一閾值，在超過第一閾值的情況下，將該資源劃分為模塊對應(yīng)的特殊資源。以bg圖片為例對上述過程進(jìn)行說明。對于bg圖片，則以圖片的邊長(資源的屬性)作為衡量指標(biāo)，如果圖片的邊長大于某個閾值(第一閾值)則認(rèn)為該圖片是大圖，則放入bg文件夾，并對相應(yīng)引用文件進(jìn)行修改。

將UI資源劃分為模塊資源的過程如下：將既不屬于公共資源又不屬于特殊資源的UI資源劃分為模塊資源。

Common圖片和bg圖片自動提取工具具有全局性。該工具之所以是全局的是因為，每個UI工程的變動都可能影響到Common文件夾的變動，例如，設(shè)置的頻繁度閾值為5，當(dāng)A.png被4個工程使用時，有新建工程也要使用A.png，這時A.png將被移入Common文件夾，這時就需要對原來4個工程中的A.png的引用文件加以修改。

在將UI資源劃分為公共資源之后，需要更新UI資源的加載路徑。對于UI資源動態(tài)加載和UI資源靜態(tài)加載的情況，更新UI資源的加載路徑的方法是不同的，因此，首先需要判斷UI資源是否為程序中動態(tài)加載的UI資源。如果判斷出UI資源為程序中動態(tài)加載的UI資源，查找引用UI資源的文件，并對查找到的文件進(jìn)行修改。如果判斷出UI資源不是程序中動態(tài)加載的UI資源，判斷UI資源是否是通過配置工具配置的；如果判斷出UI資源不是通過配置工具配置的，對引用UI資源的所有工程的第一文件進(jìn)行修改，其中，通過第一文件能夠靜態(tài)加載UI資源。

例如，當(dāng)A.png被認(rèn)為是頻繁圖片，被移入Common文件夾后，需要在每個工程中自動修改該圖片的加載路徑。這時將查詢A.png是否在黑名單或白名單中，如果A.png在黑名單中，則將A.png移出Common文件夾，如果A.png在白名單中，則在白名單中查找引用A.png的文件，并對相應(yīng)文件進(jìn)行自動化修改。如果A.png既不在黑名單，也不在白名單中，則對引用A.png的所有工程的Json文件進(jìn)行自動化修改，其修改過程類似導(dǎo)出工具。

Common圖片和bg圖片的提取流程如圖11所示。如圖11所示，該過程包括以下步驟：

步驟S1102，自動生成黑白名單。

步驟S1104，對圖片的支持度進(jìn)行計數(shù)。

步驟S1106，獲取圖片尺寸。

步驟S1108，判斷圖片尺寸是否大于或等于閾值。如果判斷結(jié)果為是，執(zhí)行步驟S1110；如果判斷結(jié)果為否，結(jié)束。

步驟S1110，判斷該圖片是否在黑名單中。如果判斷結(jié)果為是，結(jié)束；如果判斷結(jié)果為否，執(zhí)行步驟S1112。

步驟S1112，判斷該圖片是否在白名單中。如果判斷結(jié)果為是，執(zhí)行步驟S1114；如果判斷結(jié)果為否，執(zhí)行步驟S1116。

步驟S1114，修改代碼。如果該圖片在白名單中，則在白名單中查找引用該圖片的文件，并對相應(yīng)文件進(jìn)行自動化修改。

步驟S1116，修改Json。如果該圖片既不在黑名單，也不在白名單中，則對引用該圖片的所有工程的Json文件進(jìn)行自動化修改，其修改過程類似導(dǎo)出工具。

使用現(xiàn)有技術(shù)方法時，某個場景的UI加載情況如圖12-1所示，使用本發(fā)明實施例所提供的方法時該場景的UI加載情況如圖12-2所示。

加載一張2048×2048的png圖片所用內(nèi)存空間峰值是32M，那么使用現(xiàn)有技術(shù)方法加載該場景僅UI就耗費(fèi)32×5＝160M內(nèi)存，而使用本發(fā)明實施例所提供的方法，bg圖片提取時，將大圖提取出去，使得plist圖片布局合理沒有浪費(fèi)的空間，內(nèi)存僅消耗32+8+2＝42M。可見，使用本發(fā)明實施例所提供的方法，在加載UI場景時，耗費(fèi)的內(nèi)存大大減小。

UI管理和優(yōu)化是手游項目耗費(fèi)時間較長的優(yōu)化問題，也是影響手游實際性能和體驗的重要方面，有效的UI管理不僅使得UI加載時內(nèi)存得到有效控制，同時也是UI進(jìn)行其他優(yōu)化的基礎(chǔ)。在本發(fā)明實施例中，通過UI資源分為模塊資源、公共資源和特殊資源三種，其中，公共資源為能夠被多個模塊共同使用的資源，特殊資源為資源的屬性超過第一閾值的資源，模塊資源僅被對應(yīng)的模塊加載，使得每個模塊UI資源獨(dú)立，避免了現(xiàn)有技術(shù)中混亂引用plist造成的內(nèi)存暴漲的問題，為UI進(jìn)行進(jìn)一步優(yōu)化奠定了基礎(chǔ)。

根據(jù)本發(fā)明實施例，還提供了一種資源加載裝置。該資源加載裝置能夠?qū)嵤┥鲜鲑Y源加載方法。圖13是根據(jù)本發(fā)明實施例的資源加載裝置的示意圖。如圖13所示，該裝置包括獲取單元10和加載單元20。

獲取單元10，用于獲取預(yù)定模塊對應(yīng)的模塊資源，其中，模塊資源僅被預(yù)定模塊加載，每個模塊對應(yīng)的模塊資源僅被該模塊加載。

加載單元20，用于加載預(yù)定模塊對應(yīng)的用戶界面UI資源，其中，UI資源至少包括模塊資源。

可選地，UI資源還包括以下至少之一：公共資源、特殊資源，其中，公共資源為能夠被多個模塊共同使用的資源，特殊資源為資源的屬性超過第一閾值的資源。

可選地，裝置還包括劃分單元。劃分單元，用于在所述獲取單元10獲取預(yù)定模塊對應(yīng)的模塊資源之前，將UI資源劃分為模塊資源、公共資源和特殊資源。

可選地，劃分單元包括第一劃分子單元、第二劃分子單元和第三劃分子單元。第一劃分子單元，用于按照預(yù)定的周期判斷使用相同預(yù)定資源的模塊數(shù)量是否超過第二閾值，在超過第二閾值的情況下，將預(yù)定資源劃分為模塊對應(yīng)的公共資源。第二劃分子單元，用于判斷資源的屬性是否超過第一閾值，在超過第一閾值的情況下，將該資源劃分為模塊對應(yīng)的特殊資源。第三劃分子單元，用于將既不屬于公共資源又不屬于特殊資源的UI資源劃分為模塊資源。

可選地，裝置還包括導(dǎo)出單元。導(dǎo)出單元，用于在加載UI資源之前，將工程目錄中的用于UI的資源按照預(yù)定規(guī)范導(dǎo)出到引擎目錄中，得到引擎目錄中的UI資源，其中，引擎目錄以及引擎目錄中的UI資源禁止被開發(fā)者修改。

可選地，第一劃分子單元包括第一判斷模塊、劃分模塊。第一判斷模塊，用于在按照預(yù)定的周期判斷出使用相同預(yù)定資源的模塊數(shù)量超過第二閾值的情況下，判斷該資源是否是通過配置工具配置的。劃分模塊，用于當(dāng)?shù)谝慌袛嗄K判斷出該資源不是通過配置工具配置時，將該資源劃分為模塊對應(yīng)的公共資源。

可選地，裝置還包括更新單元。更新單元，用于在將UI資源劃分為公共資源之后，更新UI資源的加載路徑。

可選地，更新單元包括第二判斷模塊和查找模塊。第二判斷模塊，用于判斷UI資源是否為程序中動態(tài)加載的UI資源。查找模塊，用于當(dāng)?shù)诙袛嗄K判斷出UI資源為程序中動態(tài)加載的UI資源時，查找引用UI資源的文件，并對查找到的文件進(jìn)行修改。

可選地，更新單元包括第三判斷模塊、第四判斷模塊和修改模塊。第三判斷模塊，用于判斷UI資源是否為程序中動態(tài)加載的UI資源。第四判斷模塊，用于當(dāng)?shù)谌袛嗄K判斷出UI資源不是程序中動態(tài)加載的UI資源時，判斷UI資源是否是通過配置工具配置的。修改模塊，用于當(dāng)?shù)谒呐袛嗄K判斷出UI資源不是通過配置工具配置時，對引用UI資源的所有工程的第一文件進(jìn)行修改，其中，通過第一文件能夠靜態(tài)加載UI資源。

可選地，預(yù)定模塊包括第一模塊和第二模塊，第二模塊與第一模塊的資源有重合，裝置還包括計算單元、判斷單元、第一開發(fā)單元和第二開發(fā)單元。計算單元，用于計算重合部分與第一模塊的資源的比值，并將結(jié)果作為第一預(yù)設(shè)比例。判斷單元，用于判斷第一預(yù)設(shè)比例是否大于或等于第三閾值。第一開發(fā)單元，用于當(dāng)判斷單元判斷出第一預(yù)設(shè)比例大于或等于第三閾值時，將第二模塊作為第一模塊的子界面進(jìn)行開發(fā)。第二開發(fā)單元，用于新建工程對第二模塊進(jìn)行開發(fā)。

顯然，本領(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)。