楊嘉成，彭 鑫，趙文耘

1.復旦大學 軟件學院，上海 201203

2.復旦大學 上海市數(shù)據(jù)科學重點實驗室，上海 201203

1 引言

網(wǎng)絡通信能力在為移動應用帶來強大支持的同時，也給移動用戶帶來了一些潛在的問題。首先，移動應用訪問網(wǎng)絡的過程會消耗數(shù)據(jù)流量，造成了用戶的經(jīng)濟負擔。其次，移動設備電池電量有限，而網(wǎng)絡通信是移動應用中消耗電量最多的操作之一。研究表明，移動應用在非空閑狀態(tài)下超過40%的電量消耗來自網(wǎng)絡通信，其中由超文本傳輸協(xié)議（hypertext transfer protocol，HTTP）操作所導致的電量消耗占近80%[1]。最后，移動應用在通過網(wǎng)絡獲取數(shù)據(jù)并進行本地處理的過程中，網(wǎng)絡傳輸可能由于網(wǎng)絡狀況不佳或數(shù)據(jù)傳輸量大而成為應用響應的瓶頸，影響用戶體驗。

緩存作為一種經(jīng)典的技術(shù)手段，可以在移動設備端有效地緩解上述問題。安卓應用中的網(wǎng)絡訪問通常通過調(diào)用HTTP客戶端應用編程接口（application programming interface，API）實現(xiàn)，其中常見的HTTP客戶端包括HttpURLConnection、Apache HTTP Client和OkHttp等。但在這些HTTP客戶端中，有些客戶端本身缺乏緩存機制（如Apache HTTP Client），其他一些客戶端（如OkHttp）雖然有內(nèi)部的緩存支持，但仍存在以下問題：（1）緩存需要開發(fā)者在代碼中顯式地啟用，一些開發(fā)者由于疏忽而沒有啟用；（2）HTTP客戶端API中的緩存處理抽象層次較高，無法針對特定應用需求進行優(yōu)化處理，導致緩存效果不佳[2]。

由于上述原因，在實際開發(fā)中應用開發(fā)者往往需要自行定義并實現(xiàn)自己的緩存處理策略，這可能導致兩方面的問題：（1）未能充分利用緩存來優(yōu)化應用性能；（2）過度使用緩存或不及時清理緩存內(nèi)容。后者會導致應用緩存占用過多的存儲空間，以及緩存管理消耗較多的電量[3]，因此也會影響移動設備和應用的整體性能。

當前已經(jīng)有一些研究工作關(guān)注于移動應用的緩存問題，但這些工作主要關(guān)注于移動端網(wǎng)絡瀏覽器的HTTP緩存表現(xiàn)[4-6]。有些研究針對應用的HTTP緩存問題進行檢測[7]，但策略比較簡單且沒有考慮安卓應用的特點，因此無法發(fā)現(xiàn)其中所包含的深層問題，比如應用緩存占用的設備空間、應用緩存的有效性等。為了實現(xiàn)細粒度的安卓應用緩存缺陷檢測，發(fā)現(xiàn)與特定安卓應用特點相關(guān)的HTTP緩存問題，本文提出并實現(xiàn)了一種基于動態(tài)分析的安卓應用HTTP緩存缺陷檢測方法。該方法可以針對安卓應用的APK（安卓應用安裝包，Android package）文件進行插裝，使其具有在運行時監(jiān)測并記錄與HTTP緩存相關(guān)的行為和數(shù)據(jù)的能力。該方法通過安卓應用自動化測試工具對插裝后的應用進行自動運行同時收集運行日志，并基于日志分析發(fā)現(xiàn)應用中的HTTP緩存缺陷并定位所在位置。

為了驗證該方法的有效性，利用基于該方法所實現(xiàn)的分析工具對當前安卓應用市場上的25個安卓應用進行了自動化分析。分析結(jié)果表明，所提出的方法適用于當前應用市場上的大多數(shù)應用。同時，該方法能夠有效發(fā)現(xiàn)安卓應用中存在的緩存缺失、緩存空間無限增長和緩存冗余等問題。針對所發(fā)現(xiàn)的這些問題，本文還分析了出現(xiàn)這些問題的原因以及解決的思路。

2 背景

安卓應用通常是用Java語言編寫的，打包成APK文件以供安裝使用。從應用源代碼到打包好的APK文件，一般要經(jīng)過以下幾個階段的轉(zhuǎn)換：首先，應用源代碼被編譯成Java類文件；然后，這些類文件被安卓軟件開發(fā)工具包（software development kit，SDK）中的dx工具轉(zhuǎn)換為.dex文件，這種文件是可以運行在安卓的Dalvik虛擬機上的可執(zhí)行字節(jié)碼；最后，這些.dex文件與聲明文件、相關(guān)的資源文件（如圖片、用戶界面布局文件）一起被打包成APK文件，添加簽名后就可以發(fā)布使用了。

安卓官方提供了兩組HTTP客戶端API：Http-URLConnection和Apache HTTP Client。其中，前者是目前官方建議開發(fā)者使用的HTTP客戶端API；后者在安卓API 22級之后已經(jīng)廢棄，但由于一些較早開發(fā)的代碼中仍有使用，出于兼容性的考慮，安卓對這部分代碼保留了支持。此外，還有一些第三方HTTP客戶端，如OkHttp，可供安卓開發(fā)者使用，這些HTTP客戶端一般也都是基于HttpURLConnection實現(xiàn)的。借助上述HTTP客戶端API，開發(fā)者可以非常方便地編寫代碼，獲取HTTP資源。但值得注意的是，這些HTTP客戶端本身要么缺少緩存機制接口供開發(fā)者使用，要么雖然提供了緩存支持，但可能需要開發(fā)者自行開啟，并且緩存處理較為簡單。

安卓設備中包含兩個存儲文件的區(qū)域：內(nèi)部存儲和外部存儲。內(nèi)部存儲是設備內(nèi)部提供的非易失性內(nèi)存，外部存儲一般是移動存儲介質(zhì)，如安全數(shù)碼卡（secure digital memory card，SD）。通常來講，安卓設備的內(nèi)部存儲在應用運行時是始終可用的，各應用的存儲空間相互隔離，應用無法訪問其他應用在內(nèi)部存儲中保存的文件；在用戶卸載某個應用后，系統(tǒng)將移除該應用所保存的文件。而安卓設備的外部存儲并不始終可用，在外部存儲中保存的文件是全局可讀的；用戶卸載某個應用時，只有保存在某些特定路徑（通過Context類中的getExternalFilesDir方法獲得）下的文件才會被系統(tǒng)刪除，應用保存在其他路徑下的文件并不會被刪除。安卓系統(tǒng)不會定期清理內(nèi)部存儲和外部存儲中緩存文件夾下的文件，只有在內(nèi)存不足時才會刪除內(nèi)部存儲中的緩存文件。

3 方法和實現(xiàn)

3.1 方法

本文提出了一種基于動態(tài)分析的安卓應用緩存缺陷自動檢測方法，該方法的概覽如圖1所示。

Fig.1 Overview ofAndroidApp HTTP cache detection圖1 安卓應用HTTP緩存檢測概覽

首先，方法對安卓應用的APK文件進行插裝改造。這一過程會向原始安卓應用中引入一個運行時庫，生成的插裝后的應用具有在運行時監(jiān)測并記錄與HTTP緩存相關(guān)的行為和數(shù)據(jù)的能力。這些數(shù)據(jù)包括：（1）HTTP響應頭部信息（主要是緩存相關(guān)的信息，如失效時間、緩存控制和上次被修改時間）及具體內(nèi)容；（2）訪問本地文件的絕對路徑；（3）文件訪問時間；（4）緩存文件容量；（5）緩存文件訪問；（6）被刪除文件的絕對路徑。

改造過程中引入原始應用中的運行時庫負責在應用運行時獲取上述數(shù)據(jù)，該運行時庫主要有三大職責：（1）記錄應用的文件訪問和刪除操作的相關(guān)信息；（2）監(jiān)測應用中的HTTP訪問，記錄HTTP響應的頭部信息（統(tǒng)一資源定位符、過期時間、緩存控制和上次修改時間）以及響應的具體內(nèi)容后，再將HTTP響應內(nèi)容返回給應用中原本的調(diào)用，從而不會對應用的正常運行產(chǎn)生影響；（3）應用啟動時的運行時庫初始化處理，包括設置應用包名，從文件系統(tǒng)中恢復該應用在之前運行時獲得的數(shù)據(jù)記錄等，以及在應用退出時將內(nèi)存中的數(shù)據(jù)記錄持久化到設備文件系統(tǒng)中。

接著，改造后的安卓應用被安裝到安卓設備上以供運行。在改造過的應用被啟動后，方法借助安卓自動化測試工具（如Monkey、Robotium等），自動化地向安卓設備發(fā)送用戶事件流。用戶事件包括點擊事件、觸屏事件、手勢操作和按鍵操作等。通過自動生成的用戶事件流，模擬用戶使用應用的過程，產(chǎn)生原始應用邏輯中訪問文件、獲取網(wǎng)絡資源的操作。

在應用運行時，被引入的運行時庫會實時監(jiān)測并收集前述的與HTTP緩存相關(guān)的行為和數(shù)據(jù)，進行一定的處理整合后，生成運行日志。日志內(nèi)容包括：（1）應用中的HTTP請求的次數(shù)；（2）導致不完善緩存發(fā)生的HTTP請求在代碼中的位置；（3）每個緩存文件的訪問次數(shù)以及緩存文件總訪問次數(shù)；（4）應用占用的設備內(nèi)部存儲和外部存儲空間的大小變化；（5）應用運行過程中刪除的文件的文件名，以及這些文件在刪除前的容量。

運行時庫通過在應用中監(jiān)測HTTP響應及其內(nèi)容來分析獲得上述日志中的第1、2部分內(nèi)容。圖2展示了運行時庫對HTTP響應進行攔截并分析其內(nèi)容的過程。分析邏輯共分5個步驟：（1）當在應用中發(fā)生一次HTTP訪問時，運行時庫會根據(jù)這次訪問的網(wǎng)絡資源的統(tǒng)一資源定位符（uniform resource locator，URL）查詢在此之前應用是否訪問過相同URL上的內(nèi)容；（2）如果訪問過，那么分析程序會接著查找數(shù)據(jù)記錄中最近的對應于該URL的緩存控制信息和緩存過期時間信息，否則結(jié)束；（3）如果緩存并未過期，那么說明應用的HTTP緩存不完整，運行時庫會將這次HTTP通信在程序代碼中的位置記錄到日志中；（4）如果緩存過期，運行時庫會查找獲取數(shù)據(jù)記錄中最近的對應于該URL的緩存內(nèi)容，并將獲得的緩存內(nèi)容與此次HTTP訪問獲得的內(nèi)容進行對比；（5）如果對比發(fā)現(xiàn)兩者內(nèi)容并無差別，那么說明存在緩存控制設置過于保守的問題，運行時庫會將這次HTTP通信在程序代碼中的位置記錄到日志中，否則直接結(jié)束。整個過程不會干擾應用獲取HTTP響應的內(nèi)容，因此也不會影響應用的正常運行。

最后，方法對運行獲得的日志記錄進行分析。分析的內(nèi)容主要包括：（1）應用緩存的完整性（也就是說，是否存在從網(wǎng)絡中請求之前訪問過并且還未過期的資源）；（2）應用緩存控制設置是否保守；（3）應用的緩存對設備內(nèi)部和外部存儲的空間占用狀況；（4）冗余緩存文件（未被使用過的緩存文件）數(shù)量，以及這些文件占所有緩存文件的比例；（5）上次被訪問時間在某一時刻之前的緩存文件的數(shù)量，以及這些文件占所有緩存文件的比例；（6）緩存文件平均訪問次數(shù)；（7）應用對緩存空間占用的控制。對于（1）、（2）兩部分內(nèi)容，運行時庫在運行時已經(jīng)在日志中進行了記錄；對其他五部分內(nèi)容，分析程序?qū)⒎謩e讀入分析所需的運行日志中內(nèi)容，然后按要求輸出分析結(jié)果。需要注意的是，很多應用為了程序健壯性的需要，會在運行時生成一些臨時文件和備份文件（如.bkp文件）。分析程序會判斷被刪除文件的類型，剔除備份文件對分析結(jié)果的影響。

Fig.2 Interception and analysis process of HTTP response圖2 HTTP響應攔截分析過程

3.2 實現(xiàn)

本文實現(xiàn)了一個自動化的安卓應用代碼插裝工具，該工具的輸入是APK文件，文件中包含的Dalvik字節(jié)碼保留了應用的程序結(jié)構(gòu)。插裝過程中，工具會自動對Dalvik字節(jié)碼進行分析和重寫，引入實現(xiàn)的運行時庫，使應用具有3.1節(jié)中描述的運行時HTTP緩存缺陷動態(tài)監(jiān)測的能力。

圖3是應用程序改造的概覽。圖中白色部分代表原本的安卓應用代碼，灰色部分是本文的自動化改造工具所引入的代碼。dex2jar是一個可以實現(xiàn)安卓中的.dex文件和Java中的.class之間的相互轉(zhuǎn)換的工具。本文實現(xiàn)的工具借助dex2jar，對APK文件中的Dalvik字節(jié)碼進行轉(zhuǎn)換后，對類文件進行操作，引入運行時庫。對每一個activity類，改造工具會向其生命周期函數(shù)（onCreate,onResume和onStop方法）中引入額外的代碼，以在進入應用時對緩存監(jiān)控進行初始化，并在離開應用時結(jié)束緩存監(jiān)控，更新未持久化的數(shù)據(jù)記錄。這部分改造的方法與CollaDroid[8]中介紹的程序改造方法類似。

工具隨后對應用所有類文件中每個方法的每一條語句進行遍歷，查找與文件操作相關(guān)的語句和與HTTP資源訪問相關(guān)的語句。

與文件操作相關(guān)的語句包括那些調(diào)用Java中的File類的構(gòu)造函數(shù)、FileInputStream類的構(gòu)造函數(shù)、FileReader類的構(gòu)造函數(shù)、RandomAccessFile類的構(gòu)造函數(shù)，以及File類中的delete方法的語句。本文工具會在使用上述構(gòu)造函數(shù)的語句之前引入額外的代碼，調(diào)用運行時庫中的方法，實現(xiàn)對緩存文件狀態(tài)的監(jiān)控。

與HTTP資源訪問相關(guān)的語句包括那些調(diào)用java.net.HttpURLConnection類中的getInputStream方法和調(diào)用org.apache.http.client.HttpClient接口中的execute方法的語句。調(diào)用上述兩種方法，程序會獲取網(wǎng)絡中特定URL上的資源。圖4展示了一個對調(diào)用getInputStream方法的代碼進行改造的例子。請注意，這里為了方便理解，展示的是源代碼，應用程序改造實際上是在Dalvik字節(jié)碼上進行的。改造工具將使用運行時庫中的方法來替換原始應用中相關(guān)的方法調(diào)用，從而在不影響應用正常使用的情況下實現(xiàn)對應用中發(fā)生的HTTP訪問的監(jiān)測。

4 實驗和分析

4.1 實驗設置

Fig.3 Overview of program transformation圖3 應用程序改造概覽

Fig.4 Example of program transformation圖4 程序改造示例

本文實現(xiàn)的APK改造工具是通過Java語言開發(fā)的，可以運行在任何安裝了Java運行時環(huán)境的機器上。使用這一工具對原始的APK文件進行改造，然后安裝在安卓設備上，并使用安卓SDK提供的Monkey測試工具模擬應用運行以獲取數(shù)據(jù)。實驗中用到的安卓設備包括一臺三星Galaxy S4（Exynos 5410 CPU，Imagination PowerVR SGX544 MP3 GPU，2 GB RAM，16 GB內(nèi)存）和一臺紅米Note 4（聯(lián)發(fā)科Helio X20，Mali-T880 MP4 GPU，3 GB RAM，64 GB內(nèi)存）。

4.2 適用性

從安卓市場上下載了25款下載量較高，并且網(wǎng)絡通信比較頻繁的應用（如新聞客戶端、在線音樂客戶端）的APK文件，并使用本文所實現(xiàn)的自動化改造工具對這些APK文件進行自動化改造。實驗發(fā)現(xiàn)，改造單個APK文件的耗時一般不超過30 s，并且改造過程本身都可以順利完成，生成可以安裝到安卓設備上的可用APK文件。改造后的APK文件中.dex文件的大小比改造前增加了0.4%到2.1%，平均增加了1.3%。由于APK文件中還會包含許多資源文件（如圖片、布局文件等），.dex文件容量一般占不到APK中所有文件總?cè)萘康囊话?，因此改造對APK文件大小的影響是微不足道的。

隨后在設備上運行這些改造過的應用，發(fā)現(xiàn)其中有6款應用無法正常運行。這些無法正常運行的應用通常表現(xiàn)為閃退，進入應用后長時間停留在初始界面沒有響應，應用提示當前應用不是官方版本后強制退出等。通過分析控制臺日志信息等方式，這些應用之所以無法運行，是因為應用開發(fā)者在應用內(nèi)設置了一些自我保護機制，使得被第三方修改過的應用無法正常運行。

實驗所使用的應用類型多種多樣，包括新聞、音樂、購物等，與一些關(guān)注于移動瀏覽器應用緩存檢測的工作[4-6,9]相比，本文所提出的方法具有更廣泛的適用性。

在改造過程中發(fā)現(xiàn)有一些應用使用Apache HTTP客戶端來訪問HTTP資源，目前的安卓官方開發(fā)文檔中已經(jīng)建議開發(fā)者不要再使用這種方式。對應用所使用的具體HTTP客戶端的檢測是先前的緩存檢測工作[7]所無法做到的，這也是本文方法的優(yōu)勢之一。根據(jù)方法調(diào)用所在的類所處的包的名稱，發(fā)現(xiàn)其中大多數(shù)調(diào)用是在應用使用的一些第三方庫中，只有兩款應用是在自己開發(fā)的代碼中使用了Apache HTTP客戶端。

實驗結(jié)果表明，本文實現(xiàn)的工具可以對現(xiàn)成的安卓應用進行自動化的改造，并且這種改造適用于安卓市場上的很大一部分應用。

4.3 緩存檢測結(jié)果及分析

對改造成功并可以在安卓設備上正常運行的19款應用進行了運行檢測。為了自動化地生成用戶事件流，使用了安卓SDK提供的Monkey工具，該工具可以向安卓模擬器或真實設備中發(fā)送偽隨機用戶事件流，模擬用戶的觸屏、點擊、手勢和按鍵等操作。借助Monkey提供的命令，將每段用戶事件流中的用戶事件數(shù)量控制在500個，用戶事件包含觸屏、位移、按鍵事件，事件將只發(fā)生在當前應用中，不會跳出到其他應用。為了給應用一定的響應時間，將用戶事件輸入間隔設置為1 s。對每個改造后的應用，每天分別運行兩次，這兩次運行中間的時間間隔大于5 h，共運行3天（為保證結(jié)果的可靠性，實驗開始時應用都是全新安裝的），得到的數(shù)據(jù)及分析結(jié)果如圖5所示。

Fig.5 Result ofAndroidApp HTTP cache detection圖5 安卓應用HTTP緩存檢測結(jié)果

在本文測試的19款應用中，有6款應用的HTTP緩存不完整，存在從網(wǎng)絡中重復獲取相同未過期資源的情況，這意味著數(shù)據(jù)流量和電池電量的不必要消耗；同時，有7款應用存在HTTP頭緩存控制設置過于保守的情況，也就是說，雖然某些資源根據(jù)HTTP頭中的緩存控制信息已經(jīng)過期，但實際上這些資源內(nèi)容并未發(fā)生變化，這主要源于服務器端設置得過于保守。需要注意的是，當應用發(fā)生一次HTTP請求時，如果運行時庫發(fā)現(xiàn)HTTP緩存不完整，就不會再檢查緩存設置是否保守，因此實際當中緩存設置保守的問題可能要比實驗結(jié)果中展示得要嚴重一些。Zhang等人的工作[7]中所使用的應用HTTP緩存檢測方法是在一個較短的間隔內(nèi)點擊兩次應用的某個界面元素，比較兩次點擊產(chǎn)生的HTTP響應內(nèi)容。這種方法只能簡單地檢測出應用的緩存是否完整，但沒有考慮響應內(nèi)容的過期時間、內(nèi)容變化等因素，也就無法像本文所提出的方法一樣檢測更多更深入的應用緩存問題，如緩存控制設置、緩存的有效性等。

圖5還展示了應用對安卓設備內(nèi)部存儲、外部存儲的使用情況，以及對緩存總?cè)萘康目刂?。從圖中可以看到，有8款應用并沒有使用設備的外部存儲，這些應用中不乏新聞客戶端、在線音樂應用。雖然安卓官方文檔中并沒有明確提出開發(fā)者對設備內(nèi)、外部存儲的使用建議，但通常來講，安卓設備的內(nèi)部存儲空間較外部存儲空間更小，完全將緩存文件存儲在內(nèi)部設備上，特別是當緩存文件中可能包含比較多的圖片、音頻等容量比較大的資源時，可能給設備內(nèi)部存儲空間帶來比較大的壓力，造成在設備外部存儲還剩余比較多空間時，內(nèi)部存儲空間已經(jīng)告急的情況。同時，在實驗檢測的共19款應用中，發(fā)現(xiàn)只有2款應用對緩存文件的存儲空間占用進行了控制，絕大多數(shù)應用的緩存空間在實驗過程中都是無限制增長的。實驗結(jié)束后應用產(chǎn)生的緩存文件大小一般在幾十兆甚至上百兆，雖然有可能存在應用中緩存空間控制的閾限較高的情況，但考慮到目前測試設備的容量和移動設備上安裝的應用數(shù)量（2016年，美國每臺移動設備平均安裝約89個應用[10]），本文實驗得到的結(jié)果還是具有說服力的。

還對應用中未被使用的緩存文件數(shù)量占比進行了統(tǒng)計，統(tǒng)計結(jié)果如圖6所示。從圖中可以看出，有超過一半的應用，它們的緩存文件中有超過40%是未被使用的。由于本文的實驗進行了3天，每天運行每個應用兩次，因此這些未被使用的緩存文件在未來被應用使用的幾率也比較小，可以認為，這些緩存內(nèi)容實際上對應用來說已經(jīng)是冗余的，基本不會給應用的性能帶來什么實質(zhì)性的幫助，反而造成設備存儲空間的浪費。

Fig.6 Proportion of unused cache files圖6 應用未使用的緩存文件數(shù)量占比

在實驗檢測的19款應用中，有16款應用的緩存命中數(shù)與緩存文件數(shù)的比率在3以內(nèi)，也就是說，平均每個緩存文件被訪問的次數(shù)不到3次，由于其中大部分緩存文件沒有被訪問或只被訪問過一次，這意味著緩存的使用集中在很小一部分文件中。

此外，應用中還有一部分緩存文件是長時間未被再次訪問的，將“長時間”定義為應用最近兩次運行（因為實驗設置的運行間隔已經(jīng)比較長）。請注意，這部分緩存文件是被使用過的。結(jié)合未被使用的緩存文件數(shù)量，在實驗結(jié)束后，這兩類緩存文件數(shù)量占緩存文件總數(shù)量的比例一般在60%以上，如果去掉實驗中應用最后兩次運行過程中新增加的緩存文件，這一比例會更高。這一結(jié)果表明，應用中絕大部分緩存文件并不需要長期保留，應用完全可以清理這類緩存，而不會對應用性能造成太大的影響。

與現(xiàn)有的一些安卓應用HTTP緩存檢測工作[4-7,9]相比，本文所提出的方法不僅可以檢測應用“有沒有緩存”，而且可以通過監(jiān)控應用對緩存文件的使用和管理狀況，檢測應用的緩存“好不好”，即有沒有真正起到緩存應有的效果，有沒有因為緩存而影響了設備的整體使用。特別是第二點，是現(xiàn)有的相關(guān)工作所忽視或是無法做到的。

5 討論

第4章的實驗結(jié)果表明，在目前安卓市場上的應用中，應用的HTTP緩存使用存在如下問題：（1）部分應用的HTTP緩存并不完整，會重復獲取網(wǎng)絡中相同的資源內(nèi)容，造成移動數(shù)據(jù)流量的浪費；同時，更多的網(wǎng)絡請求意味著更多的電量消耗，在移動設備電池電量仍比較緊張的今天，這也是移動設備使用者不愿意看到的。（2）一些應用雖然對運行過程中獲取的HTTP資源進行了緩存，但往往忽略了對緩存的管理，沒有對緩存文件的空間占用進行控制，導致緩存空間無限制增長，影響設備的整體使用。（3）應用運行過程中產(chǎn)生的緩存文件中，有很大一部分是冗余的、無意義的，它們在生成后并沒有被應用所使用，無法起到開發(fā)者期望的效果；同時，一些緩存文件雖然被使用過，但在應用隨后的運行過程中不再被訪問，這些緩存文件實際上也已經(jīng)是冗余的。

基于以上分析，針對安卓應用HTTP緩存，向開發(fā)者提出以下幾點建議：

（1）開發(fā)應用時應注意開啟HTTP客戶端API中提供的緩存，這是最基本的緩存處理，對開發(fā)者的編程負擔很小，而且比較有效。

（2）開發(fā)者應該根據(jù)所開發(fā)應用的特點及具體情況，設計實現(xiàn)更為合適、靈活的緩存處理策略，以獲得更好的緩存效果。例如對于在線音樂客戶端，用戶常聽的歌曲很適合緩存在本地，可以在很大程度上減少運行時消耗的流量，但用戶使用類似“隨便聽聽”的功能隨機播放在線曲庫中的歌曲時，緩存這類歌曲對于減少流量消耗的意義并不大，因為用戶可能不會重復聽這些歌曲。

（3）如果應用運行時使用的HTTP資源也是由應用的開發(fā)者部署在服務器上的，那么開發(fā)者應該謹慎對待資源緩存控制的設置，一方面要保證客戶端不會展示過期的內(nèi)容，另一方面又要把失效時間設置得盡可能久，以減少不必要的重復訪問。

（4）應用在運行時應該及時清理那些長時間未使用的緩存內(nèi)容，減少緩存對設備存儲空間的占用。雖然現(xiàn)在很多應用內(nèi)置了供用戶使用的清理緩存功能，但由于一臺移動設備上應用數(shù)量往往有幾十個甚至上百個，手動清理緩存對用戶來說仍是一件比較繁瑣的事情。應用應當把存儲空間優(yōu)先分配給那些使用頻率較高的緩存內(nèi)容，及時清理那些使用頻率低或者長時間沒有被使用的緩存內(nèi)容，這樣既可以保證應用的流暢運行，發(fā)揮緩存應有的效果，又可以保證良好的用戶使用體驗。

6 局限和未來工作

本文提出的方法及具體實現(xiàn)還存在一些局限，主要有以下幾方面：

（1）由于不同的應用有各自的內(nèi)部處理邏輯，對于緩存“命中”定義的粒度比較粗，只能定義到文件級別，因此應用存儲緩存的方式和訪問方式都可能會對分析結(jié)果產(chǎn)生影響。例如，應用如果將緩存集中存儲在少數(shù)幾個文件當中，那么這幾個文件被訪問的次數(shù)可能會比較多。此外，在應用運行時，可能會有一些保存在內(nèi)存中的緩存內(nèi)容，這些緩存內(nèi)容的具體形式因應用而異，無法記錄關(guān)于這類緩存的確切信息，如果應用不訪問文件，而是直接獲取存儲在內(nèi)存當中的緩存，那么可能會對檢測的結(jié)果造成影響。不過由于設備內(nèi)存容量相對設備總體存儲容量比較有限，這類緩存的總?cè)萘恳话惚容^小，對檢測結(jié)果的影響相對有限。未來可以加入對應用代碼結(jié)構(gòu)的分析，找出應用存儲HTTP緩存的數(shù)據(jù)結(jié)構(gòu)和存儲方式，以便在運行時獲得更加準確的檢測結(jié)果。

（2）本文實驗中的自動化測試工具使用的是安卓SDK提供的Monkey，該工具生成的用戶事件流的隨機性比較大，可控性相對較小；而在一個移動應用中，不同的業(yè)務邏輯的使用頻率也不盡相同，比如在微博客戶端中，用戶可能更常刷新微博而不是發(fā)送私信，Monkey產(chǎn)生的隨機用戶事件流也許不能很好地模擬這一點，并可能對最終檢測結(jié)果造成一定的影響。在未來的工作中，將嘗試結(jié)合一些能產(chǎn)生更加可控的用戶事件流的自動化測試工具來進行檢測。

（3）應用內(nèi)容的更新頻率和應用的使用頻率也可能對檢測結(jié)果造成影響。如果應用中的內(nèi)容的更新頻率很高（比如一些新聞客戶端）而使用頻率較低，檢測得到的緩存命中次數(shù)可能相對較少。在本文實驗中，每天檢測兩次，兩次檢測時間間隔大于5 h，檢測3天，可以大致模擬普通用戶使用應用的一般頻率，但由于無法完全了解每個應用的內(nèi)容更新頻率，因此實驗的結(jié)果可能受到一些影響。

7 相關(guān)工作

有許多與安卓應用的HTTP緩存相關(guān)的工作。Zhang等人[7]對安卓應用的網(wǎng)絡緩存狀況進行了調(diào)研，并且實現(xiàn)了一個系統(tǒng)級的應用網(wǎng)絡緩存服務。這一工作進行的調(diào)研是通過代理服務器攔截應用的網(wǎng)絡請求來實現(xiàn)的，只能實現(xiàn)對應用網(wǎng)絡緩存的完整性的檢測，無法對本文所描述的更深層次的、與應用相關(guān)的緩存問題進行檢測。為了優(yōu)化移動應用中的HTTP請求調(diào)用，減少HTTP請求對電池電量的消耗，Li等人[11]提出了一種通過靜態(tài)分析自動檢測安卓應用中的HTTP請求并在運行時將多個請求捆綁發(fā)送的方法，可以有效減少電量消耗，并且不會引入過多額外開銷。

還有一些與移動端網(wǎng)絡瀏覽器的緩存相關(guān)的研究工作。其中一部分工作[12-13]將移動設備與個人電腦上的網(wǎng)絡訪問行為的差異進行了比較，指出了這些差異可能對移動端的網(wǎng)絡瀏覽器緩存產(chǎn)生的影響。還有一些工作[4,9]對移動端網(wǎng)絡瀏覽器的緩存表現(xiàn)進行了研究和分析，雖然這些研究針對的是瀏覽器應用，但其中發(fā)現(xiàn)的諸如冗余傳輸、誤緩存等問題在一些其他類型的移動應用中也同樣存在。Liu等人[5-6]針對這些問題設計實現(xiàn)了一個基于代理的緩存優(yōu)化系統(tǒng)，供移動端網(wǎng)絡瀏覽器和服務器使用，可以節(jié)約網(wǎng)頁加載時間，減少網(wǎng)絡數(shù)據(jù)傳輸量。本文在上述基礎(chǔ)上更進一步地研究了一般化的移動應用中存在的緩存問題，以及應用緩存的使用效率和空間占用情況。

一些現(xiàn)有工作對緩存策略進行了研究。Ihm等人[14]研究發(fā)現(xiàn)，基于內(nèi)容的緩存策略相比基于對象的緩存策略，可以獲得更高的緩存命中率。Kim等人[15]對現(xiàn)有緩存策略在移動設備閃存上的適用性進行了調(diào)查研究，并針對移動設備閃存容量較小、性能有限的特點，設計了一種考慮閃存中寫操作的空間鄰接性的緩存策略。Chavan等人[16]提出了一種新的移動設備數(shù)據(jù)庫緩存替換策略，該策略考慮了客戶端運動的時間和空間屬性，以及獲取數(shù)據(jù)的模式。在移動設備上，該策略的緩存表現(xiàn)相較傳統(tǒng)的最近最少使用策略有了較大提升。

8 總結(jié)

本文提出了一種基于動態(tài)分析的安卓應用緩存缺陷自動檢測方法，該方法可以在運行時監(jiān)測應用的HTTP通信和對緩存文件的使用，從而檢測分析應用中存在的HTTP緩存問題。依據(jù)這一方法，實現(xiàn)了一個運行時庫和一款安卓應用自動化改造工具，并使用25款安卓市場上的應用進行了實驗。實驗結(jié)果表明，本文提出的方法適用于很大一部分安卓應用，并能夠有效發(fā)現(xiàn)安卓應用中存在的緩存缺失、緩存空間無限增長和緩存冗余等問題。本文還對發(fā)現(xiàn)的緩存問題進行了討論，為開發(fā)者指出了解決這些問題的思路和方法。