應于一個活動組件(Activity)，具體視分包技術的需要而定。由此，軟件的升級包可以是針對每個分包進行設計，精確對應到軟件的功能模塊或者對應到具體組件。安裝包與升級包內部，均以文件的形式存在，因此，本質上，升級包僅包含用于局部替換安裝包中的一部分文件的相對應替換文件。當然，一個升級包中也可以包含多個所述的子包，視導致軟件問題的子包數量而定。確定一個軟件問題后，存儲軟件升級包的遠程服務器，可以根據軟件問題而提供一個精確對應的升級包進行推送，終端由此接收到的升級包便是輕量型的，可以大大節約網絡帶寬和提高升級效率。
[0118]步驟S16，以所述升級包的文件替換該軟件的安裝包中相對應的文件，完成該軟件的升級。
[0119]完成所述的軟件升級包下載后，以分包技術相應的安裝技術，安裝所述的升級包，使得軟件安裝包中的部分涉及升級所需的文件被升級包中的相應文件所替換。具體而言，如Andro id的APK格式安裝包，其中的代碼文件cl asses.dex被分包為classes.dex_l,
classes.dex_2......此外還包括配置文件Androidmanifest.1ni，而升級包中包含了
classes.dex_l與Androidmanifest.1ni，則可以將這兩個文件與安裝包所包含的文件進行替換并重新簽名，最終完成該安裝包的重新打包和安裝。
[0120]進而，基于軟件的模塊化思維，本發明對應上述各種方法提供若干種裝置如下:
[0121]請參閱圖5，本發明提供的一種軟件維護裝置，其包括獲取單元11、統計單元12以及判定單元13，各單元所實現的功能概述如下:
[0122]所述的獲取單元11，用于獲取本軟件的進程響應于不同事件行為產生的多種問題類型的日志數據。
[0123]軟件在開發時，可以植入產生日志數據的代碼，或者，軟件運行時，可以由操作系統監控軟件的運行而產生對應于該軟件運行過程所進行的操作而產生日志數據，無論何種方式產生日志數據，均與該軟件在運行時的進程相關聯。并且，以面向對象的設計原則中，這些日志數據通常是對應于不同事件行為而產生的。而且，軟件的一種事件行為可能對應一種或多種問題類型，因此而產生一個或多個日志數據；同一份日志數據也可能對應于一個或多個事件行為而產生，而一份日志文件則通常表征一種問題類型。事件行為與問題類型、日志數據之間的對應關系，視彼此的公知的事實關系而定，為本領域技術人員所當然理解。所述的事件行為，可能是軟件進程的生命周期內因為執行指令而觸發的，也可能是受用戶的操作而觸發的。通常，以Android系統下的軟件為例，一個軟件包括多個功能模塊，如Activity組件，一個Activity組件用于展示一個用戶界面，其背后是相應的各類函數。該用戶界面可以響應于用戶操作而產生事件行為，其函數在運行時執行諸如調用接口函數或者各類資源時，也可產生所述的事件行為。本領域技術人員對此原理應當能予以理解，恕不贅述。
[0124]如前所述，所述日志數據的產生需要預先設置打點功能。一種方式中，所述日志數據具體依據針對該軟件的不同功能頁面相對應的功能模塊的用戶操作事件行為進行打點產生。例如在上述的一個Activity組件的點擊事件函數中寫入實現日志數據打點的代碼，在運行時，便可響應于對該用戶界面的點擊事件而產生一個預設了相對應的日志數據。另一種方式中，上述用于實現打點的代碼預置于某些并非由系統定義的函數中，由技術人員靈活確定，使得所述日志數據具體依據針對該軟件的不同功能頁面相對應的功能模塊的運行過程事件行為進行打點產生。例如，在一個后臺功能模塊中，當運行到特點指令之后即執行一次打點，產生相應的日志數據，起到類似于軟件調試中的預設調試點的效果。
[0125]對所述問題類型的分類，可以依照一定的原則，由本領域技術人員靈活確定。例如，所述日志數據按照屬于其所屬的宿主模塊的事實屬性進行歸類，由此，用于實現同一應用功能的若干個組件可以預置相同的打點代碼，使得作用于該應用功能不同組件的操作事件可以產生相同的問題類型的日志數據，有利于通過多個相關組件確定某一應用功能是否存在某種問題，典型地如獲知該應用功能的使用頻度。又如，所述日志數據按照不同的事件行為進行歸類，在不同的組件的相同事件行為中植入所述的同一打點代碼，同理可以將問題類型與事件行為建立起對應性。本領域技術人員參照此處的揭示，足以知曉本獲取單元11的具體實現。
[0126]所述的統計單元12，依據預設規則處理所述日志數據，使所述日志數據經數學統計獲得相應的結果數據。
[0127]所述的日志數據，在計算機存儲時，首先是以日志記錄的方式存在的，可以存儲于系統的日志數據庫中，也可以存儲于軟件自行預置的日志文件中。通過對相應的數據庫或文件的讀取，可以獲得包括問題類型與記錄條數之類的日志數據。
[0128]本發明主要采用統計學上公知的卡方檢驗法對所述的日志數據進行數學處理，可以采用至少兩種實施方式來實現本統計單元12，一種是通過遠程服務器來實現，另一種則可在終端本機上執行實現。兩種方式的原理相同，只是數據分布關系不同，也即視后述的用于進行統計決策的大數據特別是理論頻數是存在于本機中還是存在于遠程服務器而決定執行卡方檢測法所在的空間位置。
[0129]對于前述的第一種方式，終端本機可以先行確定各問題類型日志數據的實際頻數，利用這些信息打包成請求判定軟件問題的用戶請求，提交到遠程服務器做統計學分析。
[0130]為此而引入揭示本發明的一種軟件問題判定裝置，以便實現所述的卡方檢驗法，具體對應于前述的第一種方式。如圖6所示，該裝置包括請求接收單元21、遠程統計單元22以及遠程判定單元23，各單元所實現的具體功能揭示如下:
[0131 ]所述的請求接收單元21，接收請求判定軟件問題的用戶請求，從中解析出針對特定軟件所產生日志數據而統計得出的若干問題類型日志數據的實際頻數。
[0132]所述的用戶請求被遠程服務器接收后，遠程服務器可以對應從中解析其中的實際頻數信息，這些信息是對應于終端的特定軟件的多個問題類型而統計得出的，因此具有針對性。對這些實際頻數加以卡方檢驗，得出的結果數據自然是對應于所述特定軟件的。
[0133]所述的遠程統計單元22，用于依據預設規則，從預設數據庫的數據中確定屬于該軟件的理論頻數，利用所述理論頻數和實際頻數，以卡方檢驗法計算得出該些問題類型的實際頻數對應的卡方值。
[0134]所述的預設規則，便是依照卡方檢驗法所靈活確定的算法。所述預設數據庫中，包括有依據所述軟件的若干歷史版本在運行時產生的日志數據以卡方檢驗法統計而得的所述理論頻數及相應的卡方值，以此作判定該軟件是否存在該些類型相對應的問題時的預定閾值的比較基準。所述預設數據庫中包括有不同卡方值范圍與軟件問題具體性質之間對應關系的數據記錄，其中的卡方值范圍限定所述的預定閾值，通過查找該些數據記錄確定相應的軟件問題。應當注意的是，軟件問題未必同于與日志數據相對應的所述問題類型，軟件問題可以是程序員預先歸類劃分的各種不同性質的內容，當然也可以與所述問題類型存在邏輯上的關聯性甚至具有相同的表述，但彼此不應混為一談，軟件問題表現在數據記錄上是獨立于所述的問題類型的。較佳的，所述軟件問題至少包括如下兩種定義任意之一:其一用于表征功能模塊的使用率降低;其二用于表征功能模塊的故障率提高。
[0135]所述諸多問題類型的實際頻數對應的卡方值的具體計算方式，在于依據該些實際頻數與所述理論頻數的差值平方與所述理論頻數之比的累計之和而確定。此一計算方式為卡方檢驗法的基本原理，實踐中，可以靈活變通，對其中所用的參數、變量進行靈活設置。由此可見，遠程服務器可以依據用戶請求所包含的實際頻數，結合采集和加工的大數據并以此確定的理論頻數，將所述的實際頻數轉換為卡方值。
[0136]所述的遠程判定單元23，用于在所述卡方值與預定閾值不符時，判定該軟件存在該些類型相對應的問題，并反饋相對應的結果數據。
[0137]如前所述，所述的預定閾值由所述預設數據庫的大數據，也即預先從各終端采集的數據，計算出其正常的卡方值來確定，可以是一個具體的數值，也可以是一個數值范圍，以此來框限依據實際頻數所計算得出的卡方值所對應的軟件問題。由此，利用依據實際頻數計算得出的卡方值，便可在該數據庫中查找出相對應的軟件問題，這些軟件問題對應于終端上產生的某些問題類型，遠程服務器將這個軟件問題的說明打包成結果數據，發送給終端，終端便可以據以進行后續處理。
[0138]以上的有關在遠程服務器中實現卡方檢驗法的第一種方式，充分揭示了卡方檢驗法在本發明中的結合實現方式。而對于主要在終端本機中實現的第二種方式，主要也同于第一種方式，其異同之處說明如下:
[0139]終端本機中實現所述預設規則，同理按照卡方檢驗法設置。如圖7所示，所述的大數據預存儲在終端本機中，同理也已利用這些大數據確定了卡方檢驗法所需的理論頻數，終端需要進行卡方檢驗時，即利用本機各類型日志數據確定相應的實際頻數，這部分功能由終端的統計單元12中構造的頻數確定模塊實現121;繼而，終端借助其統計單元12構造的卡方值確定模塊122，利用各類型實際頻數分別與理論頻數差值平方與理論頻數之比的累計之和，確定實