本發(fā)明涉及軟件開發(fā)技術(shù)領(lǐng)域，尤其涉及一種用戶定制產(chǎn)品的批量打包方法。

背景技術(shù)：

所謂用戶定制產(chǎn)品，例如原始設(shè)備制造商(originalequipmentmanufacturer，oem)制造的并賣給第三方代理商的軟件產(chǎn)品等，其具有能夠根據(jù)不同的客戶修改產(chǎn)品特性的特點。

正因為用戶定制產(chǎn)品具有上述特點，導致不同的第三方代理商對于其私人訂制的需求非常多并且非常復雜，例如希望私人訂制公司的圖標、聯(lián)系電話、公司的宣傳網(wǎng)站等信息，這就導致用戶定制產(chǎn)品的oem包越來越多，每次修改都需要復制不同的代碼以組成新的oem包，非常不便于管理。并且，當版本升級后，所有的工作進程都需要重新再來一遍，降低處理效率的同時還容易出現(xiàn)錯誤。

綜上，現(xiàn)有的用戶定制產(chǎn)品的開發(fā)和處理過程中需要投入大量的人力和物力，也會耗費大量的時間，并且無法保證測試效果，這給軟件開發(fā)過程帶來了很多的未知風險。

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

根據(jù)現(xiàn)有技術(shù)中存在的上述問題，現(xiàn)提供一種用戶定制產(chǎn)品的批量打包方法的技術(shù)方案，旨在降低用戶定制產(chǎn)品打包過程中的人力物力成本，減少打包時間，提升打包效率。

上述技術(shù)方案具體包括：

一種用戶定制產(chǎn)品的批量打包方法，適用于安卓系統(tǒng)；其中，每個所述用戶定制產(chǎn)品具有多個不同的配置信息；

針對同一個批次內(nèi)的所有所述用戶定制產(chǎn)品的所述批量打包方法包括：

步驟s1，形成一用于執(zhí)行所述用戶定制產(chǎn)品的底層邏輯操作的邏輯單元；

步驟s2，形成一用于展示所述用戶定制產(chǎn)品的所述產(chǎn)品元素的展示單元；

步驟s3，形成所述邏輯單元與所述展示單元之間的對應關(guān)系；

步驟s4，整理所述用戶定制產(chǎn)品的所述配置信息，以形成包括不同的所述用戶定制產(chǎn)品的配置文件；

步驟s5，根據(jù)所述配置文件對同一個批次內(nèi)的所有所述用戶定制產(chǎn)品進行批量打包操作，以分別形成關(guān)聯(lián)于每個所述用戶定制產(chǎn)品的產(chǎn)品安裝文件；

每個所述產(chǎn)品安裝文件中包括所述展示單元中對應于所述用戶定制產(chǎn)品的所述配置文件，以及所述邏輯單元中對應于所述用戶定制產(chǎn)品的所述底層邏輯操作的代碼文件。

優(yōu)選的，該批量打包方法，其中，所述配置信息包括：

所述用戶定制產(chǎn)品的圖標信息；和/或

所述用戶定制產(chǎn)品的標題信息；和/或

所述用戶定制產(chǎn)品的簽名信息；和/或

所述用戶定制產(chǎn)品對應的代理商主頁信息。

優(yōu)選的，該批量打包方法，其中，所述邏輯單元執(zhí)行的所述底層邏輯操作包括執(zhí)行所述用戶定制產(chǎn)品的業(yè)務代碼，以及執(zhí)行所述用戶定制產(chǎn)品的數(shù)據(jù)協(xié)議交互操作。

優(yōu)選的，該批量打包方法，其中，所述步驟s3中，所述邏輯單元與所述展示單元之間的所述對應關(guān)系包括：

所述展示單元依賴于所述邏輯單元工作。

優(yōu)選的，該批量打包方法，其中，所述展示單元中，針對每個所述用戶定制產(chǎn)品形成一對應的產(chǎn)品文件夾，所述產(chǎn)品文件夾中包括對應的所述用戶定制產(chǎn)品的所有所述配置信息；

所述步驟s5中，對所述用戶定制產(chǎn)品進行打包的過程具體包括：

步驟s51，針對每個所述用戶定制產(chǎn)品分別增加一可定義子目錄；

步驟s52，針對每個所述用戶定制產(chǎn)品分別增加源集節(jié)點，每個所述源集節(jié)點分別指向所述用戶定制產(chǎn)品的源代碼目錄下對應的所述產(chǎn)品文件夾的存儲位置；

步驟s53，針對每個所述用戶定制產(chǎn)品分別修改對應的默認配置屬性；

步驟s54，對同一個批次內(nèi)的所有所述用戶定制產(chǎn)品進行批量打包操作，以分別形成關(guān)聯(lián)于每個所述用戶定制產(chǎn)品的產(chǎn)品安裝文件。

優(yōu)選的，該批量打包方法，其中，所述步驟s5中，通過修改gradle配置腳本對所述用戶定制產(chǎn)品進行批量打包。

優(yōu)選的，該批量打包方法，其中，所述步驟s5中，通過修改gradle配置腳本對所述用戶定制產(chǎn)品進行批量打包；

所述步驟s51中，所述可定義子目錄為所述gradle配置腳本中的productflavors節(jié)點。

優(yōu)選的，該批量打包方法，其中，所述步驟s5中，通過修改gradle配置腳本對所述用戶定制產(chǎn)品進行批量打包；

所述步驟s52中：

所述源集節(jié)點為所述gradle配置腳本中的sourcesets節(jié)點。

優(yōu)選的，該批量打包方法，其中，所述步驟s5中，通過修改gradle配置腳本對所述用戶定制產(chǎn)品進行批量打包；

所述步驟s53中，所述默認配置屬性為所述gradle配置腳本中的defaultconfig屬性。

上述技術(shù)方案的有益效果是：提供一種用戶定制產(chǎn)品的批量打包方法，能夠降低用戶定制產(chǎn)品打包過程中的人力物力成本，減少打包時間，提升打包效率。

附圖說明

圖1是本發(fā)明的較佳的實施例中，一種用戶定制產(chǎn)品的批量打包方法的總體流程示意圖；

圖2是本發(fā)明的較佳的實施例中，于圖1的基礎(chǔ)上，對用戶定制產(chǎn)品進行打包的具體流程示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

需要說明的是，在不沖突的情況下，本發(fā)明中的實施例及實施例中的特征可以相互組合。

下面結(jié)合附圖和具體實施例對本發(fā)明作進一步說明，但不作為本發(fā)明的限定。

本發(fā)明的較佳的實施例中，基于現(xiàn)有技術(shù)中存在的上述問題，現(xiàn)提供一種用戶定制產(chǎn)品的批量打包方法，該方法適用于安卓(android)系統(tǒng)。具體地，每個用戶定制產(chǎn)品具有多個不同的配置信息(該配置信息在下文中會詳述)。

則上述批量打包方法中，針對同一個批次的所有用戶定制產(chǎn)品的批量打包方法具體如圖1所示，包括：

步驟s1，形成一用于執(zhí)行用戶定制產(chǎn)品的底層邏輯操作的邏輯單元；

步驟s2，形成一用于展示用戶定制產(chǎn)品的產(chǎn)品元素的展示單元；

步驟s3，形成邏輯單元與展示單元之間的對應關(guān)系；

步驟s4，整理用戶定制產(chǎn)品的配置信息，以形成包括不同的用戶定制產(chǎn)品的配置文件；

步驟s5，根據(jù)配置文件對同一個批次內(nèi)的所有用戶定制產(chǎn)品進行批量打包操作，以分別形成關(guān)聯(lián)于每個用戶定制產(chǎn)品的產(chǎn)品安裝文件；

每個產(chǎn)品安裝文件中包括展示單元中對應于用戶定制產(chǎn)品的配置文件，以及邏輯單元中對應于用戶定制產(chǎn)品的底層邏輯操作的代碼文件。

具體地，本實施例中，上述用戶定制產(chǎn)品即oem產(chǎn)品，因此下文中采用oem產(chǎn)品來替代“用戶定制產(chǎn)品”進行描述。

本實施例中，上述步驟s1中形成的邏輯單元即為oem產(chǎn)品應用的邏輯層，該邏輯層主要負責業(yè)務代碼以及數(shù)據(jù)協(xié)議交互等方面的工作。

本實施例中，上述步驟s2中形成的展示單元即為oem產(chǎn)品應用的展示層，該展示層主要負責顯示各個oem產(chǎn)品的工作。

因此，本實施例中，上述步驟s1和步驟s2實際為采用分庫的方式，將整個應用劃分成邏輯層和展示層兩大塊。

本實施例中，上文中所述的“邏輯單元”和“展示單元”均為開發(fā)和形成oem產(chǎn)品的開發(fā)應用的相關(guān)單元。換言之，將開發(fā)oem產(chǎn)品的開發(fā)應用分城邏輯層和展示層兩大塊。

進一步地，上述步驟s1中形成邏輯單元的方式是抽取應用中的邏輯層代碼。

相應地，上述步驟s2中形成展示單元的方式是抽取應用中的展示層代碼。

本實施例中，上述步驟s3中，上述邏輯單元和展示單元之間的對應關(guān)系具體為：邏輯單元作為展示單元的被依賴單元(即邏輯單元作為展示單元的依賴庫)。

即上述步驟s1中，抽取邏輯層的相應代碼并形成一個獨立的邏輯單元，并將邏輯單元作為核心依賴庫；相應地，上述步驟s2中，抽取ui層的相應代碼并形成一個獨立的展示單元，并把上述邏輯層的業(yè)務代碼作為展示單元的library包含，即建立邏輯單元和展示單元的依賴關(guān)系。

本實施例中，上述步驟s4中，根據(jù)上述已被分離的邏輯單元和展示單元，對同一個批次的所有oem產(chǎn)品均進行配置信息的整理，以形成包括該同一個批次的所有oem產(chǎn)品的配置文件。該配置文件在展示單元的存儲和展示方式為樹形文件夾的方式。該樹形文件夾中，根目錄為不同的oem產(chǎn)品的產(chǎn)品資源，根目錄下的不同的子目錄分別代表該oem產(chǎn)品的各個配置信息。

本實施例中，最終應用根據(jù)上述已經(jīng)形成的配置文件，將每個oem產(chǎn)品的文件夾作為一個獨立的庫進行依次打包，以將同一批次的oem產(chǎn)品批量打包分別形成對應的產(chǎn)品安裝文件，該產(chǎn)品安裝文件中包括展示單元中對應于用戶定制產(chǎn)品的配置文件，以及邏輯單元中對應于用戶定制產(chǎn)品的底層邏輯操作的代碼文件。

本實施例中，上述步驟s1-s5可以重復進行，以分別對不同批次的oem產(chǎn)品進行批量打包操作。

本發(fā)明的較佳的實施例中，上述配置信息中可以包括下文中的至少一種：

用戶定制產(chǎn)品的圖標信息(logo信息)；

用戶定制產(chǎn)品的標題信息；

用戶定制產(chǎn)品的簽名信息；以及

用戶定制產(chǎn)品對應的代理商主頁信息。

則本發(fā)明的較佳的實施例中，上述樹形文件夾中，根目錄下的不同的子目錄分別表示上述配置信息中的一種。

本發(fā)明的較佳的實施例中，上述展示單元中，針對每個用戶定制產(chǎn)品形成一對應的產(chǎn)品文件夾，產(chǎn)品文件夾中包括對應的用戶定制產(chǎn)品的所有配置信息；

則上述步驟s5中，對用戶定制產(chǎn)品進行打包的過程具體如圖2中所示，包括：

步驟s51，針對每個用戶定制產(chǎn)品分別增加一可定義子節(jié)點；

步驟s52，針對每個用戶定制產(chǎn)品分別增加源集節(jié)點，每個源集節(jié)點分別指向用戶定制產(chǎn)品的源代碼目錄下對應的產(chǎn)品文件夾的存儲位置；

步驟s53，針對每個用戶定制產(chǎn)品分別修改對應的默認配置屬性；

步驟s54，對同一個批次內(nèi)的所有用戶定制產(chǎn)品進行批量打包操作，以分別形成關(guān)聯(lián)于每個用戶定制產(chǎn)品的產(chǎn)品安裝文件。

本發(fā)明的較佳的實施例中，對上述oem產(chǎn)品進行打包可以通過修改android系統(tǒng)中的gradle配置腳本實現(xiàn)，即通過修改gradle配置腳本將每個oem產(chǎn)品的文件夾都當作一個獨立的庫進行打包操作。

具體地，上述步驟s51中，上述可定義子節(jié)點即為android系統(tǒng)下的productflavors節(jié)點，即上述步驟s51中，針對每個oem產(chǎn)品分別增加對應的一個productflavors節(jié)點，有幾個oem就增加幾個子節(jié)點。

上述步驟s52中，上述源集節(jié)點即為android系統(tǒng)下的sourcesets節(jié)點，針對每個oem文件夾的sourcesets節(jié)點分別指向該oem對應的源代碼(src)目錄下的文件夾的存儲位置。

上述步驟s53中，上述默認配置屬性即為android系統(tǒng)下的defaultconfig屬性。上述每個oem文件夾中若有相同的屬性，可以統(tǒng)一在這里進行配置。

上述步驟s54中，最終通過gradle命令執(zhí)行批量打包操作。具體地，指令下發(fā)控制gradlewassemblerelease對所有的release包進行打包，也可以采用gradle指令對指定的oem進行打包。

本發(fā)明技術(shù)方案中，通過將邏輯層和展示層模塊的代碼分庫拆開，以形成相對獨立又具有依賴關(guān)系的邏輯單元和展示單元，則每次新增或者修改oem包時，只需要增加或者修改配置節(jié)點并修改對應節(jié)點目錄下的配置文件圖片即可。在對oem進行批量打包時核心依賴庫的代碼只需要編譯一次，因此提升了打包速度，并使得開發(fā)分工更明確，版本管理更方便。

以上所述僅為本發(fā)明較佳的實施例，并非因此限制本發(fā)明的實施方式及保護范圍，對于本領(lǐng)域技術(shù)人員而言，應當能夠意識到凡運用本發(fā)明說明書及圖示內(nèi)容所作出的等同替換和顯而易見的變化所得到的方案，均應當包含在本發(fā)明的保護范圍內(nèi)。