本發(fā)明涉及軟件加載技術(shù)領(lǐng)域，尤其涉及一種APP快速加載方法。

背景技術(shù)：

隨著信息技術(shù)等相關(guān)產(chǎn)業(yè)的高速發(fā)展，智能終端設(shè)備已經(jīng)轉(zhuǎn)變?yōu)槭澜绺鱾€國家發(fā)展信息技術(shù)的熱門方向，智能終端逐漸演變成集合了交流平臺、娛樂平臺、商務(wù)平臺于一體的載體。

目前極為流行的智能終端產(chǎn)品多以ARM內(nèi)核處理器為核心，移植RTOS微內(nèi)核，再配合外圍設(shè)備實現(xiàn)智能終端的多功能。如果需要智能終端具備更強(qiáng)的擴(kuò)展性能，那還需要輔以軟件重定位技術(shù)來實現(xiàn)軟件的動態(tài)加載。但是在每次運(yùn)行同一個動態(tài)軟件的過程中，都需要將軟件中的代碼進(jìn)行l(wèi)ink（鏈接）、load（加載）處理，然后才能生成可執(zhí)行文件。所以，每次運(yùn)行軟件都需要耗費大量的時間，造成CPU資源的浪費。同時，此過程也消耗大量的電能，為原本容量就極小的電池帶來更大的負(fù)擔(dān)。

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

本發(fā)明要解決的技術(shù)問題就在于：針對現(xiàn)有技術(shù)存在的技術(shù)問題，本發(fā)明提供一種可實現(xiàn)在智能終端上進(jìn)行APP的快速加載，節(jié)約APP（應(yīng)用軟件程序）的安裝時間，降低安裝APP的能耗，高效、可靠的APP快速加載方法。

為解決上述技術(shù)問題，本發(fā)明提出的技術(shù)方案為：一種APP快速加載方法，包括：

S1. 智能設(shè)備為APP分配固定的運(yùn)行空間；

S2. 初始化所述運(yùn)行空間；

S3. 根據(jù)所需要加載的APP，判斷APP存儲空間中是否存在所述需要加載的APP的可執(zhí)行文件和配置信息文件，是則跳轉(zhuǎn)到步驟S4，否則跳轉(zhuǎn)到步驟S5；

S4. 從所述APP存儲空間獲取所述需要加載的APP的可執(zhí)行文件和配置信息文件，并根據(jù)所述配置信息文件將所述需要加載的APP的可執(zhí)行文件加載至所述運(yùn)行空間；

S5. 從所述APP存儲空間獲取所述需要加載的APP的軟件包，解析并重定位所述軟件包，生成需要加載的APP的可執(zhí)行文件及配置信息文件，將所述可執(zhí)行文件加載至運(yùn)行空間，并將所述可執(zhí)行文件及配置信息文件備份至所述APP存儲空間。

作為本發(fā)明的進(jìn)一步改進(jìn)，所述步驟S2的具體步驟包括：判斷所述運(yùn)行空間是否已經(jīng)被占用，是則重新初始化所述運(yùn)行空間。

作為本發(fā)明的進(jìn)一步改進(jìn)，在所述步驟S1之后，還包括步驟S1a：根據(jù)所需要加載的APP，判斷所需要加載的APP的可執(zhí)行文件是否緩存在智能設(shè)備中，是則直接運(yùn)行所述可執(zhí)行文件，否則跳轉(zhuǎn)到步驟S3。

作為本發(fā)明的進(jìn)一步改進(jìn)，所述步驟S5的具體步驟包括：

S5.1. 從所述APP存儲空間獲取所述需要加載的APP的軟件包；

S5.2. 解析所述軟件包，進(jìn)行軟件包的代碼段與資源段的分離；

S5.3. 將所述需要加載的APP的詳細(xì)信息注冊到智能設(shè)備的軟件管理器中；

S5.4. 通過所述軟件管理器對所述代碼段進(jìn)行Link和Load操作，生成所述需要加載的APP的可執(zhí)行文件和配置信息文件；

S5.5. 將所述可執(zhí)行文件拷貝至所述運(yùn)行空間，運(yùn)行所述可執(zhí)行文件；

S5.6. 將所述可執(zhí)行文件拷貝和配置信息文件備份至所述APP存儲空間。

作為本發(fā)明的進(jìn)一步改進(jìn)，所述APP存儲空間為所述智能設(shè)備以外的服務(wù)端上的存儲空間。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點在于：可實現(xiàn)在智能終端上進(jìn)行APP的快速加載，節(jié)約APP的安裝時間，降低安裝APP的能耗，安裝效率高、可靠性好。

附圖說明

圖1為軟件包的結(jié)構(gòu)示意圖。

圖2為本發(fā)明具體實施例流程示意圖。

具體實施方式

以下結(jié)合說明書附圖和具體優(yōu)選的實施例對本發(fā)明作進(jìn)一步描述，但并不因此而限制本發(fā)明的保護(hù)范圍。

如圖2所示，本實施例的APP快速加載方法，步驟為：S1. 智能設(shè)備為APP分配固定的運(yùn)行空間；S2. 初始化運(yùn)行空間；S3. 根據(jù)所需要加載的APP，判斷APP存儲空間中是否存在需要加載的APP的可執(zhí)行文件和配置信息文件，是則跳轉(zhuǎn)到步驟S4，否則跳轉(zhuǎn)到步驟S5；S4. 從APP存儲空間獲取需要加載的APP的可執(zhí)行文件和配置信息文件，并根據(jù)配置信息文件將需要加載的APP的可執(zhí)行文件加載至運(yùn)行空間；S5. 從APP存儲空間獲取需要加載的APP的軟件包，解析并重定位軟件包，生成需要加載的APP的可執(zhí)行文件及配置信息文件，將可執(zhí)行文件加載至運(yùn)行空間，并將可執(zhí)行文件及配置信息文件備份至APP存儲空間。

在本實施例中，步驟S2的具體步驟包括：判斷所述運(yùn)行空間是否已經(jīng)被占用，是則重新初始化所述運(yùn)行空間。

在本實施例中，在步驟S1之后，還包括步驟S1a：根據(jù)所需要加載的APP，判斷所需要加載的APP的可執(zhí)行文件是否緩存在智能設(shè)備中，是則直接運(yùn)行可執(zhí)行文件，否則跳轉(zhuǎn)到步驟S3。在本實施例中，APP的可執(zhí)行文件緩存在智能設(shè)備中是指該APP的可執(zhí)行文件在智能設(shè)備上停止運(yùn)行，但由于沒有新的APP加載，所以該APP的可執(zhí)行文件仍駐留在運(yùn)行空間中。此時，不需要重新初始化運(yùn)行空間，重新獲取該APP的可執(zhí)行文件，只需要直接運(yùn)行該APP在運(yùn)行空間中的可執(zhí)行文件即可。

在本實施例中，步驟S5的具體步驟為：S5.1. 從APP存儲空間獲取需要加載的APP的軟件包；S5.2. 解析軟件包，進(jìn)行軟件包的代碼段與資源段的分離；S5.3. 將需要加載的APP的詳細(xì)信息注冊到智能設(shè)備的軟件管理器中；S5.4. 通過軟件管理器對代碼段進(jìn)行Link和Load操作，生成需要加載的APP的可執(zhí)行文件和配置信息文件；S5.5. 將可執(zhí)行文件拷貝至運(yùn)行空間，運(yùn)行可執(zhí)行文件；S5.6. 將可執(zhí)行文件拷貝和配置信息文件備份至APP存儲空間。在APP存儲空間沒有需要加載的APP的可執(zhí)行文件和配置信息文件時，需要執(zhí)行步驟S5所示的一個完整的APP加載過程，并對生成的可執(zhí)行文件和配置信息文件進(jìn)行備份。軟件包的結(jié)構(gòu)如圖1所示，包括RW、RO以及Resource三個部分組成，其中RW包括RW Data和ZI Data，RO包括Code和RO Data，Resource包括Resource Data。支持程序運(yùn)行的文件有Code、RO Data、RW Data以及ZI Data，因為ZI Data是未初始化的變量，所以其數(shù)據(jù)均為0，只需要程序運(yùn)行之前將ZI Data的數(shù)據(jù)所在區(qū)域清零即可。所以程序運(yùn)行最開始需要加載的文件為Code、RO Data以及RW Data。在通過對軟件包進(jìn)行解析獲取Code、RO Data以及RW Data之后，仍然不能直接運(yùn)行，需要對Code、RO Data以及RW Data進(jìn)行重定位，重定位后的文件即為可執(zhí)行文件。

在本實施例中，APP存儲空間為智能設(shè)備以外的服務(wù)端上的存儲空間。當(dāng)然，如果智能設(shè)備本地存儲空間足夠大，滿足APP軟件包及可執(zhí)行文件和配置信息文件的存儲需求，當(dāng)然也可以將APP存儲空間設(shè)備在智能設(shè)備本地。

在本實施例中，通過對智能設(shè)備的內(nèi)存空間進(jìn)行劃分，專門為APP分配一個固定的運(yùn)行空間，本實施例中假定智能設(shè)備為APP分配的固定的運(yùn)行空間為起始地址為0x0000，大小為512Kb的運(yùn)行空間。在該智能設(shè)備上，所有需要運(yùn)行的APP都在該運(yùn)行空間中運(yùn)行。并且，在每次加載新的APP之前，判斷該運(yùn)行空間是否被占用，是則停止運(yùn)行空間中原有APP的運(yùn)行，并初始化運(yùn)行空間，即在任意時刻，智能設(shè)備上只有一個APP在運(yùn)行。由于為APP配置了固定的專用的運(yùn)行空間，同時，該運(yùn)行空間在任意時刻只有一個APP加載，即APP的可執(zhí)行文件每次加載的首地址是固定的，在該設(shè)備上運(yùn)行的所有APP的可執(zhí)行文件的加載起始地址均為0x0000。對于同一個APP來說，該APP的可執(zhí)行文件每次在該設(shè)備上的加載起始地址均為0x0000，則在每次加載時，該APP的可執(zhí)行文件中的全部需要重定位條目的地址也相同，因此，在將運(yùn)行空間中的可執(zhí)行文件進(jìn)行備份后，在下次需要運(yùn)行該APP時，可直接將備份的可執(zhí)行文件拷貝至運(yùn)行空間中，直接運(yùn)行，而不需要再次進(jìn)行重定位。從而節(jié)省了APP的加載時間，提高了加載效率。

上述只是本發(fā)明的較佳實施例，并非對本發(fā)明作任何形式上的限制。雖然本發(fā)明已以較佳實施例揭露如上，然而并非用以限定本發(fā)明。因此，凡是未脫離本發(fā)明技術(shù)方案的內(nèi)容，依據(jù)本發(fā)明技術(shù)實質(zhì)對以上實施例所做的任何簡單修改、等同變化及修飾，均應(yīng)落在本發(fā)明技術(shù)方案保護(hù)的范圍內(nèi)。