本發(fā)明涉及Android系統(tǒng)領(lǐng)域，具體涉及一種Activity組件加載方法及裝置。

背景技術(shù)：

Android系統(tǒng)是一種基于Linux的自由及開放源代碼的操作系統(tǒng)，目前被廣泛應(yīng)用于智能終端(例如智能手機、平板電腦和智能電視等)中。

Activity組件是Android系統(tǒng)的四大組件之一，而程序的Activity組件需要在該程序的AndroidManifest.xml文件中進行注冊，并且，程序開發(fā)的Activity組件的名稱需要與該程序的AndroidManifest.xml文件中指定的類名相同。

目前，通過基于dalvik.system.DexClassLoader加載.dex文件的方式可以改變程序的代碼邏輯，達到不安裝新的程序安裝包就可升級該程序的目的。然而，上述方式存在一定的局限性，由于程序開發(fā)的Activity組件需要和該程序的AndroidManifest.xml文件中指定的類名相同，并且由于AndroidManifest.xml文件為固有屬性，無法在程序運行時改變，因此，通過上述方式無法在程序運行時動態(tài)加載程序的Activity組件。

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

本發(fā)明提供一種Activity組件加載方法及裝置，使得Activity組件的動態(tài)加載成為可能。

本發(fā)明第一方面提供一種Activity組件加載方法，應(yīng)用于Android系統(tǒng)，該Activity組件加載方法，包括：

獲取預(yù)先嵌入Android系統(tǒng)的開放服務(wù)網(wǎng)關(guān)協(xié)議框架的BundleContext；

確定待啟動的Activity組件；

獲取與所述待啟動的Activity組件關(guān)聯(lián)的bundle標識符；

根據(jù)當前獲取的bundle標識符，調(diào)用所述BundleContext的BundleContext.start方法啟動相應(yīng)的bundle文件，以便加載相應(yīng)的Activity組件，其中，所述bundle文件由jar文件轉(zhuǎn)化而成，所述jar文件由所述Activity組件的源代碼編譯而成。

本發(fā)明第二方面提供一種Activity組件加載裝置，應(yīng)用于Android系統(tǒng)，該Activity組件加載裝置包括：

第一獲取單元，用于獲取預(yù)先嵌入Android系統(tǒng)的開放服務(wù)網(wǎng)關(guān)協(xié)議框架的BundleContext；

確定單元，用于確定待啟動的Activity組件；

第二獲取單元，用于獲取與所述待啟動的Activity組件關(guān)聯(lián)的bundle標識符；

啟動單元，用于根據(jù)當前所述第二獲取單元獲取的bundle標識符，調(diào)用所述BundleContext的BundleContext.start方法啟動相應(yīng)的bundle文件，以便加載相應(yīng)的Activity組件，其中，所述bundle文件由jar文件轉(zhuǎn)化而成，所述jar文件由所述Activity組件的源代碼編譯而成。

由上可見，本發(fā)明中將由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，并且，在Android系統(tǒng)中嵌入開放服務(wù)網(wǎng)關(guān)框架(OSGI，Open Service Gateway Initiative)，借助該OSGI框架實現(xiàn)了bundle文件的運行，進而實現(xiàn)了相應(yīng)Activity組件的加載。由于本發(fā)明中Activity組件的加載是通過啟動相應(yīng)的bundle文件來實現(xiàn)，因此，Activity組件的加載無需受限于AndroidManifest.xml文件，從而使得Activity組件的動態(tài)加載成為可能。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明提供的Activity組件加載方法一個實施例流程示意圖；

圖2為本發(fā)明提供在圖1所示方法基礎(chǔ)上的一種Activity組件動態(tài)更新方法實施例流程示意圖；

圖3為本發(fā)明提供在圖1或圖2所示方法基礎(chǔ)上的一種Activity組件動態(tài)卸載方法實施例流程示意圖；

圖4為本發(fā)明提供的Activity組件加載裝置一個實施例結(jié)構(gòu)示意圖。

具體實施方式

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

本發(fā)明實施例提供一種Activity組件加載方法，請參閱圖1所示，本發(fā)明實施例中的Activity組件加載方法可以包括如下步驟：

步驟101、獲取預(yù)先嵌入Android系統(tǒng)的開放服務(wù)網(wǎng)關(guān)協(xié)議框架的BundleContext；

本發(fā)明實施例中，開放服務(wù)網(wǎng)關(guān)協(xié)議框架也即OSGI框架，是實現(xiàn)并提供OSGI功能的運行環(huán)境。OSGI框架在創(chuàng)建基于OSGI的應(yīng)用時起著核心作用，因為它是應(yīng)用的執(zhí)行環(huán)境。

OSGI聯(lián)盟在OSGI框架規(guī)范中定義了框架的正確行為，這樣就可以基于一個定義清晰的應(yīng)用程序編程接口(API，Application Programming Interface)進行編程。這個框架是依據(jù)OSGI規(guī)范中定義的三個概念層設(shè)計的：

模塊層：關(guān)注于打包和共享代碼。模塊層定義了OSGI模塊的概念，并將之稱為一個bundle。bundle文件是一個包含元數(shù)據(jù)(關(guān)于數(shù)據(jù)的數(shù)據(jù))的jar文件，由類文件和相關(guān)資源組成。它是構(gòu)成一個特定應(yīng)用程序的多個邏輯模塊。

服務(wù)層：關(guān)注于模塊，特別是模塊內(nèi)的組件間的交互和通信。服務(wù)層支持和促成了一個靈活的應(yīng)用編程模型。主要涉及面向服務(wù)的發(fā)布、查找和綁定交互模式，即服務(wù)提供者將服務(wù)發(fā)布到服務(wù)注冊中心，然后服務(wù)客戶端通過搜索服務(wù)注冊中心，查找可供使用的服務(wù)。

生命周期層：關(guān)注于提供執(zhí)行時模塊管理和對底層OSGI框架的訪問。生命周期層定義了在OSGI框架中是如何動態(tài)安裝和管理來的。生命周期層定義了bundle生命周期的操作(如安裝、更新、啟動、停止和卸載)。這些生命周期的操作使得可以用一種定義明確的方式動態(tài)地提供、管理和改進應(yīng)用程序。

bundle是OSGI中的模塊模型。標準Java平臺的jar包中包含有class文件以及相應(yīng)的資源文件，bundle文件可以簡單地理解為是增加了元數(shù)據(jù)的jar包。一個bundle文件中包含了java類和一些其他的數(shù)據(jù)資源，這些數(shù)據(jù)可以是HTML文件、幫助文檔以及圖標等。每個bundle文件都對應(yīng)一個唯一的并且在生命周期中保持不變的ID號碼，該ID由OSGI框架分配。

為便于描述，將模塊定義為：一個從邏輯上封裝實現(xiàn)類的集合，一個基于實現(xiàn)類子集的可選公共API，以及一個對外部代碼依賴關(guān)系的集合。從用戶層可以把bundle文件理解為一個功能模塊。bundle文件可以從項目中導入導出，并且能夠與項目中的其它bundle共享jar文件。本發(fā)明實施例中可以將bundle文件定義為：一個模塊化的物理單元，以jar文件形式包含代碼、資源和元數(shù)據(jù)，其中jar文件的邊界也作為執(zhí)行時邏輯模塊化的封裝邊界。

BundleContext是指模塊在OSGI框架中運行時的上下文，該上下文提供了模塊與OSGI框架進行交互的方法(即為應(yīng)用提供執(zhí)行時操作OSGI框架的方法)。啟動模塊時，OSGI框架會創(chuàng)建一個對應(yīng)的BundleContext對象，但該對象不能在模塊之間進行傳遞，這是為了保障模塊的安全和資源的正確分配。

本發(fā)明實施例中，預(yù)先在Android系統(tǒng)中嵌入OSGI框架，在步驟101中，獲取該OSGI框架的BundleContext。

可選的，在步驟101之前還包括：通過已啟動的OSGI框架服務(wù)的代理獲取OSGI框架的實例，其中，上述OSGI框架服務(wù)為：預(yù)先基于Framework創(chuàng)建的，用以實現(xiàn)在上述Android系統(tǒng)運行OSGI框架的服務(wù)。本發(fā)明實施例中，可以在上述OSGI框架服務(wù)啟動之后，通過Android系統(tǒng)中的binder機制，向應(yīng)用層提供該OSGI框架服務(wù)的代理，通過該OSGI框架服務(wù)的代理，就可以訪問到該OSGI框架服務(wù)中相關(guān)接口(例如獲取OSGI框架實例接口)。具體地，可通過getFrameworkInstance方法獲取OSGI框架的實例。當然，本發(fā)明實施例中也可以通過其它方式獲取上述OSGI框架的實例，例如，可通過FrameWork Factory.new FrameWork方法獲取上述OSGI框架的實例，并通過Framework.start方法啟動該OSGI框架的實例。步驟101具體表現(xiàn)為：基于獲取的上述OSGI框架的實例，獲取預(yù)先嵌入Android系統(tǒng)的OSGI框架的BundleContext。具體地，可通過調(diào)用Framework.getBundleContext()方法獲取上述OSGI框架的BundleContext。

可選的，將上述OSGI框架服務(wù)添加至上述Android系統(tǒng)的系統(tǒng)服務(wù)中，例如，可通過Android系統(tǒng)中的服務(wù)管理器(即ServiceManager)將該OSGI框架服務(wù)添加進上述Android系統(tǒng)的系統(tǒng)服務(wù)中。這樣，每次系統(tǒng)啟動時該OSGI框架服務(wù)便可隨著系統(tǒng)服務(wù)的啟動而啟動。

步驟102、確定待啟動的Activity組件；

本發(fā)明實施例中，可以在程序啟動或運行的過程中，確定待啟動的Activity組件。

具體地，程序可以在需要調(diào)用某一個或多個Activity組件時，按照預(yù)先定義的接口協(xié)議輸入預(yù)設(shè)的參數(shù)，以便在步驟102中通過輸入的參數(shù)確定待啟動的Activity組件。本發(fā)明實施例中，上述預(yù)先定義的接口協(xié)議中包括輸入部分和輸出部分。上述輸入部分定義了輸入的參數(shù)，比如程序包名、Activity組件名稱。輸出部分定義了被調(diào)用的Activity組件的執(zhí)行結(jié)果的狀態(tài)。為了便于描述，這里舉例說明，假設(shè)某一應(yīng)用程序所要啟動的Activity組件是具備歡迎界面的Activity組件，在調(diào)用該Activity組件時，按照預(yù)先定義的接口協(xié)議輸入該應(yīng)用程序的程序包名和該Activity組件名稱，以便通過該應(yīng)用程序的程序包名和該Activity組件名稱唯一確定當前所要啟動的Activity組件(即確定待啟動的Activity組件)。

步驟103、獲取與上述待啟動的Activity組件關(guān)聯(lián)的bundle標識符；

本發(fā)明實施例中，預(yù)先將程序所需的Activity組件轉(zhuǎn)化為bundle文件(具體轉(zhuǎn)化方式在步驟104中說明)并下載到本地，之后在本地安裝該bundle文件(例如可在獲取上述OSGI框架的BundleContext之后，調(diào)用BundleContext.install方法安裝該bundle文件)。當該bundle文件安裝成功后，可以通過調(diào)用Bundle接口的getBundleId方法來獲取Bundle ID。之后，可通過列表或數(shù)組或其它方式將獲取的Bundle ID與上述Activity組件關(guān)聯(lián)存儲(例如將獲取的Bundle ID與能夠唯一指示該Activity組件的標識(例如Activity組件的名稱)關(guān)聯(lián)存儲)，以便在步驟103中，可以根據(jù)步驟102確定的待啟動的Activity組件，獲取到與該Activity組件關(guān)聯(lián)的Bundle ID。

其中，上述Bundle ID是運行期最常用的標識符，它是由OSGI框架自動分配的一個長整型數(shù)字，在整個生命周期內(nèi)(包括bundle文件的更新、卸載之后)都不會改變，甚至在OSGI框架重啟后都能保留下來。Bundle ID是在bundle文件安裝過程中由OSGI框架根據(jù)bundle文件安裝時間的先后次序，由小到大進行分配的。

進一步，當該bundle文件安裝成功后，還可以調(diào)用Bundle接口的getSymbolicName方法和getVersion分別獲取到該bundle文件的符號名稱和bundle版本號。則還可以通過列表或數(shù)組或其它方式將獲取的Bundle ID、bundle文件的符號名稱和bundle版本號以及上述Activity組件關(guān)聯(lián)存儲，或者，也可以將bundle文件的符號名稱設(shè)定為相應(yīng)Activity組件的名稱，則只需要通過bundle文件的符號名稱即可獲取到與相應(yīng)Activity組件關(guān)聯(lián)的bundle標識符。

步驟104、根據(jù)當前獲取的bundle標識符，調(diào)用上述BundleContext的BundleContext.start方法啟動相應(yīng)的bundle文件，以便加載相應(yīng)的Activity組件；

本發(fā)明實施例中，上述bundle文件由jar文件轉(zhuǎn)化而成，上述jar文件由上述Activity組件的源代碼編譯而成。由于上述bundle文件是由上述Activity組件的源代碼轉(zhuǎn)化而成，因此，通過調(diào)用BundleContext.start方法啟動該bundle文件，即可實現(xiàn)該Activity組件的加載。

以下對生成Activity組件的bundle文件的過程進行說明：

由前述可知，bundle文件是添加了特定元數(shù)據(jù)的jar文件，因此，要將由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，需要為該jar文件增加相應(yīng)的元數(shù)據(jù)，其中，上述元數(shù)據(jù)包括：可讀信息、bundle識別信息和代碼可見性信息。

1、可讀信息：為使用者提供該bundle的相關(guān)幫助信息。例如可包括：

Bundle-Name：作為bundle文件的一個縮寫名；

Bundle-Description：描述bundle文件的功能；

Bundle-DocURL：提供有關(guān)bundle文件的文檔；

Bundle-Category：定義了一組由逗號分隔的分類名；

Bundle-Vendor：有關(guān)bundle提供商的信息；

Bundle-ContactAddress：有關(guān)bundle提供商的信息；

Bundle-Copyright：有關(guān)bundle提供商的信息；

2、bundle文件識別信息：識別bundle文件的必要信息；

安裝到OSGI框架中的每個bundle文件都必須有一個唯一標識，這個標識由bundle文件的符號名稱和bundle版本號兩部分組成。

Bundle-SymbolicName，即bundle文件的符號名稱，它和java中包命名方法一致，可直接采用包名作為符號名稱。本發(fā)明實施例中，可將Activity組件的名稱作為該bundle文件的符號名稱

Bundle-Version，即bundle版本號，OSGI規(guī)范約定的bundle文件的版本號格式為：主版本號.次版本號.微版本號.限定符。

Bundle-ManifestVersion：OSGI框架根據(jù)此元數(shù)據(jù)信息確定采用哪個版本的OSGI規(guī)范來處理bundle文件

3、代碼可見性信息：定義哪些代碼內(nèi)部可見和哪些代碼外部可見的必要信息；

Export-Package：導出內(nèi)部代碼，一個為了與其它bundle文件共享而公開的、由逗號分隔的內(nèi)部bundle包；

Import-Package：導入外部代碼，內(nèi)部bundle代碼需要的、來自其它bundle文件并由逗號分隔的一組包。

具體地，可利用eclipse的BndTools插件、jar命令和bnd工具，在jar文件的META-INF/MANIFEST.MF條目里增加上述元數(shù)據(jù)并轉(zhuǎn)化為bundle文件，其中，上述bnd工具由OSGI技術(shù)負責相關(guān)人員開關(guān)，提供了大量的專門為OSGI設(shè)計的命令行。

需要說明的是，本發(fā)明實施例中的Activity組件加載方法可以由Activity組件加載裝置執(zhí)行，該Activity組件加載裝置可以集成智能終端(例如智能手機、平板電腦和智能電視等)中，此處不作限定。

由上可見，本發(fā)明中的Activity組件加載方法將由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，并且，在Android系統(tǒng)中嵌入OSGI，借助該OSGI框架實現(xiàn)了bundle文件的運行，進而實現(xiàn)了相應(yīng)Activity組件的加載。由于本發(fā)明中Activity組件的加載是通過啟動相應(yīng)的bundle文件來實現(xiàn)，因此，Activity組件的加載無需受限于AndroidManifest.xml文件，從而使得Activity組件的動態(tài)加載成為可能。

在圖1所示實施例的基礎(chǔ)上，本發(fā)明實施例中的Activity組件加載方法還包含Activity組件動態(tài)更新方法，如圖2所示，上述Activity組件動態(tài)更新方法包括：

步驟201、獲取來自服務(wù)器的第一配置文件；

其中，上述第一配置文件包括：bundle符號名稱、版本號和bundle文件下載地址(例如統(tǒng)一資源定位器(URL，Uniform Resoure Locator)地址)。

本發(fā)明實施例中，可以在程序運行或啟動的過程中，通過主動獲取方式或者被動獲取方式獲取來自服務(wù)器的第一配置文件。上述主動獲取方式例如可以為：周期性查詢預(yù)設(shè)的服務(wù)器上是否有新增的第一配置文件，若存在新增的第一配置文件，則下載該新增的第一配置文件。上述被動獲取方式可以由服務(wù)器在有新增的第一配置文件時主動推送該第一配置文件。

步驟202、若本地存在滿足第一條件的配置文件，則：根據(jù)上述第一配置文件中的bundle文件下載地址下載相應(yīng)的bundle文件；

其中，上述第一條件為：配置文件包含的bundle符號名稱與上述第一配置文件包含的bundle符號名稱一致，且，配置文件包含的版本號低于上述第一配置文件包含的版本號。

本發(fā)明實施例中，每個bundle文件可對應(yīng)一配置文件，該配置文件可在bundle文件首次安裝時與該bundle文件關(guān)聯(lián)存儲，或者，也可以在該bundle文件首次啟動時，采用預(yù)先定義的獲取默認配置文件的協(xié)議接口，從服務(wù)器獲取并下載與該bundle文件關(guān)聯(lián)的默認配置文件，之后將下載的默認配置文件與該bundle文件關(guān)聯(lián)存儲。

在步驟202中，對上述第一配置文件進行解析，以檢測本地是否存在包含的bundle符號名稱與步驟201下載的第一配置文件包含的bundle符號名稱一致的配置文件，若存在(為便于描述，后續(xù)將包含的bundle符號名稱與步驟201下載的第一配置文件包含的bundle符號名稱一致的配置文件描述為配置文件A)，進一步檢測配置文件A的版本號是否低于上述第一配置文件包含的版本號，若配置文件A包含的版本號低于上述第一配置文件包含的版本號，則可判定配置文件A為滿足上述第一條件的配置文件。此時，根據(jù)上述第一配置文件中的bundle文件下載地址下載相應(yīng)的bundle文件。

步驟203、基于當次下載的bundle文件更新本地的bundle文件；

在步驟203中，基于步驟202下載的bundle文件更新本地的bundle文件。例如，可以將步驟202下載的bundle文件作為輸入函數(shù)，調(diào)用BundleContext.update方法更新本地的bundle文件。具體地，更新bundle文件的過程也可以參照其它已有技術(shù)實現(xiàn)，此處不做限定。

需要說明的是，在bundle文件更新之后，相應(yīng)地存儲于本地且與被更新的bundle相關(guān)的信息(例如bundle版本號)也會被更新。

步驟204、將滿足上述第一條件的配置文件包含的版本號更新為上述第一配置文件中的版本號；

在步驟204中，將本地存在的滿足上述第一條件的配置文件包含的版本號更新為上述第一配置文件中的版本號。

圖2所示的bundle文件的動態(tài)更新方法可實現(xiàn)bundle文件的動態(tài)更新，而對于由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，該bundle文件的動態(tài)更新實際上也實現(xiàn)了相應(yīng)Activity組件的動態(tài)更新。

在圖1或圖2所示實施例的基礎(chǔ)上，本發(fā)明實施例中的Activity組件加載方法還包含Activity組件動態(tài)卸載方法，如圖3所示，上述Activity組件動態(tài)卸載方法包括：

步驟301、獲取來自服務(wù)器的第二配置文件；

其中，上述第二配置文件包括：bundle符號名稱、版本號和命令信息。

本發(fā)明實施例中，可以在程序運行或啟動的過程中，通過主動獲取方式或者被動獲取方式獲取來自服務(wù)器的第二配置文件。上述主動獲取方式例如可以為：周期性查詢預(yù)設(shè)的服務(wù)器上是否有新增的第二配置文件，若存在新增的第一配置文件，則下載該新增的第二配置文件。上述被動獲取方式可以由服務(wù)器在有新增的第一配置文件時主動推送該第二配置文件。

步驟302、若本地存在滿足第二條件的配置文件且上述第二配置文件包含的命令信息指示的命令為卸載bundle文件，則：根據(jù)上述第二配置文件包含的bundle符號名稱，獲取與上述bundle符號名稱關(guān)聯(lián)的bundle標識符；

其中，上述第二條件為：配置文件包含的bundle符號名稱與上述第二配置文件包含的bundle符號名稱一致，且，配置文件包含的版本號與所述第二配置文件包含的版本號一致。

本發(fā)明實施例中，每個bundle文件可對應(yīng)一配置文件，該配置文件可在bundle文件首次安裝時與該bundle文件關(guān)聯(lián)存儲，或者，也可以在該bundle文件首次啟動時，采用預(yù)先定義的獲取默認配置文件的協(xié)議接口，從服務(wù)器獲取并下載與該bundle文件關(guān)聯(lián)的默認配置文件，之后將下載的默認配置文件與該bundle文件關(guān)聯(lián)存儲。

在步驟302中，對上述第二配置文件進行解析，以檢測本地是否存在包含的bundle符號名稱與步驟301下載的第二配置文件包含的bundle符號名稱一致的配置文件，若存在(為便于描述，后續(xù)將包含的bundle符號名稱與步驟301下載的第二配置文件包含的bundle符號名稱一致的配置文件描述為配置文件B)，進一步檢測配置文件B的版本號是否與上述第二配置文件包含的版本號一致，若配置文件B包含的版本號與上述第二配置文件包含的版本號一致，則可判定配置文件B為滿足上述第二條件的配置文件。進一步檢測上述第二配置文件包含的命令信息指示的命令是否為卸載bundle文件(例如檢測上述第二配置文件包含的命令信息是否為“uninstall”)，若檢測上述第二配置文件包含的命令信息指示的命令為卸載bundle文件，則根據(jù)上述第二配置文件包含的bundle符號名稱，獲取與上述bundle符號名稱關(guān)聯(lián)的bundle標識符(即Bundle ID)。

步驟303、根據(jù)當前獲取的bundle標識符，卸載本地存儲的相應(yīng)的bundle文件；

在步驟303中，基于步驟302獲取的Bundle ID，卸載本地存儲的相應(yīng)的bundle文件。例如，可以將步驟302獲取的Bundle ID作為輸入函數(shù)，調(diào)用BundleContext.uninstall方法卸載相應(yīng)的bundle文件。具體地，卸載bundle文件的過程也可以參照其它已有技術(shù)實現(xiàn)，此處不做限定。

需要說明的是，在bundle文件卸載之后，相應(yīng)地存儲于本地且與被卸載的bundle相關(guān)的信息也會被刪除。

圖3所示的bundle文件的動態(tài)卸載方法可實現(xiàn)bundle文件的動態(tài)卸載，而對于由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，該bundle文件的動態(tài)卸載實際上也實現(xiàn)了相應(yīng)Activity組件的動態(tài)卸載。

需要說明的是，在圖2所示實施例提及的第一配置文件與圖3所示實施例提及的第二配置文件可以為統(tǒng)一格式的配置文件，其中，第一配置文件為bundle符號名稱字段、版本號字段和bundle文件下載地址字段不為空的配置文件，而第二配置文件為bundle符號名稱字段、版本號字段和命令信息字段不為空的配置文件。

本發(fā)明實施例還提供一種應(yīng)用于Android系統(tǒng)的Activity組件加載裝置，如圖4所示，該Activity組件加載裝置400包括：

第一獲取單元401，用于獲取預(yù)先嵌入Android系統(tǒng)的開放服務(wù)網(wǎng)關(guān)協(xié)議框架的BundleContext；

確定單元402，用于確定待啟動的Activity組件；

第二獲取單元403，用于獲取與所述待啟動的Activity組件關(guān)聯(lián)的bundle標識符；

啟動單元404，用于根據(jù)當前第二獲取單元403獲取的bundle標識符，調(diào)用所述BundleContext的BundleContext.start方法啟動相應(yīng)的bundle文件，以便加載相應(yīng)的Activity組件，其中，所述bundle文件由jar文件轉(zhuǎn)化而成，所述jar文件由所述Activity組件的源代碼編譯而成。

可選的，本發(fā)明實施例中的Activity組件加載裝置還包括：

第三獲取單元，用于獲取來自服務(wù)器的第一配置文件，其中，所述第一配置文件包括：bundle符號名稱、版本號和bundle文件下載地址；

下載單元，用于當本地存在滿足第一條件的配置文件時，根據(jù)所述第一配置文件中的bundle文件下載地址下載相應(yīng)的bundle文件；

更新單元，用于基于所述下載單元當次下載的bundle文件更新本地的bundle文件，并將滿足所述第一條件的配置文件包含的版本號更新為所述第一配置文件中的版本號；

其中，所述第一條件為：配置文件包含的bundle符號名稱與所述第一配置文件包含的bundle符號名稱一致，且，配置文件包含的版本號低于所述第一配置文件包含的版本號。

可選的，本發(fā)明實施例中的Activity組件加載裝置還包括：

第三獲取單元，用于獲取來自服務(wù)器的第二配置文件，其中，所述第二配置文件包括：bundle符號名稱、版本號和命令信息；

第四獲取單元，用于當本地存在滿足第二條件的配置文件且所示第二配置文件包含的命令信息指示的命令為卸載bundle文件時，根據(jù)所述第二配置文件包含的bundle符號名稱，獲取與所述bundle符號名稱關(guān)聯(lián)的bundle標識符；

卸載單元，用于根據(jù)所述第四獲取當前獲取的bundle標識符，卸載本地存儲的相應(yīng)的bundle文件；

其中，所述第二條件為：配置文件包含的bundle符號名稱與所述第二配置文件包含的bundle符號名稱一致，且，配置文件包含的版本號與所述第二配置文件包含的版本號一致。

可選的，本發(fā)明實施例中的Activity組件加載裝置還包括：

第五獲取單元，用于通過已啟動的OSGI框架服務(wù)的代理獲取開放服務(wù)網(wǎng)關(guān)協(xié)議框架的實例，其中，所述OSGI框架服務(wù)為：預(yù)先基于Framework創(chuàng)建的，用以實現(xiàn)在所述Android系統(tǒng)運行開放服務(wù)網(wǎng)關(guān)協(xié)議框架的服務(wù)；

第一獲取單元401具體用于：基于所述第五獲取單元獲取的所述開放服務(wù)網(wǎng)關(guān)協(xié)議框架的實例，獲取預(yù)先嵌入Android系統(tǒng)的開放服務(wù)網(wǎng)關(guān)協(xié)議框架的BundleContext。

進一步，本發(fā)明實施例中的Activity組件加載裝置還可包括：系統(tǒng)服務(wù)添加單元，用于將所述OSGI框架服務(wù)添加至所述Android系統(tǒng)的系統(tǒng)服務(wù)中。

需要說明的是，本發(fā)明實施例中的Activity組件加載裝置可以集成智能終端(例如智能手機、平板電腦和智能電視等)中，此處不作限定。

應(yīng)理解，本發(fā)明實施例中的Activity組件加載裝置的各個功能模塊的功能可以根據(jù)上述方法實施例中的方法具體實現(xiàn)，其具體實現(xiàn)過程可參照上述方法實施例中的相關(guān)描述，此處不再贅述。

由上可見，本發(fā)明中的Activity組件加載裝置將由Activity組件的源代碼編譯而成的jar文件轉(zhuǎn)化成bundle文件，并且，在Android系統(tǒng)中嵌入OSGI，借助該OSGI框架實現(xiàn)了bundle文件的運行，進而實現(xiàn)了相應(yīng)Activity組件的加載。由于本發(fā)明中Activity組件的加載是通過啟動相應(yīng)的bundle文件來實現(xiàn)，因此，Activity組件的加載無需受限于AndroidManifest.xml文件，從而使得Activity組件的動態(tài)加載成為可能。

在本申請所提供的幾個實施例中，應(yīng)該理解到，所揭露的方法、裝置和系統(tǒng)可以通過其它的方式實現(xiàn)。

需要說明的是，對于前述的各方法實施例，為了簡便描述，故將其都表述為一系列的動作組合，但是本領(lǐng)域技術(shù)人員應(yīng)該知悉，本發(fā)明并不受所描述的動作順序的限制，因為依據(jù)本發(fā)明，某些步驟可以采用其它順序或者同時進行。其次，本領(lǐng)域技術(shù)人員也應(yīng)該知悉，說明書中所描述的實施例均屬于優(yōu)選實施例，所涉及的動作和模塊并不一定都是本發(fā)明所必須的。

在上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部分，可以參見其它實施例的相關(guān)描述。

以上為對本發(fā)明所提供的一種Activity組件加載方法及裝置的描述，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明實施例的思想，在具體實施方式及應(yīng)用范圍上均會有改變之處，綜上，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。