過程中通過Context. registerReceiver注冊。
[0152] 應(yīng)用程序的運行需要相匹配的運行環(huán)境，故本發(fā)明由構(gòu)造單元12構(gòu)造應(yīng)用程 序的運行環(huán)境。應(yīng)用程序包含多個Activity，其啟動過程實際上是應(yīng)用程序中的默認 activity啟動過程，然后由默認activity在內(nèi)部調(diào)起其他activity，故本發(fā)明重點闡述由 構(gòu)造單元12對未安裝應(yīng)用程序的activity組件加載調(diào)度過程。
[0153] 應(yīng)用程序的配置文件Androidmanafest. xml中，各個activity的注冊 信息可以視為獨立注冊信息模塊，視為"坑位"。Android系統(tǒng)在對應(yīng)用程序進 行安裝時，由PackageManageService (PMS)對APK安裝包的各個組件進行校驗， 而ActivityManagerSevice (AMS)則可以根據(jù)注冊信息為活動組件建立進程入口 (ActivityThread)，以確?；顒咏M件的正常運行。
[0154] 通常，Activity活動組件應(yīng)當預(yù)先在Androidmanafest. xml配置文件中進行坑位 注冊，并且坑位與組件名稱以及活動組件的其他屬性之間應(yīng)保持--對應(yīng)性和確定性，這 樣才能夠確保這些活動組件的正常注冊。這種情況下，整個應(yīng)用程序應(yīng)當在開發(fā)時便確定 了這些活動組件，由這些活動組件有機組合而成的應(yīng)用程序繼而作為一個整體提供給終端 進行安裝。終端每一次安裝均是基于一個完整的應(yīng)用程序的基礎(chǔ)上進行，其中的每一個活 動組件都在配置文件中進行了一一對應(yīng)的注冊表達，不存在任何不確定性。換言之，任何未 經(jīng)在Androidmanifest. xml注冊的Activity活動組件，常規(guī)情況下均不能夠被調(diào)度為進程 運行。由此可知，每一次為應(yīng)用程序擴展功能而提供新的活動組件，均需要將應(yīng)用程序重新 進行打包，并以打包后的安裝文件提供給客戶端進行安裝，每次安裝均是全量的。對于遠程 下載的情況而言，既浪費流量，又降低了效率，更不利于應(yīng)用程序的功能模塊的靈活擴展。 為了解決此問題，本發(fā)明采用在配置文件中預(yù)留活動組件坑位的方式加載應(yīng)用程序的活動 組件。所述活動組件坑位的具體調(diào)度步驟如下：
[0155] 步驟1、宿主程序向系統(tǒng)預(yù)注冊多個activity組件坑位；
[0156] 本發(fā)明出于預(yù)留的目的而在宿主程序的Androidmanifest. xml配置文件中設(shè)置 多個活動組件注冊信息，但這些注冊信息所指向的活動組件的真實內(nèi)容并未確定，因此，本 發(fā)明中，形象地將這些配置文件預(yù)留了注冊信息的活動組件，并在該配置文件提供給系統(tǒng) 進行安裝之后形成的活動組件虛擬單位稱之為活動組件坑位。具體而言，預(yù)先在主程序的 Androidmanifest. xml文件中聲明了多個活動組件的注冊信息，以便在主程序安裝時，由 PMS依據(jù)這些注冊信息進行注冊，由AMS為其建立進程入口，從而形成所述的活動組件坑 位。
[0157] 依據(jù)活動組件的不同屬性，諸如launchMode、taskAffinity、theme等屬性對活動 組件進行分類管理，因此，在所述的注冊信息中所使用到的包名，可以在包名的后綴中使用 不同的特征字符用于表征不同類型的坑位，也是指代不同的進程空間，以利于識別。
[0158] 步驟2、構(gòu)建包含所述多個活動組件坑位的特征信息的坑位列表；
[0159] 構(gòu)建坑位列表的過程，將涉及到對Application類的運用，因此先行介紹 Application 類。
[0160] Application 和 Activity、Service - 樣是 Android 框架的一個系統(tǒng)組件， 當Android程序啟動時系統(tǒng)會創(chuàng)建一個Application對象，用來存儲系統(tǒng)的一些信息。 Android系統(tǒng)自動會為每個程序運行時創(chuàng)建一個Application類的對象且只創(chuàng)建一個，所 以Application可以說是單例（singleton)模式的一個類。通常使用時并不需要指定一個 Application，系統(tǒng)會自動為之創(chuàng)建該類，如果需要創(chuàng)建自有的Application，只需創(chuàng)建一個 類繼承Application并在AndroidManifest. xml文件中的application標簽中進行注冊。
[0161] 啟動Application時，系統(tǒng)會創(chuàng)建一個PID，即進程ID，所有的Activity都會在 此進程上運行。那么如果在Application創(chuàng)建的時候初始化全局變量，同一個應(yīng)用的所 有Activity都可以取到這些全局變量的值，換句話說，如果在某一個Activity中改變了 這些全局變量的值，那么在同一個應(yīng)用的其他Activity中值就會改變。Application對 象的生命周期是整個程序中最長的，它的生命周期就等于這個程序的生命周期。因為它是 全局的單例的，所以在不同的Activity、Service中獲得的對象都是同一個對象。所以可 以通過Application來進行一些，如：數(shù)據(jù)傳遞、數(shù)據(jù)共享和數(shù)據(jù)緩存等操作。通過繼承 Application類來實現(xiàn)應(yīng)用程序級的全局變量，這種全局變量方法相對靜態(tài)類更有保障，直 到應(yīng)用的所有Activity全部被destory掉之后才會被釋放掉。
[0162] 與此同時，Activity的IaunchMode屬性在多個Activity跳轉(zhuǎn)的過程中扮演著 重要的角色，它可以決定是否生成新的Activity實例，是否重用已存在的Activity實 例，是否和其他Activity實例公用一個task棧。其中，IaunchMode屬性包括standard、 singleTop、singleTask、singlelnstance 四種模式?；?Application 和 IaunchMode 的 以上特性，通過重構(gòu)Application. onCreate方法，在其中寫入用于添加每個活動組件坑位 特征信息的代碼指令，來實現(xiàn)所述坑位列表的構(gòu)建。
[0163] 所述坑位列表實質(zhì)上是實現(xiàn)了對具體列表的索引，其包括總表、以IaunchMode屬 性進行分類后組成的四種列表，以及IaunchMode屬性結(jié)合Theme屬性、taskAffinity屬 性分類后組成的列表。如 private final HashMap〈String，ActivityState>mStates，其 中，String字段是字符串，表示Activity坑位的坑位名，而ActivityState則為狀態(tài)信息， mStates表示該列表為總表，即所有的Activity都要存儲在這張表中，以作為匯總之用。
[0164] 通過上述的方式，便建立起坑位列表所包括的各個子表的索引關(guān)系，由此形成一 個數(shù)據(jù)架構(gòu)。
[0165] 步驟3、利用坑位列表為待加載活動組件分配相適配的目標活動組件坑位；
[0166] 本步驟利用上述的坑位列表為應(yīng)用程序中的待加載活動組件分配坑位。具體 而言，從應(yīng)用程序的PackageInfo中獲取所有ActivityInfo對象，通過launchMode、 taskAffinity、theme等屬性判別與請求分配的待加載活動組件所屬的類型表，開始對類型 表進行檢索，從相應(yīng)的類型表中確定相適配的目標活動組件坑位。
[0167] 步驟4、將該待加載活動組件加載到目標坑位所對應(yīng)的進程空間中運行。
[0168] 由上一步驟提供的分配方法確定唯一的一個目標坑位，返回該目標坑位的信息， 所述信息主要指坑位名稱，通過重構(gòu)的類加載器ClassLoader加載待加載活動組件。然后 由類對象傳遞目標坑位，利用該對象構(gòu)造 Intent，然后以context. startActivity方法調(diào) 用該Intent，即可打開目標坑位，從而使待加載活動組件加載于既定進程空間中運行。
[0169] 由此，便可實現(xiàn)免安裝應(yīng)用程序的活動組件Activity加載于系統(tǒng)進程中，構(gòu)造出 其運行環(huán)境。此外，
[0170] 宿主程序還向系統(tǒng)預(yù)注冊多個進程，以滿足有多個未安裝應(yīng)用程序同時借助宿 主程序運行時使用，每個應(yīng)用程序?qū)?yīng)一個進程，且僅對應(yīng)一個ContentProvider和一 個Service。故而，每個進程又向系統(tǒng)預(yù)注冊一個ContentProvider坑位和一個Service 坑位。其中，Service用于以后臺服務(wù)的形式運行應(yīng)用程序，ContentProvider用于為不 同的應(yīng)用程序訪問相同的數(shù)據(jù)提供統(tǒng)一接口。本發(fā)明對免安裝應(yīng)用程序的Service和 ContentProvider的調(diào)度與上述活動組件Activity相同，只是本發(fā)明所述這兩種組件的 調(diào)度方案更適用與多進程的情況，而Activity的調(diào)度方法適用于單進程和多進程。對于 Service和ContentProvider的調(diào)度方案可參考上述Activity的調(diào)度方法，在此不再贅述。
[0171] Android系統(tǒng)四大組件還包括廣播組件Broadcast Receiver組件，由于通常的 靜態(tài)注冊方式需要在AndroidManifest. xml文件中聲明，而免安裝應(yīng)用程序由于沒有安裝 入系統(tǒng)，故其AndroidManifest. xml文件中聲明的Broadcast Receiver組件不能通過系 統(tǒng)認證，也不能在系統(tǒng)中注冊。因此，本發(fā)明采用動態(tài)注冊的方式在系統(tǒng)中注冊Broadcast Receiver，以使應(yīng)用程序在運行過程中實現(xiàn)廣播的注冊。
[0172] 宿主程序預(yù)先向系統(tǒng)注冊多個進程，以滿足多個應(yīng)用程序的同時運行，或應(yīng)用程 序的不同的組件加載于不同的進程中。其中，每個進程僅對應(yīng)一個上述所述的組件坑位，當 應(yīng)用程序運行時，則去匹配未被占用的坑位，如果匹配成功則應(yīng)用程序運行于該坑位對應(yīng) 的進程，如果匹配不成功則繼續(xù)匹配未被占用的坑位，直到匹配成功。在此過程中，當坑位 被應(yīng)用程序使用完以后，則回收該坑位，無論該坑位對應(yīng)的進程是否還在運行，都對該坑位 進行回收，以便后續(xù)分配給其他應(yīng)用程序，實現(xiàn)進程的共享。
[0173] 當然，上述只是對本發(fā)明構(gòu)造單元12執(zhí)行的對應(yīng)用程序部分運行環(huán)境的構(gòu)造方 法做說明，由于程序的運行需要涉及很多細節(jié)，故在此不一一說明，本領(lǐng)域技術(shù)人員可以基 于本發(fā)明所述方法，結(jié)合現(xiàn)有技術(shù)，構(gòu)造出免安裝應(yīng)用程序的運行環(huán)境。
[0174] 運行資源調(diào)用單元13,用于在所述應(yīng)用程序運行過程中，調(diào)度應(yīng)用程序運行所需 的系統(tǒng)資源，以確保該應(yīng)用程序正常運行。
[0175] 應(yīng)用程序基于上述構(gòu)造完成的運行環(huán)境運行過程中，還包括對一系列運行資源的 調(diào)用，本發(fā)明配置運行資源調(diào)用單元13執(zhí)行。首先，由于Android系統(tǒng)的碎片化，要適用于 多種不同的系統(tǒng)版本，就需要開發(fā)不同版本的應(yīng)用程序，而為了使作為功能模塊的應(yīng)用程 序在免安裝的情況下適用于不同版本的程序，需要在應(yīng)用程序運行過程中，由適配單元16 為其適配相匹配的系統(tǒng)接口函數(shù)。在對系統(tǒng)接口函數(shù)調(diào)用過程中，通常需要先利用Java的 反射機制去獲取函數(shù)接口的對象，然后再調(diào)用該函數(shù)方法，該過程比較耗時，因此，為了提 高調(diào)用效率，本發(fā)明的第二存儲單元18將第一次調(diào)用后獲取的函數(shù)接口對象緩存入內(nèi)存， 以便后續(xù)調(diào)用相同函數(shù)時直接從內(nèi)存中獲取相應(yīng)的對象，從而避免系統(tǒng)查找相應(yīng)對象產(chǎn)生 的耗時問題。
[0176] 其次，在應(yīng)用程序運行過程中，由于其未安裝到系統(tǒng)中，故其各組件就沒有實際 意義，而各組件的生命周期是由系統(tǒng)管理的。Activity的生命周期由ActivityManager 管理的，由ActivityManager調(diào)用startActivity函數(shù)啟動Activity。主進程調(diào)用 startService函數(shù)，通過binder進程間通信機制通知ActivityManagerService創(chuàng)建新的 進程，并啟動指定的服務(wù)，其中，所述指定的服務(wù)即為上述步驟確定的要加載的應(yīng)用程序的 服務(wù)。ContentProvider只有在被用到的時候才會被系統(tǒng)加載到內(nèi)存中，ActivityManager 調(diào)用getContentProvider函數(shù)獲取應(yīng)用程序的數(shù)據(jù)信息。
[0177] 基于上述原理，為了保證應(yīng)用程序的正常運行，本發(fā)明的運行資源調(diào)用單元13提 供一種方法，作為系統(tǒng)和應(yīng)用程序之間的代理，將應(yīng)用程序的運行過程中用戶的資源加載 到系統(tǒng)的進程中。具體調(diào)用應(yīng)用程序的運行資源包括以下幾方面：
[0178] 1、在Android