本發(fā)明涉及移動終端
技術領域：
，具體涉及一種移動終端及應用修復方法。
背景技術：
：當一個應用發(fā)布之后，突然發(fā)現一個嚴重問題需要緊急修復時，按照常規(guī)的做法：應用開發(fā)商需要對該應用進行修復，重新打包應用，對應用包進行測試，并在測試通過后向各個應用市場和渠道換包，提示用戶升級，提示用戶下載修復后的應用包，然后對已安裝出現問題的應用進行覆蓋安裝。然而，當解決這個問題所需要修改的代碼量很小時，也同樣要付出巨大的成本進行換包和重新發(fā)布。而且，當應用開發(fā)商發(fā)布修復問題之后的升級應用包后，用戶也不一定會馬上升級到新版本的應用?？梢钥闯?，現有技術中存在應用修復效率較低的問題。技術實現要素：本發(fā)明提供一種移動終端及應用修復方法，旨在提高應用的修復效率。為實現上述發(fā)明目的，本發(fā)明提供一種移動終端，該移動終端包括：第一獲取模塊，用于在啟動待修復應用時，獲取對應所述待修復應用的補丁包，所述補丁包包括唯一可執(zhí)行文件，所述唯一可執(zhí)行文件攜帶所述待修復應用發(fā)生錯誤的類所對應的修復后的正確類；第二獲取模塊，用于獲取對應所述待修復應用各可執(zhí)行文件的第一數組，并構造對應所述唯一可執(zhí)行文件的第二數組；修復模塊，用于將所述第一數組與第二數組合并為一個數組，并將所述唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，以供加載。可選地，所述移動終端還包括校驗模塊，用于對獲取的所述補丁包進行安全校驗；所述第二獲取模塊還用于在安全校驗通過后，獲取對應所述待修復應用各可執(zhí)行文件的第一數組，并構造對應所述唯一可執(zhí)行文件的第二數組?？蛇x地，所述校驗模塊還用于采用約定的消息摘要算法計算所述唯一可執(zhí)行文件的消息摘要；還用于將計算得到的消息摘要與所述補丁包攜帶的消息摘要進行比對，其中，在二者比對一致時，確定所述補丁包通過安全校驗?？蛇x地，所述第一獲取模塊還用于發(fā)送補丁包獲取請求至預設服務器，所述補丁包獲取請求包括所述待修復應用的版本信息以及已安裝補丁包的版本信息；還用于接收所述預設服務器基于所述補丁包獲取請求返回的對應所述待修復應用的最新版本的補丁包?？蛇x地，所述修復模塊還用于在偵測到所述待修復應用運行錯誤時，確定所述待修復應用發(fā)生錯誤的類；還用于將確定的類信息上傳至所述預設服務器，以供其他終端在基于所述類信息修復發(fā)生錯誤的類之后，將修復后的正確類打包為可執(zhí)行文件，并生成對應的補丁包上傳至所述預設服務器。此外，為實現上述發(fā)明目的，本發(fā)明還提供一種應用修復方法，該應用修復方法包括：在啟動待修復應用時，獲取對應所述待修復應用的補丁包，所述補丁包包括唯一可執(zhí)行文件，所述唯一可執(zhí)行文件攜帶所述待修復應用發(fā)生錯誤的類所對應的修復后的正確類；獲取對應所述待修復應用各可執(zhí)行文件的第一數組，并構造對應所述唯一可執(zhí)行文件的第二數組；將所述第一數組與第二數組合并為一個數組，并將所述唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，以供加載。可選地，所述獲取對應所述待修復應用各可執(zhí)行文件的第一數組，并構造對應所述唯一可執(zhí)行文件的第二數組的步驟之前，還包括：對獲取的所述補丁包進行安全校驗；在安全校驗通過后，執(zhí)行所述獲取對應所述待修復應用各可執(zhí)行文件的第一數組，并構造對應所述唯一可執(zhí)行文件的第二數組的步驟。可選地，所述對獲取的所述補丁包進行安全校驗的步驟包括：采用約定的消息摘要算法計算所述唯一可執(zhí)行文件的消息摘要；將計算得到的消息摘要與所述補丁包攜帶的消息摘要進行比對，其中，在二者比對一致時，確定所述補丁包通過安全校驗?？蛇x地，所述獲取對應所述待修復應用的補丁包的步驟包括：發(fā)送補丁包獲取請求至預設服務器，所述補丁包獲取請求包括所述待修復應用的版本信息以及已安裝補丁包的版本信息；接收所述預設服務器基于所述補丁包獲取請求返回的對應所述待修復應用的最新版本的補丁包?？蛇x地，所述在啟動待修復應用時，獲取對應所述待修復應用的補丁包的步驟之前，還包括：在偵測到所述待修復應用運行錯誤時，確定所述待修復應用發(fā)生錯誤的類；將確定的類信息上傳至所述預設服務器，以供其他終端在基于所述類信息修復發(fā)生錯誤的類之后，將修復后的正確類打包為可執(zhí)行文件，并生成對應的補丁包上傳至所述預設服務器。本發(fā)明提出的移動終端及應用修復方法，通過在啟動待修復應用時，獲取到對應待修復應用的補丁包，進而構造與補丁包攜帶唯一可執(zhí)行文件對應的第二數組，并將該第二數組與對應待修復應用各可執(zhí)行文件的第一數組合并為一個數組，將前述唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，從而在加載類文件時，首先加載前述唯一可執(zhí)行文件攜帶的待修復應用發(fā)生錯誤的類所對應的修復后的正確類，而不加載錯誤類，避免了現有技術在應用運行錯誤時需要按照新版本的應用才能修復錯誤，又不會中斷用戶使用應用，實現了應用的高效修復。附圖說明圖1為實現本發(fā)明各個實施例的一個移動終端的硬件結構示意圖；圖2為本發(fā)明移動終端第一實施例的模塊示意圖；圖3為本發(fā)明移動終端第一實施例中對應用包進行分包的示例圖；圖4為本發(fā)明移動終端第一實施例中待修復應用以及補丁包的結構示意圖；圖5為本發(fā)明移動終端第一實施例中第一數組的結構示意圖；圖6為本發(fā)明移動終端第一實施例中第二數組的結構示意圖；圖7為本發(fā)明移動終端第一實施例中合并后數組的結構示意圖；圖8為本發(fā)明移動終端第一實施例中類替換的實現原理示意圖；圖9為本發(fā)明移動終端第一實施例中的應用熱修復架構示意圖；圖10本發(fā)明為本發(fā)明應用修復方法第一實施例的流程示意圖。具體實施方式應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。需要說明的是，在不沖突的情況下，本發(fā)明中的實施例及實施例中的特征可以相互任意結合。現在將參考附圖描述實現本發(fā)明各個實施例的移動終端。在后續(xù)的描述中，使用用于表示元件的諸如“模塊”、“部件”或“單元”的后綴僅為了有利于本發(fā)明的說明，其本身并沒有特定的意義。因此，"模塊"與"部件"可以混合地使用。移動終端可以以各種形式來實施。例如，本發(fā)明中描述的移動終端可以包括諸如移動電話、智能電話、筆記本電腦、數字廣播接收器、pda(個人數字助理)、pad(平板電腦)、pmp(便攜式多媒體播放器)、導航裝置等，本領域技術人員將理解的是，除了特別用于移動目的的元件之外，根據本發(fā)明的實施方式的構造也能夠應用于固定類型的終端。圖1為實現本發(fā)明各個實施例的一個移動終端的硬件結構示意圖。移動終端100可以包括無線通信單元110、a/v(音頻/視頻)輸入單元120、用戶輸入單元130、感測單元140、輸出單元150、存儲器160、接口單元170、控制器180和電源單元190等等。圖1示出了具有各種組件的移動終端，但是應理解的是，并不要求實施所有示出的組件。可以替代地實施更多或更少的組件。將在下面詳細描述移動終端的元件。無線通信單元110通常包括一個或多個組件，其允許移動終端100與無線通信系統(tǒng)或網絡之間的無線電通信。例如，無線通信單元可以包括移動通信模塊111、無線互聯網模塊112和短距無線通信模塊113中的至少一個。移動通信模塊111將無線電信號發(fā)送到基站(例如，接入點、節(jié)點b等等)、外部終端以及服務器中的至少一個和/或從其接收無線電信號。這樣的無線電信號可以包括語音通話信號、視頻通話信號、或者根據文本和/或多媒體消息發(fā)送和/或接收的各種類型的數據。無線互聯網模塊112支持移動終端的無線互聯網接入。該模塊可以內部或外部地耦接到終端。該模塊所涉及的無線互聯網接入技術可以包括wibro(無線寬帶)、wimax(全球微波互聯接入)、hsdpa(高速下行鏈路分組接入)等等。短距無線通信模塊113是用于支持短程通信的模塊。短程通信技術的一些示例包括wlan(無線lan)(wi-fi)、藍牙tm、射頻識別(rfid)、紅外數據協(xié)會(irda)、超寬帶(uwb)、紫蜂tm以及近場通訊(nfc)等等。a/v輸入單元120用于接收音頻或視頻信號。a/v輸入單元120可以包括相機121和麥克風122，相機121對在視頻捕獲模式或圖像捕獲模式中由圖像捕獲裝置獲得的靜態(tài)圖片或視頻的圖像數據進行處理。處理后的圖像幀可以顯示在顯示單元151上。經相機121處理后的圖像幀可以存儲在存儲器160(或其它存儲介質)中或者經由無線通信單元110進行發(fā)送，可以根據移動終端的構造提供兩個或更多相機121。麥克風122可以在電話通話模式、記錄模式、語音識別模式等等運行模式中經由麥克風接收聲音(音頻數據)，并且能夠將這樣的聲音處理為音頻數據。處理后的音頻(語音)數據可以在電話通話模式的情況下轉換為可經由移動通信模塊112發(fā)送到移動通信基站的格式輸出。麥克風122可以實施各種類型的噪聲消除(或抑制)算法以消除(或抑制)在接收和發(fā)送音頻信號的過程中產生的噪聲或者干擾。用戶輸入單元130可以根據用戶輸入的命令生成鍵輸入數據以控制移動終端的各種操作。用戶輸入單元130允許用戶輸入各種類型的信息，并且可以包括鍵盤、鍋仔片、觸摸板(例如，檢測由于被接觸而導致的電阻、壓力、電容等等的變化的觸敏組件)、滾輪、搖桿等等。特別地，當觸摸板以層的形式疊加在顯示單元151上時，可以形成觸摸屏。感測單元140檢測移動終端100的當前狀態(tài)，(例如，移動終端100的打開或關閉狀態(tài))、移動終端100的位置、用戶對于移動終端100的接觸(即，觸摸輸入)的有無、移動終端100的取向、移動終端100的加速或減速移動和方向等等，并且生成用于控制移動終端100的操作的命令或信號。例如，當移動終端100實施為滑動型移動電話時，感測單元140可以感測該滑動型電話是打開還是關閉。另外，感測單元140能夠檢測電源單元190是否提供電力或者接口單元170是否與外部裝置耦接。接口單元170用作至少一個外部裝置與移動終端100連接可以通過的接口。例如，外部裝置可以包括有線或無線頭戴式耳機端口、外部電源(或電池充電器)端口、有線或無線數據端口、存儲卡端口、用于連接具有識別模塊的裝置的端口、音頻輸入/輸出(i/o)端口、視頻i/o端口、耳機端口等等。識別模塊可以是存儲用于驗證用戶使用移動終端100的各種信息并且可以包括用戶識別模塊(uim)、客戶識別模塊(sim)、通用客戶識別模塊(usim)等等。另外，具有識別模塊的裝置(下面稱為"識別裝置")可以采取智能卡的形式，因此，識別裝置可以經由端口或其它連接裝置與移動終端100連接。接口單元170可以用于接收來自外部裝置的輸入(例如，數據信息、電力等等)并且將接收到的輸入傳輸到移動終端100內的一個或多個元件或者可以用于在移動終端和外部裝置之間傳輸數據。另外，當移動終端100與外部底座連接時，接口單元170可以用作允許通過其將電力從底座提供到移動終端100的路徑或者可以用作允許從底座輸入的各種命令信號通過其傳輸到移動終端的路徑。從底座輸入的各種命令信號或電力可以用作用于識別移動終端是否準確地安裝在底座上的信號。輸出單元150被構造為以視覺、音頻和/或觸覺方式提供輸出信號(例如，音頻信號、視頻信號、警報信號、振動信號等等)。輸出單元150可以包括顯示單元151、音頻輸出模塊152等。顯示單元151可以顯示在移動終端100中處理的信息。例如，當移動終端100處于電話通話模式時，顯示單元151可以顯示與通話或其它通信(例如，文本消息收發(fā)、多媒體文件下載等等)相關的用戶界面(ui)或圖形用戶界面(gui)。當移動終端100處于視頻通話模式或者圖像捕獲模式時，顯示單元151可以顯示捕獲的圖像和/或接收的圖像、顯示出視頻或圖像以及相關功能的ui或gui等等。同時，當顯示單元151和觸摸板以層的形式彼此疊加以形成觸摸屏時，顯示單元151可以用作輸入裝置和輸出裝置。顯示單元151可以包括液晶顯示器(lcd)、薄膜晶體管lcd(tft-lcd)、有機發(fā)光二極管(oled)顯示器、柔性顯示器、三維(3d)顯示器等等中的至少一種。這些顯示器中的一些可以被構造為透明狀以允許用戶從外部觀看，這可以稱為透明顯示器，典型的透明顯示器可以例如為toled(透明有機發(fā)光二極管)顯示器等等。根據特定想要的實施方式，移動終端100可以包括兩個或更多顯示單元(或其它顯示裝置)，例如，移動終端可以包括外部顯示單元(未示出)和內部顯示單元(未示出)。觸摸屏可用于檢測觸摸輸入壓力以及觸摸輸入位置和觸摸輸入面積。音頻輸出模塊152可以在移動終端處于呼叫信號接收模式、通話模式、記錄模式、語音識別模式、廣播接收模式等等模式下時，將無線通信單元110接收的或者在存儲器160中存儲的音頻數據轉換音頻信號并且輸出為聲音。而且，音頻輸出模塊152可以提供與移動終端100執(zhí)行的特定功能相關的音頻輸出(例如，呼叫信號接收聲音、消息接收聲音等等)。音頻輸出模塊152可以包括揚聲器、蜂鳴器等等。存儲器160可以存儲由控制器180執(zhí)行的處理和控制操作的軟件程序等等，例如，可以存儲實現本發(fā)明應用修復方法的軟件程序，或者可以暫時地存儲己經輸出或將要輸出的數據(例如，電話簿、消息、靜態(tài)圖像、視頻等等)。而且，存儲器160可以存儲關于當觸摸施加到觸摸屏時輸出的各種方式的振動和音頻信號的數據。存儲器160可以包括至少一種類型的存儲介質，所述存儲介質包括閃存、硬盤、多媒體卡、卡型存儲器(例如，sd或dx存儲器等等)、隨機訪問存儲器(ram)、靜態(tài)隨機訪問存儲器(sram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、可編程只讀存儲器(prom)、磁性存儲器、磁盤、光盤等等。而且，移動終端100可以與通過網絡連接執(zhí)行存儲器160的存儲功能的網絡存儲裝置協(xié)作。控制器180通?？刂埔苿咏K端的總體操作。例如，控制器180執(zhí)行與語音通話、數據通信、視頻通話等等相關的控制和處理。控制器180可以執(zhí)行模式識別處理，以將在觸摸屏上執(zhí)行的手寫輸入或者圖片繪制輸入識別為字符或圖像。電源單元190在控制器180的控制下接收外部電力或內部電力并且提供操作各元件和組件所需的適當的電力。這里描述的各種實施方式可以以使用例如計算機軟件、硬件或其任何組合的計算機可讀介質來實施。對于硬件實施，這里描述的實施方式可以通過使用特定用途集成電路(asic)、數字信號處理器(dsp)、數字信號處理裝置(dspd)、可編程邏輯裝置(pld)、現場可編程門陣列(fpga)、處理器、控制器、微控制器、微處理器、被設計為執(zhí)行這里描述的功能的電子單元中的至少一種來實施，在一些情況下，這樣的實施方式可以在控制器180中實施。對于軟件實施，諸如過程或功能的實施方式可以與允許執(zhí)行至少一種功能或操作的單獨的軟件模塊來實施。軟件代碼可以由以任何適當的編程語言編寫的軟件應用程序(或程序)來實施，軟件代碼可以存儲在存儲器160中并且由控制器180執(zhí)行?；谏鲜鲆苿咏K端硬件結構，提出本發(fā)明移動終端的各個實施例。參照圖2，在本發(fā)明移動終端的第一實施例中，該移動終端包括：第一獲取模塊10，用于在啟動待修復應用時，獲取對應待修復應用的補丁包，其中，獲取的補丁包包括唯一可執(zhí)行文件，該唯一可執(zhí)行文件攜帶待修復應用發(fā)生錯誤的類所對應的修復后的正確類；第二獲取模塊20，用于獲取對應待修復應用各可執(zhí)行文件的第一數組，并構造對應前述唯一可執(zhí)行文件的第二數組；修復模塊30，用于將第一數組與第二數組合并為一個數組，并將唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，以供加載。為便于理解本發(fā)明方案，以下首先結合附圖對本發(fā)明采用的multidex分包技術進行簡要說明。在安卓系統(tǒng)中，可執(zhí)行文件都存儲在dex文件中，而dex文件的方法數量是有限制的，即一個單一的dex文件的方法總數最多為65536。為了應對該問題，谷歌發(fā)布了multidex分包技術來解決該問題。簡單來說，multidex分包技術就是將類文件打包成多個dex文件，以繞過dex方法數量的限制以及安裝時的檢查，然后在運行時再動態(tài)加載其它的dex文件(注：安卓系統(tǒng)版本5.0之后，系統(tǒng)在安裝應用時會掃描和優(yōu)化應用包中所有的dex文件)，如圖3所示?？梢钥闯觯琺ultidex分包實際上就是把多個dex文件(即安卓系統(tǒng)的可執(zhí)行文件，等同于windows系統(tǒng)的exe文件)加載到應用的類加載器中?；趍ultidex分包技術，提出本發(fā)明移動終端的應用熱修復方案，該方案支持類方法、變量的改變，適用于緊急情況下的應急措施，能夠實現無需升級應用而快速修復應用問題的功能。在本實施例中，預先在應用中埋設修復邏輯，當應用運行錯誤且需要修復時，若修復問題的代碼量很少(可設置門限值進行判決，具體取值本發(fā)明不做限制)并且符合熱修復的約束條件時，預埋的修復邏輯將啟動，對待修復應用進行熱修復。其中，熱修復的約束條件包括：(1)移動終端的系統(tǒng)需為安卓系統(tǒng)；(2)適用已有正式版本的安卓系統(tǒng)，對未來的系統(tǒng)版本需要重新適配；(3)對某些高度定制的移動終端可能存在適配問題，從而影響修復成功率；參照圖4，首先，假設某應用的b.class(錯誤類)有問題，將該應用作為待修復應用，并對b.class進行修復后，得到正確類b’.class，我們將b’.class單獨打包為一個獨立的可執(zhí)行文件(即圖示patch.dex文件)，得到補丁包，以供移動終端在進行熱修復時進行獲取。第一獲取模塊10實時對移動終端的應用運行狀態(tài)進行偵測，當移動終端啟動待修復應用時，獲取到對應待修復應用的補丁包。其中，獲取到的補丁包包括唯一可執(zhí)行文件，該唯一可執(zhí)行文件攜帶待修復應用發(fā)生錯誤的類所對應的修復后的正確類。其中，補丁包可從移動終端本地獲取也可從云端服務器實時獲取，本發(fā)明不做具體限制。如圖5所示，在第一獲取模塊10獲取到補丁包之后，第二獲取模塊20通過當前的類加載器pathclassloader(路徑類加載器，安卓系統(tǒng)的默認類加載器)獲取待修復應用各可執(zhí)行文件的第一數組，即當前dexpathlist(dex路徑列表)下的dexelements(dex元素)數組110，可以看出，該第一數組包括兩個元素：classes.dex和classes2.dex。具體的代碼實現如下所示：如圖6所示，第二獲取模塊20進一步構造對應前述唯一可執(zhí)行文件(patch.dex)的第二數組，具體的：第二獲取模塊20新建類加載器dexclassloader加載補丁包中的唯一可執(zhí)行文件(patch.dex)，首先，獲取patch.dex的路徑，具體的代碼實現如下(假設第一獲取模塊10將獲取的補丁包存儲在移動終端的sd卡上)：stringpatchpath＝environment.getexternalstoragedirectory().getabsolutepath()+"/patch.dex"；dexclassloaderdexclassloader＝newdexclassloader(patchpath,defaultdexoptpath,patchpath,getpathclassloader())；然后，加載patch.dex，構建第二數組，具體的代碼實現如下：objectnewdexelements＝getdexelements(getpathlist(dexclassloader))；如圖6所示，構建的第二數組即新的dex路徑列表下的dex元素數組120，可以看出，該第二數組僅包括一個元素，即patch.dex。在第二獲取模塊20獲取得到第一數組(圖5所示的原dex元素數組110)以及第二數組(圖6所示的新的dex元素數組120)之后，由修復模塊30作進一步處理。具體的，如圖7所示，修復模塊30通過反射機制實現第一數組和第二數組的合并，得到合并后的dex元素數組130，并將前述唯一可執(zhí)行文件patch.dex作為合并后的dex元素數組130的第一個可執(zhí)行文件，可以看出，合并后的dex元素數組130包括三個元素：分別為排列數組首位的patch.dex，以及排列靠后的classes.dex和classes2.dex。具體的代碼實現如下所示：objectpathlist＝getpathlist(getpathclassloader())；reflectionutils.setfield(pathlist,pathlist.getclass(),"dexelements",alldexelements)；結合參照圖8，對本發(fā)明的類替換原理進行說明：如圖8所示，在修復前加載類文件時，會遍歷修復前的dex元素數組210，得到原可執(zhí)行文件2101(即圖示原.dex)，根據類名獲取到原類(原.class)，即錯誤類；在修復后加載類文件時，遍歷修復后的dex元素數組220，將首先得到補丁包中的可執(zhí)行文件2201(即圖示patch.dex)，再根據類名獲取到正確類(正確.class)，而不會去加載錯誤的原可執(zhí)行文件2101。以錯誤類b.class和修復后的正確類b’.class為例，由于原可執(zhí)行文件classes.dex與補丁包中的可執(zhí)行文件patch.dex中都有同樣的b.class類，而通過替換，將patch.dex中的b’.class放到了數組的前面，在加載時會首先會找到b’.class進行加載，從而實現了對錯誤類b.class的熱修復。本發(fā)明提出的移動終端，通過在啟動待修復應用時，獲取到對應待修復應用的補丁包，進而構造與補丁包攜帶唯一可執(zhí)行文件對應的第二數組，并將該第二數組與對應待修復應用各可執(zhí)行文件的第一數組合并為一個數組，將前述唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，從而在加載類文件時，首先加載前述唯一可執(zhí)行文件攜帶的待修復應用發(fā)生錯誤的類所對應的修復后的正確類，而不加載錯誤類，避免了現有技術在應用運行錯誤時需要按照新版本的應用才能修復錯誤，又不會中斷用戶使用應用，實現了應用的高效修復。進一步地，為了確保補丁包的有效性，提出了本發(fā)明移動終端的第二實施例，與前述第一實施例的區(qū)別在于，在本實施例中，移動終端還包括校驗模塊，用于對獲取的補丁包進行安全校驗；第二獲取模塊20還用于在安全校驗通過后，獲取對應待修復應用各可執(zhí)行文件的第一數組，并構造對應前述唯一可執(zhí)行文件的第二數組。需要說明的是，以下僅對校驗模塊的校驗操作進行說明，其他可參照前述第一實施例，此處不再贅述。在本實施例中，在第一獲取模塊10獲取到補丁包之后，首先由校驗模塊對獲取的補丁包進行安全校驗，以確定補丁包在傳輸過程中未被篡改也未被偽造，從而確保補丁包的有效性。在第一獲取模塊10獲取的補丁包通過安全校驗之后，校驗模塊指示第二獲取模塊20作進一步處理，具體可參照前述第一實施例，此處不再贅述。進一步地，在本實施例中，校驗模塊還用于采用約定的消息摘要算法計算前述唯一可執(zhí)行文件的消息摘要；還用于將計算得到的消息摘要與補丁包攜帶的消息摘要進行比對，其中，在二者比對一致時，確定補丁包通過安全校驗。需要說明的是，考慮到消息摘要算法不存在密鑰的管理與分發(fā)問題，適合于分布式網絡上使用的特點，在本實施例中采用消息摘要算法確保補丁包的有效性。具體的，由補丁包發(fā)布方與補丁包獲取方預先約定采用的具體消息摘要算法，如md5算法和sha-1算法等。在補丁包發(fā)布方發(fā)布補丁包時，采用約定的消息摘要算法進行消息摘要的計算，并將計算的消息摘要與攜帶修復后的正確類的可執(zhí)行文件打包為補丁包進行發(fā)布。校驗模塊在第一獲取模塊10獲取到補丁包之后，采用約定的消息摘要算法計算前述唯一可執(zhí)行文件的消息摘要，并將計算得到的消息摘要與補丁包攜帶的消息摘要進行比對，若二者比對一致，則可確定補丁包中的可執(zhí)行文件未被篡改，也未被偽造，確定第一獲取模塊10獲取的補丁包通過安全校驗，是有效的補丁包。進一步地，基于前述第一或第二實施例，提出本發(fā)明移動終端的第三實施例，本實施例中，第一獲取模塊10還用于發(fā)送補丁包獲取請求至預設服務器，該補丁包獲取請求包括待修復應用的版本信息以及已安裝補丁包的版本信息；還用于接收預設服務器基于補丁包獲取請求返回的對應待修復應用的最新版本的補丁包。需要說明的是，本實施例在前述實施例的基礎上，進一步對第一獲取模塊10獲取補丁包的操作進行描述，其他可參照前述實施例，此處不再贅述。參照圖9，本發(fā)明移動終端100的功能實現需要由預設服務器200配合實現，其中，移動終端100負責補丁包的下載、更新本地補丁包，應用補丁包熱修復待修復應用；預設服務器端需要對補丁包進行管理與分發(fā)。具體的，第一獲取模塊10在偵測到移動終端100啟動待修復應用時，會向預設服務器200查詢是否有存在對應待修復應用的補丁包，如果存在則下載。具體的，第一獲取模塊10發(fā)送補丁包獲取請求至預設服務器200，向預設服務器200請求對應待修復應用的最新補丁包，其中，補丁包獲取請求包括待修復應用的版本信息以及已安裝補丁包的版本信息，具體數據定義如下表1所示：字段名必選數據類型描述appversionname是stringandroidmanifest中的版本名稱appversioncode是stringandroidmanifest中的版本號patchversionname是string補丁包的版本名稱patchversioncode是string補丁包的版本號packagename是string待修復應用的包名表1在接收到第一獲取模塊10發(fā)送的補丁包獲取請求之后，預設服務器200基于接收的補丁包獲取請求向第一獲取模塊10返回對應待修復應用的最新版本的補丁包。進一步地，為確保預設服務器200分發(fā)補丁包的時效性，在本實施例中，修復模塊30還用于在偵測到待修復應用運行錯誤時，確定待修復應用發(fā)生錯誤的類；還用于將確定的類信息上傳至預設服務器200，以供其他終端300在基于前述類信息修復發(fā)生錯誤的類之后，將修復后的正確類打包為可執(zhí)行文件，并生成對應的補丁包上傳至預設服務器200。其中，其他終端在生成補丁包時，可通過差分工具來生成，具體可參照現有安卓系統(tǒng)的ota技術實現，此處不再贅述。進一步的，本發(fā)明還提供一種應用修復方法，由圖2所示的移動終端執(zhí)行，結合參照圖2和圖10，對應于本發(fā)明移動終端的第一實施例，在本發(fā)明應用修復方法的第一實施例中，該應用修復方法包括：步驟s10，在啟動待修復應用時，獲取對應待修復應用的補丁包，其中，獲取的補丁包包括唯一可執(zhí)行文件，該唯一可執(zhí)行文件攜帶待修復應用發(fā)生錯誤的類所對應的修復后的正確類；步驟s20，獲取對應待修復應用各可執(zhí)行文件的第一數組，并構造對應前述唯一可執(zhí)行文件的第二數組；步驟s30，將第一數組與第二數組合并為一個數組，并將唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，以供加載。為便于理解本發(fā)明方案，以下首先結合附圖對本發(fā)明采用的multidex分包技術進行簡要說明。在安卓系統(tǒng)中，可執(zhí)行文件都存儲在dex文件中，而dex文件的方法數量是有限制的，即一個單一的dex文件的方法總數最多為65536。為了應對該問題，谷歌發(fā)布了multidex分包技術來解決該問題。簡單來說，multidex分包技術就是將類文件打包成多個dex文件，以繞過dex方法數量的限制以及安裝時的檢查，然后在運行時再動態(tài)加載其它的dex文件(注：安卓系統(tǒng)版本5.0之后，系統(tǒng)在安裝應用時會掃描和優(yōu)化應用包中所有的dex文件)，如圖3所示?？梢钥闯?，multidex分包實際上就是把多個dex文件(即安卓系統(tǒng)的可執(zhí)行文件，等同于windows系統(tǒng)的exe文件)加載到應用的類加載器中?；趍ultidex分包技術，提出本發(fā)明移動終端的應用熱修復方案，該方案支持類方法、變量的改變，適用于緊急情況下的應急措施，能夠實現無需升級應用而快速修復應用問題的功能。在本實施例中，預先在應用中埋設修復邏輯，當應用運行錯誤且需要修復時，若修復問題的代碼量很少(可設置門限值進行判決，具體取值本發(fā)明不做限制)并且符合熱修復的約束條件時，預埋的修復邏輯將啟動，對待修復應用進行熱修復。其中，熱修復的約束條件包括：(3)移動終端的系統(tǒng)需為安卓系統(tǒng)；(4)適用已有正式版本的安卓系統(tǒng)，對未來的系統(tǒng)版本需要重新適配；(3)對某些高度定制的移動終端可能存在適配問題，從而影響修復成功率；參照圖4，首先，假設某應用的b.class(錯誤類)有問題，將該應用作為待修復應用，并對b.class進行修復后，得到正確類b’.class，我們將b’.class單獨打包為一個獨立的可執(zhí)行文件(即圖示patch.dex文件)，得到補丁包，以供移動終端在進行熱修復時進行獲取。第一獲取模塊10實時對移動終端的應用運行狀態(tài)進行偵測，當移動終端啟動待修復應用時，獲取到對應待修復應用的補丁包。其中，獲取到的補丁包包括唯一可執(zhí)行文件，該唯一可執(zhí)行文件攜帶待修復應用發(fā)生錯誤的類所對應的修復后的正確類。其中，補丁包可從移動終端本地獲取也可從云端服務器實時獲取，本發(fā)明不做具體限制。如圖5所示，在第一獲取模塊10獲取到補丁包之后，第二獲取模塊20通過當前的類加載器pathclassloader(路徑類加載器，安卓系統(tǒng)的默認類加載器)獲取待修復應用各可執(zhí)行文件的第一數組，即當前dexpathlist(dex路徑列表)下的dexelements(dex元素)數組110，可以看出，該第一數組包括兩個元素：classes.dex和classes2.dex。具體的代碼實現如下所示：如圖6所示，第二獲取模塊20進一步構造對應前述唯一可執(zhí)行文件(patch.dex)的第二數組，具體的：第二獲取模塊20新建類加載器dexclassloader加載補丁包中的唯一可執(zhí)行文件(patch.dex)，首先，獲取patch.dex的路徑，具體的代碼實現如下(假設第一獲取模塊10將獲取的補丁包存儲在移動終端的sd卡上)：stringpatchpath＝environment.getexternalstoragedirectory().getabsolutepath()+"/patch.dex"；dexclassloaderdexclassloader＝newdexclassloader(patchpath,defaultdexoptpath,patchpath,getpathclassloader())；然后，加載patch.dex，構建第二數組(即圖6所示新的dexelements數組)，具體的代碼實現如下：objectnewdexelements＝getdexelements(getpathlist(dexclassloader))；如圖6所示，構建的第二數組即新的dex路徑列表下的dex元素數組120，可以看出，該第二數組僅包括一個元素，即patch.dex。在第二獲取模塊20獲取得到第一數組(圖5所示的原dex元素數組110)以及第二數組(圖6所示的新的dex元素數組120)之后，由修復模塊30作進一步處理。具體的，如圖7所示，修復模塊30通過反射機制實現第一數組和第二數組的合并，得到合并后的dex元素數組130，并將前述唯一可執(zhí)行文件patch.dex作為合并后的dex元素數組130的第一個可執(zhí)行文件，可以看出，合并后的dex元素數組130包括三個元素：分別為排列數組首位的patch.dex，以及排列靠后的classes.dex和classes2.dex。具體的代碼實現如下所示：objectpathlist＝getpathlist(getpathclassloader())；reflectionutils.setfield(pathlist,pathlist.getclass(),"dexelements",alldexelements)；結合參照圖8，對本發(fā)明的類替換原理進行說明：如圖8所示，在修復前加載類文件時，會遍歷修復前的dex元素數組210，得到原可執(zhí)行文件2101(即圖示原.dex)，根據類名獲取到原類(原.class)，即錯誤類；在修復后加載類文件時，遍歷修復后的dex元素數組220，將首先得到補丁包中的可執(zhí)行文件2201(即圖示patch.dex)，再根據類名獲取到正確類(正確.class)，而不會去加載錯誤的原可執(zhí)行文件2101。以錯誤類b.class和修復后的正確類b’.class為例，由于原可執(zhí)行文件classes.dex與補丁包中的可執(zhí)行文件patch.dex中都有同樣的b.class類，而通過替換，將patch.dex中的b’.class放到了數組的前面，在加載時會首先會找到b’.class進行加載，從而實現了對錯誤類b.class的熱修復。本發(fā)明提出的應用修復方法，通過在啟動待修復應用時，獲取到對應待修復應用的補丁包，進而構造與補丁包攜帶唯一可執(zhí)行文件對應的第二數組，并將該第二數組與對應待修復應用各可執(zhí)行文件的第一數組合并為一個數組，將前述唯一可執(zhí)行文件作為合并后數組的第一個可執(zhí)行文件，從而在加載類文件時，首先加載前述唯一可執(zhí)行文件攜帶的待修復應用發(fā)生錯誤的類所對應的修復后的正確類，而不加載錯誤類，避免了現有技術在應用運行錯誤時需要按照新版本的應用才能修復錯誤，又不會中斷用戶使用應用，實現了應用的高效修復。進一步地，為了確保補丁包的有效性，基于第一實施例，提出了本發(fā)明應用修復方法的第二實施例，對應于前述應用修復方法的第二實施例，在本實施例中，步驟s20之前，還包括：對獲取的補丁包進行安全校驗；在安全校驗通過后，轉入執(zhí)行步驟s20。需要說明的是，以下僅對補丁包的安全校驗操作進行說明，其他可參照前述第一實施例，此處不再贅述。在本實施例中，移動終端還包括校驗模塊，用于對獲取的補丁包進行安全校驗；第二獲取模塊20還用于在安全校驗通過后，獲取對應待修復應用各可執(zhí)行文件的第一數組，并構造對應前述唯一可執(zhí)行文件的第二數組。具體的，在第一獲取模塊10獲取到補丁包之后，首先由校驗模塊對獲取的補丁包進行安全校驗，以確定補丁包在傳輸過程中未被篡改也未被偽造，從而確保補丁包的有效性。在第一獲取模塊10獲取的補丁包通過安全校驗之后，校驗模塊指示第二獲取模塊20作進一步處理，具體可參照前述第一實施例，此處不再贅述。進一步地，步驟s20包括：采用約定的消息摘要算法計算前述唯一可執(zhí)行文件的消息摘要；將計算得到的消息摘要與補丁包攜帶的消息摘要進行比對，其中，在二者比對一致時，確定補丁包通過安全校驗。在本實施例中，校驗模塊還用于采用約定的消息摘要算法計算前述唯一可執(zhí)行文件的消息摘要；還用于將計算得到的消息摘要與補丁包攜帶的消息摘要進行比對，其中，在二者比對一致時，確定補丁包通過安全校驗。需要說明的是，考慮到消息摘要算法不存在密鑰的管理與分發(fā)問題，適合于分布式網絡上使用的特點，在本實施例中采用消息摘要算法確保補丁包的有效性。具體的，由補丁包發(fā)布方與補丁包獲取方預先約定采用的具體消息摘要算法，如md5算法和sha-1算法等。在補丁包發(fā)布方發(fā)布補丁包時，采用約定的消息摘要算法進行消息摘要的計算，并將計算的消息摘要與攜帶修復后的正確類的可執(zhí)行文件打包為補丁包進行發(fā)布。校驗模塊在第一獲取模塊10獲取到補丁包之后，采用約定的消息摘要算法計算前述唯一可執(zhí)行文件的消息摘要，并將計算得到的消息摘要與補丁包攜帶的消息摘要進行比對，若二者比對一致，則可確定補丁包中的可執(zhí)行文件未被篡改，也未被偽造，確定第一獲取模塊10獲取的補丁包通過安全校驗，是有效的補丁包。進一步地，基于前述第一或第二實施例，提出本發(fā)明應用修復方法的第三實施例，對應于前述移動終端的第三實施例，在本實施例中，步驟s10包括：發(fā)送補丁包獲取請求至預設服務器，該補丁包獲取請求包括待修復應用的版本信息以及已安裝補丁包的版本信息；接收預設服務器基于補丁包獲取請求返回的對應待修復應用的最新版本的補丁包。需要說明的是，本實施例在前述實施例的基礎上，進一步對獲取補丁包的操作進行描述，其他可參照前述實施例，此處不再贅述。參照圖9，本發(fā)明移動終端100的功能實現需要由預設服務器200配合實現，其中，移動終端100負責補丁包的下載、更新本地補丁包，應用補丁包熱修復待修復應用；預設服務器端需要對補丁包進行管理與分發(fā)。具體的，第一獲取模塊10在偵測到移動終端100啟動待修復應用時，會向預設服務器200查詢是否有存在對應待修復應用的補丁包，如果存在則下載。具體的，第一獲取模塊10發(fā)送補丁包獲取請求至預設服務器200，向預設服務器200請求對應待修復應用的最新補丁包，其中，補丁包獲取請求包括待修復應用的版本信息以及已安裝補丁包的版本信息，具體數據定義如表1所示。在接收到第一獲取模塊10發(fā)送的補丁包獲取請求之后，預設服務器200基于接收的補丁包獲取請求向第一獲取模塊10返回對應待修復應用的最新版本的補丁包。進一步地，為確保預設服務器200分發(fā)補丁包的時效性，在本實施例中，步驟s10之前，還包括：在偵測到待修復應用運行錯誤時，確定待修復應用發(fā)生錯誤的類；將確定的類信息上傳至預設服務器200，以供其他終端300在基于前述類信息修復發(fā)生錯誤的類之后，將修復后的正確類打包為可執(zhí)行文件，并生成對應的補丁包上傳至預設服務器200。在本實施例中，修復模塊30還用于在偵測到待修復應用運行錯誤時，確定待修復應用發(fā)生錯誤的類；還用于將確定的類信息上傳至預設服務器200，以供其他終端300在基于前述類信息修復發(fā)生錯誤的類之后，將修復后的正確類打包為可執(zhí)行文件，并生成對應的補丁包上傳至預設服務器200。其中，其他終端在生成補丁包時，可通過差分工具來生成，具體可參照現有安卓系統(tǒng)的ota技術實現，此處不再贅述。需要說明的是，在本文中，術語“包括”、“包含”或者其任何其它變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其它要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件平臺的方式來實現，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發(fā)明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質(如rom/ram、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器，空調器，或者網絡設備等)執(zhí)行本發(fā)明各個實施例所述的方法。出于解釋的目的，前面的描述使用了特定的術語，以提供對本發(fā)明的透徹理解。然而，對本領域的技術人員來說顯而易見的是，為了實踐本發(fā)明并不需要具體的細節(jié)。本發(fā)明的具體實施例的前述描述是為了圖示和說明的目的而呈現。它們并不意在詳盡的或將本發(fā)明限于所公開的準確形式。鑒于上面的教義，許多修改和變化是可能的。為了最好地解釋本發(fā)明的原理及其實際應用而示出并描述了這些實施例，從而使本領域的其他技術人員能夠最好地利用本發(fā)明和具有適于預期的特定使用的各種修改的各種實施例。意在本發(fā)明的范圍由隨后的權利要求和其等同物來限定。當前第1頁12