基于用戶行為的流式應用分發系統緩存設計

王輝宇，陽 旺

中南大學 計算機學院，長沙410006

1 引言

近年來，隨著互聯網絡技術的不斷發展和移動終端的技術革新，移動終端的數量與日俱增，呈現出爆炸式增長的趨勢。截至2018年底，我國手機網民規模達8.17億，網民通過手機接入互聯網的比例高達98.6%[1]。用戶手機安裝的應用數量根據使用的手機性能的不同而有所差異。平均每臺高中低端手機中安裝的應用數量分別為59、50和45，而低端手機用戶安裝的APP數量與高中端手機有一定差距，其差距主要來源于手機內部存儲（Random Access Memory，RAM）與外部存儲（Read-Only Memory，ROM）的不同。雖然目前手機外存在不斷地增長，但是對應的應用大小也在逐漸增大（由于業務的擴展使得應用大小增加）。因此單純地增大外存并不能從根本上解決問題，只會增加手機的成本。對于用戶而言，可能只使用應用的部分功能，因此應用大小的增加對于部分用戶而言只會占用存儲空間而并未改善其使用的功能。

針對以上問題，目前主流的方案是應用程序的輕量化設計。以微信小程序和Android Instant app為例的輕量化應用滿足了用戶小需求的及時化場景，并且無需安裝，用完即走。但是輕量化應用值包含了原生應用的部分功能，導致此類應用只能作為對原生APP使用場景的一種補充，而無法替代原生APP。而流式應用分發系統[2]基于透明計算[3]的思想，采用“存儲與計算分離，按需加載”的思想，用于集中存儲和管理移動終端程序，從根本上釋放終端的存儲空間。此外，將應用存儲于服務器中，移動終端無需考慮應用的安裝、維護、管理、升級等問題。但是所有資源均從服務器中獲取，與當前的網絡狀況息息相關，因此移動終端的緩存設計對流式應用分發系統而言至關重要。它通過有限的存儲空間，實現無應用限制的使用。此外合理的緩存替換算法，可以增加緩存命中率，減少網絡訪問次數，加快應用啟動速度。

2 相關工作

流式應用技術的核心是“按需加載，流式執行”，應用資源存儲于遠程服務器，通過流的形式按需加載到終端。文獻[4]提出一種基于Android的流式應用分發系統，應用的分發由服務器管理平臺處理，客戶端無需執行任何操作；文獻[5]在該系統上通過位置信息對其進行應用智能推薦；文獻[6]提出基于情景感知的流式應用分發系統，通過對用戶情景數據的收集，利用極端梯度提升算法（eXtreme Gradient Boosting，Xgboost）給用戶推薦相應的應用。但是流式應用分發系統在網速受限的情況下，加載速度較慢，導致應用啟動緩慢，并且在用戶頻繁使用應用的過程中，客戶端需要不斷地向服務器請求數據，容易導致高并發情況，使得服務器負載加重，而通過無線網絡方式連接互聯網，往往帶來流量消耗的費用增加。因此，如何有效地減少客戶端訪問服務器的頻率成為流式應用分發系統亟待解決的問題。

目前解決此類問題，主要是通過緩存設計將從網絡中加載過來的資源緩存于本地。緩存設計又可分為硬件層面與軟件層面。文獻[7]介紹了一種基于自旋轉移矩隨機存儲器（Spin-Transfer Torque-Magnetoresistive Random-Access Memory，STT-MRAM）的新型非易失性末級存儲，該存儲方案通過新穎地讀出電路增強了STT-MRAM的可靠性與典型的糾錯碼。文獻[8]基于內存駐留數據庫管理系統提出將部分分解的存儲和即時查詢相結合的思想，消除了CPU低效的函數調用，實現了在不犧牲CPU效率的情況下節省帶寬。文獻[9]針對新型的非易失性存儲器需要嚴格地按照順序執行存儲器寫入導致的系統性能降低問題，提出了一種松散順序一致性機制。其主要通過消除事務結束時執行的持久化提交記錄的寫入，以減少開銷，允許通過推測性寫入來放寬事務之間的寫入順序。

除從緩存的結構和性能指標上對緩存進行優化外，還可通過適當的緩存替換策略增加緩存命中率。文獻[10]在移動透明計算系統（Transparent Computing System，TCOS）中設計了基于預取機制的緩存替換策略（Cache Replacement Algorithm based on Prefetching Mechanism，BPF-CR）。該策略設置三個不同等級的主隊列，對不同隊列采取不同的緩存替換策略，當下一級隊列的數據再次被訪問時，將移入上一級隊列中，并設置副隊列用于存儲緩存淘汰的數據。文獻[11]在實現透明手表應用程序的緩存設計時提出了N-LRU策略。該策略結合應用程序的大小、使用概率以及當前網絡帶寬計算策略優先級。

流式應用分發系統中各用戶相互獨立，用戶之間數據不可共享，緩存對象為應用程序。因此挖掘用戶使用應用的行為規律有利于提高流式應用的緩存命中率。文獻[12]通過對Android系統中豌豆莢平臺的數百萬數據進行分析，研究用戶使用應用的行為過程，如用戶的偏好、用戶對應用的選擇、應用程序的生命周期等。文獻[13]關注于移動應用程序之間的相互依賴性，通過數據挖掘算法對應用程序進行分類。由此可知，用戶使用應用的行為具有一定的規律性。文獻[14]通過對應用程序使用日志數據進行分析，預測應用的使用情況。

流式應用分發系統中緩存策略的選擇需要考慮用戶行為、應用使用大小等問題。由于客戶端在達到緩存替換策略的觸發條件時仍能進行緩存，因此緩存替換策略的執行時間應在緩存溢出前完成，故算法的復雜性可能會影響到應用的啟動速度。

3 總體框架設計

3.1 框架介紹

流式應用分發系統采用的是C/S架構，如圖1所示。服務器端主要是應用資源存儲模塊和應用推送模塊，客戶端主要是流式加載模塊、緩存模塊和緩存替換策略模塊。客戶端和服務器端通過無線網絡進行通信。

圖1 流式分發系統框架

服務器端的功能主要是存儲應用資源，管理用戶個人信息，并且根據用戶的需求將應用推送給客戶端。在服務器端和客戶端之間，通過無線網絡進行交互，其中主要有兩部分資源的交互：第一部分為網絡文件系統（Network File System，NFS）[15]，應用資源通過NFS加載網絡資源，客戶端在通過NFS訪問服務器資源時，如同訪問本地資源；第二部分為文本通信，主要通信的內容是待安裝或卸載的應用程序少量信息，如文件名，采用的是消息隊列遙測傳輸（Message Queuing Telemetry Transport，MQTT）協議[16]，它是一個發布/訂閱者模式的協議，并且通信消耗的網絡流量幾乎可以忽略不計。

客戶端主要是流式加載來自服務器的資源，在本地進行安裝運行，緩存是在流式加載的過程中將資源保存到本地主存中，進行持久化存儲，緩存替換在緩存大小達到一定值后會被觸發，將優先級低的緩存塊替換。緩存替換算法的優劣直接影響應用緩存的頻率，從而影響客戶端流量的消耗、應用啟動的時延等。

3.2 系統實現原理

在原生的Android系統中，應用被下載之后首先會被拷貝到/data/app/下（系統級應用安裝在/system/app/下），并通過監聽機制inotify監聽該目錄。而在流式應用分發系統中，APK文件存儲于服務器，因此在本地創建一個與/data/app/同級的新目錄/data/metaosapp/，并通過NFS實現掛載。由于metaosapp文件夾資源來自于服務器，當該文件內容發生變化，客戶端只有在主動更新文件內容時文件屬性才會發生變化，此時才能被inotify監聽到。因此，本文通過MQTT實現客戶端與服務器之間的通信，當服務器向該掛載目錄中刪除或添加應用時，通知客戶端更新目錄，從而執行安裝卸載命令。客戶端/data/data/目錄用于存儲用戶使用應用的信息，同上，創建新目錄/data/metaosdata/并實現網絡化。

3.3 緩存實現原理

流式應用分發系統的緩存設計主要是為了緩存客戶端通過NFS從服務器中加載的資源，而在Linux內核中，提供了FS-Cache[17]用于實現網絡文件系統緩存。Android操作系統基于Linux內核，因此本文通過FSCache實現流式應用分發系統緩存設計。

FS-Cache在文件系統緩存中只是作為一個緩存接口，其實際的緩存操作交由緩存后端CacheFiles[18]實現，通過CacheFiles管理緩存文件和目錄，可以將從網絡文件系統中加載的資源永久緩存于本地。CacheFiles緩存后端主要包括cachefilesd守護進程和cachefiles模塊。cachefilesd用于cachefiles模塊的管理，如初始化相關信息、監聽目錄文件等。cachefiles模塊則通過接收cachefilesd指定執行相關操作，如目錄文件創建、緩存生成等。

圖2為流式應用緩存實現原理。客戶端首先啟動應用程序，然后CacheFiles判斷緩存是否命中與一致性，若緩存命中且客戶端與服務器緩存資源一致，則直接從緩存中獲取資源，否則，通過NFS按需加載，同時將從服務器加載的資源緩存于本地。當緩存空間不足時，則執行緩存替換操作，當應用啟動資源加載完畢后，應用便可正常使用。

圖2 流式應用緩存實現

CacheFiles緩存替換策略的觸發通過設置三組參數實現，如表1所示。與傳統的緩存空間設置不同，Cache-Files緩存替換策略并非在緩存溢出時觸發，而是在緩存空間使用率達到某一條件時觸發，直至滿足另一條件時結束。觸發條件主要由兩部分組成——實際緩存空間大小與文件存儲數量。并且通過bstop/fstop參數的設置，可以使得緩存剔除操作與緩存生成同時進行，以避免等待緩存替換所花費的時間。

表1 緩存替換策略觸發參數

緩存空間只是客戶端存儲空間的一部分，緩存替換的觸發除了達到緩存空間上限之外，同時還考慮了客戶端的剩余存儲空間。在滿足客戶端可用存儲空間足夠時，會自適應調節緩存空間的總大小，以提高客戶端存儲空間的利用率和緩存替換算法的命中率。其主要是通過調節上述三組參數的數值以控制緩存剔除的開啟與關閉。

4 緩存替換策略

4.1 用戶行為預測策略

本文緩存設計的對象為應用程序，而應用的使用者為用戶，根據調研發現，用戶使用應用時具有主觀意識，而CacheFiles默認使用的最近最少使用策略（Least Recently Used，LRU）僅考慮緩存塊的訪問時間，因此無法有效地提高緩存命中率。而本文中，緩存塊的主體是應用程序，主體的使用者是用戶，因此可以根據用戶的使用行為預測應用的使用時間，故本文提出了用戶行為預測（User Behavior Prediction，UBP）緩存替換策略。該策略通過記錄應用啟動時間并分析預測應用下次的使用時間。

UBP緩存替換策略從時間預測上分為兩類：一類是預測當前可能會運行的應用程序，因為存在部分應用，在使用時通常會和某些應用同時使用，所以可以根據其中某一應用的啟動預測另一應用可能會被使用；另一類是預測應用下次使用時間，通常用戶會在某種特定的場景下使用某些應用。根據這些特點，對歷史記錄中各時間點應用的使用情況進行分析，替換緩存中預測時間距當前時間最久的應用。

UBP策略將應用的使用時間分為兩部分：一個是橫向時間軸，表示時間點，單位毫秒；另一個是縱向時間軸，表示天數，單位日。縱向的時間軸用于預測事件在某時間點的發生概率或可信度。對所有時間點進行加權平均，得到應用的預測值。由于存在部分應用得到的預測值相同，如某些應用使用時間完全相同，因此預測值并不能完全區分應用的優先級，故UBP策略除了對應用進行預測，同時還對應用的使用時長進行統計。如圖3所示，綜合四種子策略的優先級值，得出UBP策略的CBP（Combined Behavior Prediction，CBP）值，用于量化該應用緩存在不久將來使用的可能性。

圖3 UBP緩存替換策略

4.1.1 關聯性規則

為了挖掘用戶在不同時間使用的應用之間的關聯性，本文采用加權頻繁項集算法[19]挖掘不同時間點應用之間的關聯性。算法核心是通過當前時間點正在運行的應用預測將可能使用的應用。

應用關聯性挖掘的是正在運行程序的應用與緩存中應用的關聯性，因此對于數據集中的頻繁項只需要包含當前正在運行的應用或緩存中的應用。每個頻繁項的使用時間不同，因此對應用的關聯性采取加權頻繁項集挖掘。

算法1關聯性規則算法

輸入：所有時間點集合T←{T1,T2,…,Tm}，各時間點集合Tt←{D1,D2,…,Dn}。

輸出：關聯性規則優先級R。

1.N←0

2.for t←1 to m do

3.提取某時間點t的歷史數據作為數據集Tt，對每個項集進行處理，只保留相關應用（運行中的應用和緩存中的應用），得到L1

4.根據最小支持度min sup篩選L1得到C1，并從C1中提取兩個集合Su與Sc，其中Su←{fi,fi+1,…,fj}表示C1中運行的應用集合，Sc←{fx,fx+1,…,fy}表示C1中緩存的應用集合

5.通過C1將Su和Sc元素組合得到L2，并根據最小支持度得到C2

6.if L2表不為空then

7. Rt←{confidence(fi?fk)|fi∈Su},fk為緩存中的應用，則fk在時間點t的關聯性規則值為Rt中的最大值Rt

8.R←R+Rt，N←N+1

9.end if

10.end for

11.R←R/N

12.Rc表示當前時間點的關聯性規則算法優先級，R取R和Rc中的最大值

13.輸出R

如算法1所示，首先對數據集進行掃描，得到頻繁一項集L1，再根據最小支持度min sup得到一階候選項集C1，將存在于C1中的運行應用和緩存應用組合，重復前面的步驟得到頻繁二項集L2以及二階候選項集C2，通過C2求出每個運行中應用對緩存應用的置信度，取其最大值。根據以上步驟，對所有時間點的最大置信度取平均值。為保證當前時間點具有更高的信任度，再將求得的平均值和當前時間點的最大置信度相比，將兩者中的較大值作為關聯性規則優先級。

4.1.2 時間點預測

關聯性規則只能用于預測即將要被使用的應用，但是緩存中大部分的應用可能并不會立刻被使用，因此還需對緩存中的應用下次使用的時間進行預測。

時間點預測主要通過分析歷史記錄中各時間點使用應用的分布情況，得出各時間點的使用概率。由于某時間點的應用使用概率需要同時考慮使用次數以及使用時間，本文采用LRFU（Least Recently Frequently Used）策略計算應用各時間點使用概率。緩存應用的使用時間并不僅限于一個時間點，通過以上計算可以得到緩存應用在多個時間點的概率。不同時間點具有不同的權值，而應用使用時間的預測為某具體時間點，多個時間點之間的優先級值不是線性疊加關系。本文在得到緩存應用在各時間點概率與該時間點權值乘積時，取其中的最大值作為預測回歸點，通過加權平均的方式計算時間點預測的優先級。時間點預測算法優先級計算過程如下：

（1）緩存應用近期使用總數據集U，時間點集合

T={t1,t2,…,tn}；

（2）根據歷史數據集U得出緩存應用各時間點的概率P(t),t∈T；

（3）結合各時間點的權值函數ψ(t)，得出應用在各時間點的優先級H(t)=ψ(t)P(t),t∈T；

（4）選擇H中的最大值作為預測回歸點，此時的時間點為回歸時間點tk；

（5）對所有時間點進行加權平均，回歸點權重為ζ，剩余所有時間點權重均為，剩余時間點集合為T′=T{tk}，因此T=

4.2 A-RBFS緩存替換策略

客戶端可以后臺運行應用，因此當前時刻正在運行的程序可能存在多個，并且當緩存空間較大時，緩存中存在近期內未使用的應用，而UBP策略是基于用戶行為的緩存替換策略，只有短期內的行為才具有信服力，故本文在UBP策略的基礎上提出了A-RBFS策略。其根據應用最近一次使用時間，將緩存應用按時間順序分為四個區域，如圖4所示，分別是Recently-Block、Behavior-Block、Frequency-Block和Size-Block，只有當該區域后面所有的緩存區域內緩存被替換完之后才會對該區域緩存塊進行緩存剔除。不同區域的緩存塊采用不同的緩存策略：Recently-Block表示短時間內使用的緩存應用，采用LRU策略，最久未使用的緩存應用將被替換；Behavior-Block表示近期內被使用緩存應用，采用UBP策略，根據計算得到的CBP值進行緩存替換；Frequency-Block表示短期未使用的緩存應用，并可根據時間再劃分成多個Frequency-Block，采用最不經常使用（Least Frequently Used，LFU）策略，將使用頻率最低的緩存應用替換；Size-Block表示長期未使用的緩存應用，采用Size策略，根據緩存應用的大小，替換最大的緩存。

圖4 A-RBFS區域分布

算法2描述了A-RBFS的主要流程，根據應用的使用時間將應用分配到不同的Block中，按照順序依次將Block內所有應用加入剔除列表，直到剔除列表應用總大小大于緩存策略待釋放的緩存空間大小，并對當前Block采用對應的緩存替換策略，將部分低優先級應用添加到剔除列表。

算法2 A-RBFS緩存替換策略

輸入：待釋放的緩存空間大小Χ，根據時間劃分的有序集合B←{B1,B2,B3,B4}，緩存應用集合Sc。

輸出：替換的緩存應用集合S。

1.for i←1 tocard(Sc)do

2.將Sc中每個元素根據最近一次使用時間存入B的子集中

3.end for

4.k←0

5.while k＜4 do

6. if(Χ＞?(Bi))then△ ?(Bi)表示Bi中所有應用的總大小

7. Χ←Χ-?(Bi)

8. else

9.exit

10.end if

11.k←k+1

12.end while

13.將Bk前的應用添加到S集合中

14.對Bk中的應用進行不同的緩存替換策略，k=1采用Size策略，k=2采用LFU策略，k=3采用UBP策略，k=4采用LRU策略

15.將替換的應用加入到S集合

16.輸出S

5 實驗

5.1 緩存有效性測試

本文實驗設備主要包括客戶端、路由器和服務器，客戶端通過Wi-Fi接入路由器，服務器與路由器處于同一網段，客戶端通過NFS掛載到服務器。客戶端、路由器和服務器的配置如下：

（1）客戶端為LG Nexus5，處理器為高通驍龍800（MSM8974），RAM容量2 GB，ROM容量16 GB，搭載基于Android 4.4的流式應用分發系統。

（2）路由器為FW300R，300 Mb/s無線傳輸速率，符合IEEE 802.11n標準。

（3）服務器采用戴爾OptiPlex 3010商務臺式電腦，處理器為i5-3470，主頻3.2 GHz，8 GB內存和1 TB 7 200轉機械硬盤，搭載Ubuntu 16.04操作系統。

通過對流式應用分發系統緩存的設計，使得應用啟動資源的獲取方式分為兩種：一種是從遠程服務器中獲取，稱之為冷啟動；另一種是從本地緩存中獲取，稱之為暖啟動。本文從Android應用市場中選取不同大小及類別的應用，用于測試流式應用分發系統中冷啟動與暖啟動情況下的流量消耗和啟動延時。表2所示為應用程序在冷啟動情況下的流量消耗和啟動延時。由表中數據可知，在冷啟動狀態下，應用需要加載部分用于啟動的必備資源，而資源僅存在于服務端，因此只能通過網絡加載，并且在加載部分必備資源前應用無法正常啟動，而應用啟動的時間則取決于當前的網速。這不僅導致流量消耗增加，同時還影響用戶體驗。在暖啟動狀態下，資源存在于本地緩存中，客戶端只需要判斷緩存一致性，消耗的流量較少，并且應用的啟動時延小于0.1 s，用戶無法感知。但是緩存并不長存于客戶端中，合適的緩存替換策略能夠增加緩存命中率，減少緩存替換次數，從而使得客戶端流量消耗和應用延時啟動次數減少。

表2 流式應用分發系統冷啟動各指標狀況

5.2 緩存替換策略性能測試

為了選取合適的緩存替換策略，本文對LFU、LRU、Size、UBP、UBP-L以及A-RBFS策略緩存性能進行測試和分析，主要測試流量消耗、命中率、緩存替換次數三方面的指標。其中，A-RBFS策略結合了LRU、UBP、LRU與Size策略。由于UBP策略只關注于分析用戶行為進行預測，而未考慮當前的客戶端應用程序的運行狀態，因此除以上幾種策略外，還新增了UBP-L（User Behavior Prediction-Last）策略。該策略在UBP的基礎上增加對當前客戶端應用程序運行狀態的考慮，即只考慮ARBFS策略中的Recently-Block與Behavior-Block。實驗數據通過Android API提供的接口，獲取志愿者60天內的應用使用記錄，志愿者由各年齡段各職業人員組成。在應用使用時，通過網絡加載的資源緩存于本地后還將緩存于客戶端內存中，本實驗中將客戶端運行內存大小設為1 GB。

應用市場中應用品類繁多，應用大小各不相同，為保證大部分應用能緩存于客戶端，且緩存中能存儲若干個應用，實驗中采取的緩存空間大小從800 MB開始，緩存開始剔除因子為0.8，結束剔除因子為0.6，即當剩余緩存空間小于20%時開始進行緩存替換，直到剩余緩存空間大于40%時剔除結束。

5.2.1 緩存流量消耗測試

圖5 緩存空間大小和流量消耗關系

圖5為不同的緩存替換策略在不同的緩存空間大小中客戶端流量消耗情況。在緩存空間較小時，客戶端中緩存應用數量較少，需要頻繁地進行緩存替換，此時流量消耗較大。LFU與A-RBFS策略能將較為頻繁的應用緩存到本地，故性能優于其他緩存替換策略，但是當緩存空間增大時，LFU策略不能在短時間內適應用戶的興趣變化，故性能提升較小。A-RBFS策略與其他五種策略相比，隨著緩存空間不斷增大，流量消耗最先達到平衡，而在平衡狀態下緩存空間的增大對減少流量消耗的提升相對較少。在A-RBFS策略流量消耗達到平衡狀態時，緩存空間大小為1 000 MB，流量消耗方面ARBFS策略比LFU策略減少了43.07%，比LRU策略減少了41.50%，比Size策略減少了81.79%，比UBP策略減少了75.31%，比UBP-L策略減少了50.59%。

圖6為緩存空間大小為1 000 MB情況下客戶端每周流量的消耗情況。其中LFU、LRU、Size、UBP、UBP-L與A-RBFS策略平均每周流量消耗分別為1.73 GB、1.64 GB、5.15 GB、3.93 GB、2.51 GB、0.97 GB。顯而易見，A-RBFS策略平均每周的流量消耗明顯小于其他緩存替換策略，且浮動范圍較小，其日均流量消耗僅為138.07 MB，在當前的移動互聯網情況下，仍處于可接受范圍之內，并且在即將到來的5G時代中，流量消耗費用將進一步降低。

圖6 一周內用戶應用使用流量消耗

5.2.2 緩存替換次數測試

圖7所示為不同緩存替換策略在不同的緩存空間大小中緩存替換次數關系。由于緩存的部分命中率和完全命中率只能說明應用緩存可能長期存在于緩存中，以及流式加載中應用加載的方式主要是從本地獲取，并不能作為衡量緩存替換策略的優劣，因此本文選用緩存替換次數比較各替換策略性能。在緩存空間小于1 000 MB時，LRU策略緩存替換次數高于LFU策略，而當緩存空間大于1 000 MB時，LFU、LRU和UBP-L策略性能持平，Size策略由于不常使用的大小較小的應用長存于緩存中，導致實際可用緩存空間較少，使得緩存替換次數相對較高，UBP策略考慮正在運行的應用程序，導致頻繁的緩存替換，并且在任何大小的緩存空間下，A-RBFS策略緩存替換次數都明顯小于其他五種緩存策略。

圖7 緩存空間大小與緩存替換次數關系

圖8為緩存空間大小為1 000 MB情況下客戶端每周緩存替換的次數情況。其中LFU、LRU、Size、UBP、UBP-L和A-RBFS策略平均每周緩存替換次數分別為7.36、6.63、22.63、17.50、10.75、2.25。同樣，A-RBFS策略的緩存替換次數明顯小于其他五種策略，并且日均替換次數為0.32。

圖8 一周內客戶端緩存替換次數

6 結束語

本文通過實現流式應用分發系統的緩存設計，節省了客戶端流量消耗，提高了應用啟動速度，增強了用戶體驗。在緩存替換策略上，本文提出了根據用戶行為分析，將歷史時間分為橫向的時間點和縱向的天數時間軸，預測應用的使用時間，剔除預測可能最后使用的緩存應用。實驗結果表明，A-RBFS能夠有效地減少流量的消耗和緩存替換次數。

應用啟動時主要獲取的是應用的布局、圖片和音頻等，這些資源存在于APK中而沒有對其壓縮，因此未來工作和研究的主要方向是分離出APK中的所有應用資源，對現有的Android操作系統安裝過程中生成的所有文件直接進行掛載而無需安裝，并對影響應用啟動的所有資源進行緩存設計。