本發(fā)明涉及互聯(lián)網(wǎng)領域，具體提供了一種應用程序打包方法、裝置及終端設備。

背景技術：

目前，安卓開發(fā)工具androdstudio在應用程序打包過程中，由于安卓虛擬機機制的緣故，其方法數(shù)被定義在65535個，如果函數(shù)個數(shù)超過65535個，虛擬機就無法正常加載dex文件。因此也就會導致安卓應用程序報錯。谷歌公司為了解決這個問題，在應用程序打包時，引入了multidex的解決方案。multidex解決方案的做法是將超過65535個方法的dex文件，分成多個dex文件，然后在應用程序啟動的時候再依次加載合并回去，繞過了安卓虛擬機不能加載65535個方案，multidex的引入，雖然解決了方法數(shù)超過65535個，但卻不能滿足業(yè)務擴展需求，因為multidex不能根據(jù)業(yè)務包名單獨自由分包。因此不能滿足安卓組件化業(yè)務所需的將特定功能代碼分成特定dex文件的需求。

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

有鑒于此，本發(fā)明實施例的目的在于提供一種應用程序打包方法、裝置及終端設備，旨在實現(xiàn)安卓特定業(yè)務代碼在打包時可以分成特定dex文件的解決方案。

為了達到上述的目的，本發(fā)明實施例采用的技術方案如下所述：

第一方面，本發(fā)明實施例提供了一種應用程序打包方法，所述方法包括：獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件；解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件；從所述解壓文件中選中指定文件；將所述指定文件轉(zhuǎn)換成dex文件；將所述dex文件壓入應用文件以得到所述應用程序。

第二方面，本發(fā)明實施例提供了一種應用程序打包裝置，所述裝置包括獲取模塊、解壓模塊、選擇模塊以及打包模塊。其中獲取模塊用于獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件；解壓模塊用于解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件；選擇模塊用于從所述解壓文件中選中指定文件；轉(zhuǎn)換模塊用于將所述指定文件轉(zhuǎn)換成dex文件；打包模塊用于將所述dex文件壓入應用文件以得到所述應用程序。

第三方面，本發(fā)明實施例提供了一種終端設備，包括處理器、存儲器以及應用程序打包裝置。所述應用程序打包裝置安裝于所述存儲器中并包括一個或多個由所述處理器執(zhí)行的軟件功能模塊，所述應用程序打包裝置包括獲取模塊、解壓模塊、選擇模塊以及打包模塊。其中獲取模塊用于獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件；解壓模塊用于解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件；選擇模塊用于從所述解壓文件中選中指定文件；轉(zhuǎn)換模塊用于將所述指定文件轉(zhuǎn)換成dex文件；打包模塊用于將所述dex文件壓入應用文件以得到所述應用程序。

本發(fā)明實施例提供的應用程序打包方法、裝置及終端設備，該應用程序打包方法包括：獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件；解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件；從所述解壓文件中選中指定文件；將所述指定文件轉(zhuǎn)換成dex文件；將所述dex文件壓入應用文件以得到所述應用程序。本發(fā)明提供的應用程序打包方法、裝置及終端設備在安卓應用程序打包過程中，將特定包名的模塊單獨打包成dex文件，將部分獨立的業(yè)務打包成dex文件，在用戶用到該業(yè)務時再去加載，不必啟動時立刻去加載，避免啟動時間長的問題，有著更好的業(yè)務模式，為動態(tài)加載方案提供基礎的打包支持。

為使本發(fā)明的上述目的、特征和優(yōu)點能更明顯易懂，下文特舉較佳實施例，并配合所附附圖，作詳細說明如下。

附圖說明

為了更清楚地說明本發(fā)明實施例的技術方案，下面將對實施例中所需要使用的附圖作簡單地介紹，應當理解，以下附圖僅示出了本發(fā)明的某些實施例，因此不應被看作是對范圍的限定，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他相關的附圖。

圖1是本發(fā)明實施例提供的終端設備的方框示意圖。

圖2是本發(fā)明實施例提供的應用程序打包方法的流程圖。

圖3是現(xiàn)有技術中對dex文件的拆分示意圖。

圖4是本發(fā)明實施例對dex文件的拆分示意圖。

圖5是本發(fā)明實施例提供的應用程序打包裝置110的功能模塊架構示意圖。

圖標：100-終端設備；110-應用程序打包裝置；111-獲取模塊；112-解壓模塊；113-選擇模塊；114-轉(zhuǎn)換模塊；115-打包模塊；116-注冊模塊；117-壓縮模塊；120-存儲器；130-處理器。

具體實施方式

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例。通常在此處附圖中描述和示出的本發(fā)明實施例的組件可以以各種不同的配置來布置和設計。

因此，以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的范圍，而是僅僅表示本發(fā)明的選定實施例。基于本發(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

應注意到：相似的標號和字母在下面的附圖中表示類似項，因此，一旦某一項在一個附圖中被定義，則在隨后的附圖中不需要對其進行進一步定義和解釋。

本發(fā)明實施例提供的應用程序打包方法及裝置應用于終端設備。該終端設備可以是，但不限于，個人電腦(personalcomputer，pc)、服務器。

請參照圖1，是該終端設備100的方框示意圖。該終端設備100包括應用程序打包裝置110、存儲器120和處理器130。

存儲器120、處理器130相互之間直接或間接地電性連接，以實現(xiàn)數(shù)據(jù)的傳輸或交互。例如，這些元件相互之間可通過一條或多條通訊總線或信號線實現(xiàn)電性連接。應用程序打包裝置110包括至少一個可以軟件或固件(firmware)的形式存儲于存儲器120中或固化在終端設備100的操作系統(tǒng)(operatingsystem，os)中的軟件功能模塊。處理器130用于執(zhí)行所述存儲器120中存儲的可執(zhí)行模塊，例如應用程序打包裝置110所包括的軟件功能模塊及計算機程序等。

其中，存儲器120可以是，但不限于，隨機存取存儲器(randomaccessmemory，ram)，只讀存儲器(readonlymemory，rom)，可編程只讀存儲器(programmableread-onlymemory，prom)，可擦除只讀存儲器(erasableprogrammableread-onlymemory，eprom)，電可擦除只讀存儲器(electricerasableprogrammableread-onlymemory，eeprom)等。其中，存儲器120用于存儲程序，處理器130在接收到執(zhí)行指令后，執(zhí)行該程序。處理器130以及其他可能的組件對存儲器120的訪問可在存儲控制器140的控制下進行。

處理器130可能是一種集成電路芯片，具有信號的處理能力。上述的處理器130可以是通用處理器，包括中央處理器(centralprocessingunit，cpu)、網(wǎng)絡處理器(networkprocessor，np)等；還可以是數(shù)字信號處理器(dsp))、專用集成電路(asic)、現(xiàn)成可編程門陣列(fpga)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件?？梢詫崿F(xiàn)或者執(zhí)行本發(fā)明實施例中的公開的各方法、步驟及邏輯框圖。通用處理器可以是微處理器或者該處理器也可以是任何常規(guī)的處理器等。

本發(fā)明實施例提供的應用程序打包方法應用于終端設備100，請參照圖2，該應用程序打包方法包括以下步驟：

步驟s101，獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件。

打包工具在將java代碼文件優(yōu)化為dex文件前，需先生成jar壓縮文件，jar壓縮文件為java代碼編譯后的可執(zhí)行代碼集合文件，jar壓縮文件生成后再打包成dex文件。本發(fā)明實施例中，打包工具為gradle打包工具，通過編寫插件，使用命令，強行將需要被轉(zhuǎn)換為dex文件的jar壓縮文件提取出來，如main.jar、proguard.jar，提取命令可為task.dofirst。

步驟s102，解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件。

解壓后的文件中，包括多個功能代碼，這些功能代碼具有各自特定的功能，在組件化業(yè)務中，需要用到的功能代碼通過內(nèi)置或者在線下發(fā)，起到降低包體的目的。本發(fā)明實施例中，指定文件為需要單獨轉(zhuǎn)換為dex文件的功能代碼。

步驟s103，從所述解壓文件中選中指定文件。

步驟s104，將所述指定文件轉(zhuǎn)換為dex文件。

在本實施例中，通過gradle工具將指定文件轉(zhuǎn)換為dex文件，在轉(zhuǎn)換過程中，按照預定的包路徑進行轉(zhuǎn)換，方便后期選取特定業(yè)務，包路徑通過預先注冊得到。具體的，將指定文件按照預定的包路徑放入預設的文件夾中，再重新壓縮指定文件，通過gradle工具將壓縮文件轉(zhuǎn)換為dex文件。

步驟s105，將所述dex文件壓入應用文件以得到所述應用程序。

當需要單獨打包為dex文件的功能代碼全部轉(zhuǎn)換為dex文件之后，將轉(zhuǎn)換得到的dex文件壓入應用文件中，得到應用程序。該應用文件為gradle工具生成的應用程序包。

在本實施例中，對于非指定文件(功能代碼中除指定文件外的文件)，會被壓縮回解壓前的壓縮文件中，然后再通過gradle工具進行對壓縮文件打包以生成應用文件。

步驟s106，對所述應用程序進行簽名校驗。

通過上述步驟，即完成應用程序的打包過程，打包后的應用程序包括多個dex文件，每一個dex文件具有單獨的功能業(yè)務，在后期用戶需要用到某一業(yè)務時，再去加載與該業(yè)務對應的dex文件，不需要在啟動時立即去加載，避免了啟動時間長的問題。為使本發(fā)明實施例更易理解，請參照圖3，是現(xiàn)有技術中，將超過65535個方法的dex文件分成多個dex文件的示意圖。其中，dex文件被拆分成dex1、dex2、dex3…dex文件中的功能業(yè)務被打亂，可能融合在拆分出來的多個dex中，例如，對于功能業(yè)務1，融合在dex1和dex2中，功能業(yè)務2融合在dex2和dex3中，要實現(xiàn)功能業(yè)務1和功能業(yè)務2，需要依次加載dex1、dex2和dex3，這無疑將增加啟動時間。本發(fā)明實施例提供的應用程序打包方法打包的應用程序請參照圖4，由于在打包過程中，各個功能業(yè)務根據(jù)需要單獨打包轉(zhuǎn)換為dex文件，所以每個需要用到的功能業(yè)務為單獨的dex文件，其中，dex文件被拆分成dex1’、dex2’、dex3’…功能業(yè)務1被打包在dex1’中，功能業(yè)務2被打包在dex2’中，例如，在用戶需要使用功能業(yè)務2時，只需要加載dex2’即可，無需先加載dex1’，再加載dex2’，也無需加載dex3’，節(jié)約了啟動時間，滿足組件化業(yè)務的需求，實現(xiàn)動態(tài)加載方案。

請參照圖5，是本發(fā)明實施例提供的應用程序打包裝置110的功能模塊架構示意圖，該應用程序打包裝置110包括獲取模塊111、解壓模塊112、選擇模塊113、轉(zhuǎn)換模塊114和打包模塊115。

其中，獲取模塊111用于獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件。

在本實施例中，獲取模塊111可用于執(zhí)行步驟s101。打包工具在將java代碼文件優(yōu)化為dex文件前，需先生成jar壓縮文件，jar壓縮文件為java代碼編譯后的可執(zhí)行代碼集合文件，jar壓縮文件生成后再打包成dex文件。本發(fā)明實施例中，打包工具為gradle打包工具，通過編寫插件，使用命令，強行將需要被轉(zhuǎn)換為dex文件的jar壓縮文件提取出來，如main.jar、proguard.jar，提取命令可為task.dofirst。

解壓模塊112用于解壓所述壓縮文件得到解壓文件。

在本實施例中，解壓模塊112可用于執(zhí)行步驟s102。解壓后的文件中，包括多個功能代碼，這些功能代碼具有各自特定的功能，在組件化業(yè)務中，需要用到的功能代碼通過內(nèi)置或者在線下發(fā)，起到降低包體的目的。本發(fā)明實施例中，指定文件為需要單獨轉(zhuǎn)換為dex文件的功能代碼。

選擇模塊113用于從所述解壓文件中選中指定文件。

在本實施例中，選擇模塊113可用于執(zhí)行步驟s103。

轉(zhuǎn)換模塊114用于將所述指定文件轉(zhuǎn)換成dex文件。

在本實施例中，轉(zhuǎn)換模塊114可用于執(zhí)行步驟s104。在本實施例中，通過gradle工具將指定文件轉(zhuǎn)換為dex文件，在轉(zhuǎn)換過程中，按照預定的包路徑進行轉(zhuǎn)換，方便后期選取特定業(yè)務，包路徑通過預先注冊得到。具體的，將指定文件按照預定的包路徑放入預設的文件夾中，再重新壓縮指定文件，通過gradle工具將壓縮文件轉(zhuǎn)換為dex文件。本發(fā)明實施例提供的應用程序打包裝置110還包括注冊模塊116，用于注冊包路徑。

打包模塊115用于將所述dex文件壓入應用文件以得到所述應用程序。

在本實施例中，打包模塊115可用于執(zhí)行步驟s105。當需要單獨打包為dex文件的功能代碼全部轉(zhuǎn)換為dex文件之后，將轉(zhuǎn)換得到的dex文件壓入應用文件中，得到應用程序。該應用文件為gradle工具生成的應用程序包。

進一步地，該應用程序打包裝置110還包括壓縮模塊117，對于非指定文件(功能代碼中除指定文件外的文件)，會被壓縮回解壓前的壓縮文件中，然后再通過gradle工具進行對壓縮文件打包以生成應用文件。壓縮模塊117用于將非指定文件壓縮回所述壓縮文件中。

該應用程序打包裝置110還包括簽名模塊118，用于對所述應用程序進行簽名校驗。

綜上所述，本發(fā)明實施例提供了一種應用程序打包方法、裝置及終端設備。該應用程序打包方法包括：獲取java文件轉(zhuǎn)換為dex文件過程中產(chǎn)生的壓縮文件；解壓所述壓縮文件得到解壓文件，所述解壓文件包括指定文件；從所述解壓文件中選中指定文件；將所述指定文件轉(zhuǎn)換成dex文件；將所述dex文件壓入應用文件以得到所述應用程序。本發(fā)明提供的應用程序打包方法、裝置及終端設備在安卓應用程序打包過程中，將特定包名的模塊單獨打包成dex文件，將部分獨立的業(yè)務打包成dex文件，在用戶用到該業(yè)務時再去加載，不必啟動時立刻去加載，避免啟動時間長的問題，有著更好的業(yè)務模式，為動態(tài)加載方案提供基礎的打包支持。

在本申請所提供的幾個實施例中，應該理解到，所揭露的裝置和方法，也可以通過其它的方式實現(xiàn)。以上所描述的裝置實施例僅僅是示意性的，例如，附圖中的流程圖和框圖顯示了根據(jù)本發(fā)明的多個實施例的裝置、方法和計算機程序產(chǎn)品的可能實現(xiàn)的體系架構、功能和操作。在這點上，流程圖或框圖中的每個方框可以代表一個模塊、程序段或代碼的一部分，所述模塊、程序段或代碼的一部分包含一個或多個用于實現(xiàn)規(guī)定的邏輯功能的dex指令。也應當注意，在有些作為替換的實現(xiàn)方式中，方框中所標注的功能也可以以不同于附圖中所標注的順序發(fā)生。例如，兩個連續(xù)的方框?qū)嶋H上可以基本并行地執(zhí)行，它們有時也可以按相反的順序執(zhí)行，這依所涉及的功能而定。也要注意的是，框圖和/或流程圖中的每個方框、以及框圖和/或流程圖中的方框的組合，可以用執(zhí)行規(guī)定的功能或動作的專用的基于硬件的系統(tǒng)來實現(xiàn)，或者可以用專用硬件與計算機指令的組合來實現(xiàn)。

另外，在本發(fā)明各個實施例中的各功能模塊可以集成在一起形成一個獨立的部分，也可以是各個模塊單獨存在，也可以兩個或兩個以上模塊集成形成一個獨立的部分。

所述功能如果以軟件功能模塊的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質(zhì)中?；谶@樣的理解，本發(fā)明的技術方案本質(zhì)上或者說對現(xiàn)有技術做出貢獻的部分或者該技術方案的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：u盤、移動硬盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。應注意到：相似的標號和字母在下面的附圖中表示類似項，因此，一旦某一項在一個附圖中被定義，則在隨后的附圖中不需要對其進行進一步定義和解釋。