本發(fā)明涉及Android應(yīng)用平臺(tái)開(kāi)發(fā)領(lǐng)域，尤其涉及一種Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)以及Android應(yīng)用插件化開(kāi)發(fā)方法。

背景技術(shù)：

插件化開(kāi)發(fā)通常是指將復(fù)雜應(yīng)用的功能分解成一個(gè)個(gè)獨(dú)立的模塊，并打包成獨(dú)立的可運(yùn)行文件，由插件框架調(diào)用啟動(dòng)不同的模塊可運(yùn)行文件，將原來(lái)的大系統(tǒng)大應(yīng)用進(jìn)行分割，不同模塊可以獨(dú)立更新、插拔而不需要影響到整個(gè)應(yīng)用或其他模塊，可保證系統(tǒng)的可擴(kuò)展性、靈活性。

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，目前市面上單個(gè)移動(dòng)應(yīng)用的功能越來(lái)越多，越來(lái)越復(fù)雜，對(duì)應(yīng)用本身的架構(gòu)及擴(kuò)展性造成很大的挑戰(zhàn)，原來(lái)小團(tuán)隊(duì)規(guī)模開(kāi)發(fā)的應(yīng)用隨著市場(chǎng)需求的增加不得不面對(duì)功能爆炸式的增長(zhǎng)，如何有序地駕馭應(yīng)用復(fù)雜度的增長(zhǎng)成為近年來(lái)移動(dòng)端架構(gòu)的主題。當(dāng)前，Android應(yīng)用開(kāi)發(fā)市面上主要使用的是插件化開(kāi)發(fā)，以此來(lái)實(shí)現(xiàn)應(yīng)用功能模塊化、獨(dú)立化的運(yùn)作。比如大家熟知的淘寶、支付寶、微信都具備插件化開(kāi)發(fā)的能力。當(dāng)需要增加應(yīng)用新功能時(shí)，只需要在服務(wù)端發(fā)布該新功能的插件模塊，前臺(tái)應(yīng)用就能更新新的功能到本地客戶(hù)端，為應(yīng)用的更新、規(guī)劃提供更便捷的解決方案。一個(gè)典型的例子就是微信中打飛機(jī)游戲的插件化發(fā)布。在微信發(fā)布打飛機(jī)游戲的時(shí)候，大部分客戶(hù)端是不具備該游戲功能模塊的，而是使用下載更新插件的方法動(dòng)態(tài)下載 游戲到本地并運(yùn)行，為微信提供強(qiáng)大的終端運(yùn)營(yíng)能力。

目前，Android市面上僅有阿里巴巴公司開(kāi)源的Atlas應(yīng)用框架可供實(shí)現(xiàn)插件化開(kāi)發(fā)。Atlas框架支持對(duì)Android工程單獨(dú)打包成框架可運(yùn)行文件，并由框架調(diào)用啟動(dòng)，但是Atlas需要對(duì)Android sdk中apptool打包工具進(jìn)行改寫(xiě)，打包出的可運(yùn)行文件不能再被Android系統(tǒng)運(yùn)行，并且開(kāi)發(fā)時(shí)需要為eclipse ide打上開(kāi)發(fā)插件，不能像開(kāi)發(fā)普通應(yīng)用一樣開(kāi)發(fā)插件，對(duì)應(yīng)用的開(kāi)發(fā)調(diào)試有一定限制，不夠便捷、高效。

因此，總的來(lái)說(shuō)，現(xiàn)有技術(shù)存在如下問(wèn)題：應(yīng)用功能模塊隨著需求增加復(fù)雜度、耦合度增加，易造成應(yīng)用不穩(wěn)定風(fēng)險(xiǎn)；微小的模塊變動(dòng)就必須對(duì)應(yīng)用進(jìn)行全量升級(jí)，造成用戶(hù)流量的浪費(fèi)以及不好的用戶(hù)體驗(yàn)；相關(guān)功能app越來(lái)越多，用戶(hù)手機(jī)上的應(yīng)用繁多，不方便統(tǒng)一管理，對(duì)用戶(hù)桌面體驗(yàn)影響很大。

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

本發(fā)明要解決的技術(shù)問(wèn)題在于，針對(duì)現(xiàn)有技術(shù)的上述缺陷，提供一種Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)和方法。

本發(fā)明解決其技術(shù)問(wèn)題所采用的技術(shù)方案是：構(gòu)造一種Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)，包括：與主應(yīng)用綁定的一個(gè)插件框架和至少一個(gè)插件apk；所述插件apk包括一描述文件，所述描述文件內(nèi)記錄有所述插件apk的程序入口代碼；每個(gè)所述插件apk在安裝時(shí)被解析且解析信息保存在插件框架的特定目錄下，所述插件框架用于根據(jù)所述特定目錄下的所述解析信息中的描述文件運(yùn)行插件apk。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)中，所述的運(yùn)行插件apk包括：插件框架基于特定目錄下的解析信息，通過(guò)hook技術(shù)構(gòu)造出插件apk 的運(yùn)行環(huán)境，并讀取描述文件內(nèi)記錄的程序入口代碼,利用讀取的程序入口代碼替代主應(yīng)用的程序入口代碼進(jìn)而啟動(dòng)相應(yīng)的插件apk。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)中，還包括一個(gè)library模塊，任意的兩個(gè)插件apk之間以及主應(yīng)用與插件apk之間通過(guò)所述library模塊通信，所述library模塊用于任意的兩個(gè)插件apk之間以及主應(yīng)用與插件apk之間的數(shù)據(jù)統(tǒng)一管理和事件分發(fā)管理。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)中，所述插件框架和所述插件apk均遵循OSGi規(guī)范。

本發(fā)明還公開(kāi)了一種Android應(yīng)用插件化開(kāi)發(fā)方法，所述方法包括：

S1、將主應(yīng)用和一個(gè)插件框架綁定；增設(shè)一描述文件到插件apk中，所述描述文件內(nèi)記錄有所述插件apk的程序入口代碼；

S2、對(duì)插件apk進(jìn)行解析，將解析信息保存在插件框架的特定目錄下；

S3、插件框架根據(jù)所述特定目錄下的所述解析信息中的描述文件運(yùn)行插件apk。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)方法中，

所述步驟S3包括：

S31、插件框架基于特定目錄下的解析信息，通過(guò)hook技術(shù)構(gòu)造出插件apk的運(yùn)行環(huán)境；

S32、插件框架讀取描述文件內(nèi)記錄的程序入口代碼,利用讀取的程序入口代碼替代主應(yīng)用的程序入口代碼進(jìn)而啟動(dòng)相應(yīng)的插件apk。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)方法中，所述方法還包括：增設(shè)一個(gè)用于數(shù)據(jù)統(tǒng)一管理和事件分發(fā)管理的library模塊，任意的兩個(gè)插件apk之間以及主應(yīng)用與插件apk之間通過(guò)所述library模塊通信。

在本發(fā)明所述的Android應(yīng)用插件化開(kāi)發(fā)方法中，所述插件框架和所述插件apk均遵循OSGi規(guī)范。

實(shí)施本發(fā)明的Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)和方法，具有以下有益效果：本發(fā)明中插件框架可根據(jù)描述文件直接運(yùn)行插件apk，因此用戶(hù)可以將應(yīng)用功能的業(yè)務(wù)分成不同的工程做成單獨(dú)的插件apk，最終集成到主應(yīng)用中即可，分解了原先代碼耦合在一起的弊端，由于功能代碼獨(dú)立存在不相互依賴(lài)，使得應(yīng)用源碼的復(fù)雜度大大下降；其次，應(yīng)用模塊以插件形式存在后，被當(dāng)做資源集成到主應(yīng)用中，插件可以以更新資源(如更新特定目錄下的解析信息)的方式更新，而不需要經(jīng)過(guò)系統(tǒng)安裝新的apk來(lái)更新應(yīng)用；而且不僅僅可以將應(yīng)用的功能模塊以插件的方式改造，對(duì)于其他的應(yīng)用可以通過(guò)增設(shè)描述文件后集成進(jìn)來(lái)，主應(yīng)用相當(dāng)于一個(gè)統(tǒng)一的應(yīng)用入口，以減少用戶(hù)手機(jī)桌面上安裝的app數(shù)量，方便用戶(hù)統(tǒng)一管理一個(gè)系列的app，提升手機(jī)桌面的用戶(hù)體驗(yàn)。

附圖說(shuō)明

下面將結(jié)合附圖及實(shí)施例對(duì)本發(fā)明作進(jìn)一步說(shuō)明，附圖中：

圖1是本發(fā)明Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)的結(jié)構(gòu)示意圖；

圖2是本發(fā)明Android應(yīng)用插件化開(kāi)發(fā)方法的流程圖。

具體實(shí)施方式

為了對(duì)本發(fā)明的技術(shù)特征、目的和效果有更加清楚的理解，現(xiàn)對(duì)照附圖詳細(xì)說(shuō)明本發(fā)明的具體實(shí)施方式。

如圖1所示，是本發(fā)明Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)的結(jié)構(gòu)示意圖。

本發(fā)明的Android應(yīng)用插件化開(kāi)發(fā)系統(tǒng)，包括：與主應(yīng)用綁定的一個(gè)插件 框架、library模塊和至少一個(gè)插件apk。

所述插件apk包括一描述文件，所述描述文件內(nèi)記錄有所述插件apk的程序入口代碼activity。其中，增加了描述文件的插件apk的創(chuàng)建過(guò)程如下：

首先，在普通的android工程的asset文件夾下增加插件描述文件，例如在asset文件夾下增加名稱(chēng)為plugin.properties；

然后，對(duì)描述文件進(jìn)行編輯，設(shè)定插件入口描述，例如plugin.properties文件中寫(xiě)入：Bundle-MainActivity＝某個(gè)插件apk的入口activity；

最后，將工程編譯并打包成apk文件，即可完成插件創(chuàng)建。

插件框架在安裝插件apk時(shí)，會(huì)把打包好的apk包解壓到特定目錄下，啟動(dòng)時(shí)從特定目錄下的asset文件夾下讀取描述文件，并加載插件apk的代碼和資源，由描述文件指定的入口activity啟動(dòng)插件。

其中，所述插件框架和所述插件apk均遵循OSGi規(guī)范。OSGi(Open Service Gateway Initiative)是面向Java的動(dòng)態(tài)模型系統(tǒng)。每一個(gè)apk插件被映射到插件框架中就是一個(gè)Bundle對(duì)象,完整路徑為：org.OSGi.framework.Bundle。通過(guò)這個(gè)Bundle能獲取到插件apk的基本信息(本身靜態(tài)屬性)以及描述文件。

因此，所述的運(yùn)行插件apk具體包括：插件框架基于特定目錄下的解析信息，通過(guò)hook技術(shù)構(gòu)造出插件apk的運(yùn)行環(huán)境，并讀取描述文件內(nèi)記錄的程序入口代碼activity,利用讀取的程序入口代碼activity替代即將加載的主應(yīng)用的程序入口代碼activity進(jìn)而啟動(dòng)相應(yīng)的插件apk。

插件框架和所述插件apk均遵循OSGi規(guī)范。插件框架用于模擬系統(tǒng)的行為，對(duì)apk文件進(jìn)行解析、加載、運(yùn)行。任何一個(gè)應(yīng)用，只要引用了插件框架這個(gè)庫(kù)，即可具備插件框架的能力，進(jìn)而可啟動(dòng)插件。通過(guò)模擬Hack系統(tǒng)安裝、啟動(dòng)APK的行為，對(duì)插件apk的安裝包進(jìn)行模擬安裝和啟動(dòng)，插件框架具 備系統(tǒng)啟動(dòng)apk文件的能力。使用插件框架后，相當(dāng)于在Android系統(tǒng)上再構(gòu)建了一個(gè)系統(tǒng)層，用于管理插件apk。

使用插件化開(kāi)發(fā)模式之后，使得應(yīng)用的可擴(kuò)展能力增強(qiáng)，有效控制安裝包體積。原有Android在集成應(yīng)用時(shí)，只能進(jìn)行代碼級(jí)的集成，并且造成代碼間耦合度增加、應(yīng)用穩(wěn)定性下降等問(wèn)題。而利用本發(fā)明的插件化開(kāi)發(fā)系統(tǒng)，可以方便的進(jìn)行獨(dú)立應(yīng)用集成，而不需要大幅修改主體工程源碼，在開(kāi)發(fā)效率、測(cè)試效率上得到提升。

在插件apk啟動(dòng)之后，通過(guò)library模塊實(shí)現(xiàn)任意的兩個(gè)插件apk之間以及者主應(yīng)用與插件apk之間的通信。Library模塊使得插件apk與主應(yīng)用共享了同一個(gè)運(yùn)行空間，這使得插件既可以以獨(dú)立的apk的形式存在，又可以和主應(yīng)用之間相互調(diào)用，獨(dú)立且靈活。

library模塊是一個(gè)公用的代碼模塊，實(shí)現(xiàn)插件與插件以及插件與主應(yīng)用之間的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)的管理、對(duì)事件分發(fā)的管理、對(duì)網(wǎng)絡(luò)請(qǐng)求的管理等，其中最主要的是對(duì)event事件的管理，主應(yīng)用和插件均通過(guò)library模塊進(jìn)行event事件的收發(fā)，所以可以通過(guò)library模塊進(jìn)行插件與插件、插件與主應(yīng)用之間的通信。本插件框架的優(yōu)勢(shì)，就是可以讓獨(dú)立存在的插件也能和主應(yīng)用進(jìn)行方便的通信以及訪(fǎng)問(wèn)主應(yīng)用的數(shù)據(jù)和資源，做到既可以獨(dú)立運(yùn)行，又可以協(xié)作運(yùn)行。

例如，企信(例如微信)主應(yīng)用啟動(dòng)了插件a，插件a通過(guò)企信的選擇人員界面選擇人員，選擇成功后，企信將人員選擇結(jié)果數(shù)據(jù)以event事件方式包裝并發(fā)送給library模塊，library模塊將event事件分發(fā)到插件a，插件a接收到結(jié)果后，使用這個(gè)結(jié)果通過(guò)library對(duì)主應(yīng)用發(fā)送事件請(qǐng)求創(chuàng)建一個(gè)討論組，主應(yīng)用收到請(qǐng)求并創(chuàng)建成功后，將結(jié)果又通過(guò)event事件的方式傳遞到 插件a，插件a得到討論組創(chuàng)建成功后的事件后可以進(jìn)行討論組會(huì)話(huà)。該例中創(chuàng)建討論組的功能是主應(yīng)用提供的，而插件通過(guò)event事件的方式調(diào)用了主應(yīng)用的功能，而這些流程中，插件不需要引用主應(yīng)用的代碼。同樣的，插件與插件之間的調(diào)用也可以通過(guò)event，避免了損壞插件獨(dú)立性的特點(diǎn)。

本發(fā)明可以使應(yīng)用具備類(lèi)似Android系統(tǒng)的行為能力，來(lái)啟動(dòng)一個(gè)插件apk可運(yùn)行文件，而不需要預(yù)先在用戶(hù)手機(jī)系統(tǒng)內(nèi)安裝。且啟動(dòng)的插件apk可以類(lèi)似于普通Android工程開(kāi)發(fā)，而不需要進(jìn)行額外的配置開(kāi)發(fā)環(huán)境。

參考圖2，是本發(fā)明Android應(yīng)用插件化開(kāi)發(fā)方法的流程圖。

相應(yīng)的，本發(fā)明還公開(kāi)了一種基于所述系統(tǒng)的Android應(yīng)用插件化開(kāi)發(fā)方法，所述方法包括：

S1、將主應(yīng)用和一個(gè)插件框架綁定；增設(shè)一描述文件到插件apk中，所述描述文件內(nèi)記錄有所述插件apk的程序入口代碼；所述插件框架和所述插件apk均遵循OSGi規(guī)范。

其中，增加了描述文件的插件apk的創(chuàng)建過(guò)程如下：

首先，在普通的android工程的asset文件夾下增加插件描述文件，例如在asset文件夾下增加名稱(chēng)為plugin.properties；

然后，對(duì)描述文件進(jìn)行編輯，設(shè)定插件入口描述，例如plugin.properties文件中寫(xiě)入：Bundle-MainActivity＝某個(gè)插件apk的入口activity；

最后，將工程編譯并打包成apk文件，即可完成插件創(chuàng)建。

S2、對(duì)插件apk進(jìn)行解析，將解析信息保存在插件框架的特定目錄下；

每一個(gè)apk插件解析后，被映射到插件框架中就是一個(gè)Bundle對(duì)象,完整路徑為：org.OSGi.framework.Bundle。

S3、插件框架根據(jù)所述特定目錄下的所述解析信息中的描述文件運(yùn)行插件 apk。通過(guò)這個(gè)Bundle能獲取到插件apk的基本信息(本身靜態(tài)屬性)以及描述文件。

插件框架在安裝插件apk時(shí)，會(huì)把打包好的apk包解壓到特定目錄下，啟動(dòng)時(shí)從特定目錄下的asset文件夾下讀取描述文件，并加載插件apk的代碼和資源，由描述文件指定的入口activity啟動(dòng)插件。

其中，

具體的，所述步驟S3包括：

S31、插件框架基于特定目錄下的解析信息，通過(guò)hook技術(shù)構(gòu)造出插件apk的運(yùn)行環(huán)境；

S32、插件框架讀取描述文件內(nèi)記錄的程序入口代碼,利用讀取的程序入口代碼替代主應(yīng)用的程序入口代碼進(jìn)而啟動(dòng)相應(yīng)的插件apk。

在啟動(dòng)一個(gè)插件apk之后，任意的兩個(gè)插件apk之間以及主應(yīng)用與插件apk之間通過(guò)一個(gè)library模塊通信。

library模塊是一個(gè)公用的代碼模塊，實(shí)現(xiàn)插件與插件以及插件與主應(yīng)用之間的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)的管理、對(duì)事件分發(fā)的管理、對(duì)網(wǎng)絡(luò)請(qǐng)求的管理等，其中最主要的是對(duì)event事件的管理，主應(yīng)用和插件均通過(guò)library模塊進(jìn)行event事件的首發(fā)，所以可以通過(guò)library模塊進(jìn)行插件與插件、插件與主應(yīng)用之間的通信。本插件框架的優(yōu)勢(shì)，就是可以讓獨(dú)立存在的插件也能和主應(yīng)用進(jìn)行方便的通信以及訪(fǎng)問(wèn)主應(yīng)用的數(shù)據(jù)和資源，做到既可以獨(dú)立運(yùn)行，又可以協(xié)作運(yùn)行。

綜上所述，本發(fā)明中插件框架可根據(jù)描述文件直接運(yùn)行插件apk，因此用戶(hù)可以將應(yīng)用功能的業(yè)務(wù)分成不同的工程做成單獨(dú)的插件apk，最終集成到主應(yīng)用中即可，分解了原先代碼耦合在一起的弊端，由于功能代碼獨(dú)立存在不相 互依賴(lài)，使得應(yīng)用源碼的復(fù)雜度大大下降；其次，應(yīng)用模塊以插件形式存在后，被當(dāng)做資源集成到主應(yīng)用中，插件可以以更新資源(如更新特定目錄下的解析信息)的方式更新，而不需要經(jīng)過(guò)系統(tǒng)安裝新的apk來(lái)更新應(yīng)用；而且不僅僅可以將應(yīng)用的功能模塊以插件的方式改造，對(duì)于其他的應(yīng)用增設(shè)描述文件后集成進(jìn)來(lái)，主應(yīng)用相當(dāng)于一個(gè)統(tǒng)一的應(yīng)用入口，以減少用戶(hù)手機(jī)桌面上安裝的app數(shù)量，方便用戶(hù)統(tǒng)一管理一個(gè)系列的app，提升手機(jī)桌面的用戶(hù)體驗(yàn)。

上面結(jié)合附圖對(duì)本發(fā)明的實(shí)施例進(jìn)行了描述，但是本發(fā)明并不局限于上述的具體實(shí)施方式，上述的具體實(shí)施方式僅僅是示意性的，而不是限制性的，本領(lǐng)域的普通技術(shù)人員在本發(fā)明的啟示下，在不脫離本發(fā)明宗旨和權(quán)利要求所保護(hù)的范圍情況下，還可做出很多形式，這些均屬于本發(fā)明的保護(hù)之內(nèi)。