手機管理應用研究【2】—— 垃圾清理篇

來源:互聯網
上載者:User

標籤:android   垃圾清理   手機最佳化   手機加速   垃圾掃描   

歡迎轉載,轉載請註明:http://blog.csdn.net/zhgxhuaa


說明

在總篇中提到過垃圾清理,本篇將著重介紹針對緩衝、卸載殘留、無用資料等“靜態內容”的清理,有關於系統進程的清理以及手機加速的相關功能,將放到《手機加速篇》中介紹研究。


什麼是垃圾
關於系統垃圾的定義
現在很多手機管理軟體中都有垃圾清理的功能,本篇也來對垃圾清理做一個簡單的分析和介紹。在正式分析之前,讓我們首先看一下“什麼叫系統垃圾?”。在百度本科中,關於“系統垃圾”是這樣定義的:系統垃圾,就是系統不再需要的檔案的統稱。當你瀏覽過網頁,安裝後又卸載掉的程式殘留檔案及註冊表的鍵值。這些都是對系統毫無作用的檔案,只能給系統增加負擔,所以叫垃圾。

關於系統垃圾其實就一句話”所有我們所不再需要的資源、檔案、緩衝,就是垃圾”。我們清理系統垃圾就是要清理掉這些不再需要的檔案。


Android中有哪些可以清理的垃圾


首先看一下在目前流行的手機管理軟體總,都將那些作為可以清理的垃圾,下面是使用率比較高的四款手機管理軟體的垃圾清理部分:




結合這些手機管理軟體,對Android手機中可以清理的垃圾總結如下:

A.       應用快取檔案

B.       應用卸載殘留

C.       無用的安裝包

D.       記憶體資料

E.        系統垃圾(日誌、縮圖、空檔案夾等)

F.        廣告檔案

G.       大檔案(檔案大小大於某個值的檔案)

H.       SD卡上的無用檔案

在清理這些垃圾檔案時,有的需要root許可權,有的不需要,接下來將統一做一下介紹分析。


Android應用資料管理策略


在瞭解了關於垃圾檔案的定義後,下面介紹一些Android中關於應用資料的管理原則:

Android中資料存放區可以簡單的分為內建儲存(主要指應用data目錄)和外置儲存(主要是SD卡)兩種情況。Android對這兩種不同情況的管理原則是不一樣的。對於內建儲存中的資料採用進程隔離的原則儲存,外置儲存則採用全域共用的原則儲存。

對於清理內建儲存中的應用私人資料一般來說是需要root許可權的,對於清理外置儲存中的資料一般來說是不需要特殊許可權的。


快速清理與深度清理


在很多手機管理類軟體中都會發現有“快速清理”和“深度清理”,這裡簡單說一下:

  • 所謂快速清理,其實往往就是指在垃圾掃描時只掃描兩到三層目錄,暫時不做一些需要深度遍曆等的耗時操作。
  • 所謂深度清理,往往就是指對所有可清理的垃圾進行全面掃描,對目錄進行深度遍曆。

這裡有一點要說的是,二者的看似涇渭分明,實則是可以相互融合的,一個可行測策略是:

在管理軟體啟動後,選擇系統空閑時間,定時做深度掃描,在使用者手動觸發時做快速掃描。不過這裡又引出另外一個問題是:在空閑時掃描要有合適的策略,什麼時候開始,什麼時候暫停,必須保證在不影響應用正常使用的前提下進行。


系統垃圾清理


應用緩衝清理


對於應用緩衝的清理,本文將介紹兩種實現方案,分別為:自己實現應用緩衝清理和利用系統介面實現應用緩衝清理,接下來將分別介紹。


自己實現應用緩衝清理


要清理應用緩衝,首先要瞭解應用的緩衝是怎麼存放的。一般來說,Android中應用的緩衝包括如下部分:

A.       /data/data/ package_name /cache(應用緩衝)

B.       /mnt/sdcard/Android/ package_name /cache(外部應用緩衝,FROYO以後支援)

C.       /data/data/package_name/database/webview.db*(WebView緩衝)

D.       /data/data/package_name/database/webviewCache.db*(WebView緩衝)

E.        其他一些/data/data/ package_name /*cache目錄(應用緩衝)

F.        /data/data/package_name/files(比較嚴格的清理策略時也可以選擇清理)

對於儲存在/data/data/ package_name目錄下檔案,應用本身及與其共用userId的應用擁有全部的讀寫執行許可權,其他應用是沒有讀寫權限的,如下:




通過上面的分析,我們得出了清理應用緩衝的第一種方案:

在獲得root許可權的前提下,遍曆掃描應用的上述緩衝目錄,如果發現則刪除即可。下面兩段是計算緩衝大小和清理緩衝的部分範例程式碼:

計算緩衝大小部分的程式碼片段:



清理緩衝部分的程式碼片段:




當然,這裡的掃描和清理工作也可以通過JNI放到C代碼裡去做,實現都是類似的。在通過C代碼是否緩衝時可以參見@frameworks/native/cmds/installd/commands.c中的free_cache函數。


利用系統介面實現應用緩衝清理


用過Android手機的朋友相信都知道在手機的“設定->應用”中的應用詳情頁裡面有“清除緩衝”的功能,下面是在我我個人的手機上一個應該的:




OK,到這裡,問題來了,我們是否可以利用系統介面實現應用”清除緩衝“功能呢?Android系統中應用詳情頁位於@/packages/apps/Settings/src/com/android/settings/applications/InstalledAppDetails.java中。

InstalledAppDetails中清理應用緩衝部分的代碼如下所示:




在PackageManager中關於deleteApplicationCacheFiles的實現如下:




這裡我們要注意如下幾點:

A.       deleteApplicationCacheFiles介面是hide的,在代碼中不能直接調用。

B.       使用deleteApplicationCacheFiles介面需要聲明DELETE_CACHE_FILES許可權。

C.       通過deleteApplicationCacheFiles介面是無法清除系統應用緩衝的。

D.       緩衝清理結果通過IPackageDataObserver介面完成回調。

除了deleteApplicationCacheFiles介面,PackageManager中還有如下兩個介面可以選擇調用:




下面是採用第二種緩衝清理方式的部分範例程式碼,如下:






下面是擷取各個應用緩衝大小的部分範例程式碼:








兩種實現方案對比


在介紹了兩種應用緩衝清理方式以後,這裡做一個簡單的對比,以供使用時進行選擇:

A.       從範圍:第一種方式清理範圍更廣,更徹底。第二種方式只能清理非系統應用,第一種方式可以清理所有應用,甚至應用自訂快取檔案。

B.       從許可權:第一種方式需要root許可權,第二種方式只需要在AndroidManifest中指定DELETE_CACHE_FILES即可。

C.       從安全:採用第一種方式時要有合適的策略,避免清理掉不應該清理的緩衝。

綜上,第一種方式的清理範圍更廣更徹底一些,在取得root許可權的情況下,建議採用第一種方式。


應用卸載殘留清理


如在1.3中所介紹,應用安裝後的資料存放有內建儲存和外置儲存兩種方式。對應內建儲存中的資料在應用刪除時會自動被刪除,這裡可以不用關心。但是許多Android應用程式會在移動終端的儲存卡上建立自己應用程式專用的目錄,用來存放快取檔案、臨時檔案或者通過網路下載的視頻、音頻、書籍等媒體檔案。但是,當Android應用程式被卸載時,殘留在儲存卡上的檔案不會被刪除,而其中大部分檔案對於使用者來說是無用處的,屬於垃圾檔案。如果使用者頻繁的安裝和卸載新軟體,就會在儲存卡產生大量的應用程式殘留檔案,不但佔用儲存卡空間,而且使儲存卡的檔案管理變得困難起來。因此,實現Android應用程式殘留目錄的識別與清理是十分必要的。

應用卸載殘留清理的一個關鍵點就是:應用殘留目錄的識別。這裡有兩種可行的方案:


方案一:維護檔案對應資訊


在檔案或者資料庫中應用程式套件名(唯一)與SD卡上檔案的一個映射資訊,可以採用應用程式套件名為Key,因為不同應用的包名是唯一的,不會重複;採用SD卡上的檔案作為Value,建立映射如下所示:

Key

Value

應用程式套件名(唯一)

檔案夾

在檢測到應用卸載事件後判斷該應用是否有對應的檔案存在,有則提示使用者刪除。採用這種方案時需要如下幾個問題:

A.       映射表的建立:需要對使用頻率和使用者量較高的應用建立映射表。這裡最好有後台提前掃描應用建立,然後下發給用戶端;也可以用戶端先上報資訊到後台,後台修正。映射表的建立是識別的關鍵。

B.       錯誤識別問題:一般來說不同應用的資料放在不同的檔案夾中,不會有重複。但在實際中難免會出現重複的情況。對於這種情景有兩種處理方式:

1)        映射關係細化到檔案,刪除完檔案後再判斷上層檔案夾是否為空白,為空白則刪除。

2)        有多個應用的映射關係重複時判斷所有應用都已卸載再刪除檔案夾。


方案二:記錄應用安裝過程


該方案的普遍性並不如第一種方案強,但也可作為一種實現方案作為參考。方案如下:

1)        在通過管理軟體進行安裝時,通過log記錄安裝應用所產生的檔案。在應用運行時,監控SD檔案的變化,發現變化時,當前應用(運行時棧頂)即檔案的建立者,同樣在log中記錄這種對應關係。

2)        在通過管理軟體卸載應用時,根據log資訊執行逆過程。


無用安裝包清理


無用安裝包的清理比較簡單。判斷無用安裝包的標準是:

A.       儲存目錄中存在APK檔案,但是該APK已被安裝

B.       APK檔案已損壞

掃描安裝包有兩種處理方式:

A.       深度掃描:掃描SD卡上的所有目錄

B.       快速掃描,只掃描手機管理軟體(豌豆莢、360手機小幫手、應用寶等)和瀏覽器(UCWeb、QQ瀏覽器)和Download目錄。

要清理其他下載檔案也可以按照這個思路來實現。


系統垃圾清理


系統垃圾清理包括臨時檔案、縮圖、系統日誌、失效檔案、空白檔案等的清理,下面做一下介紹。


清理系統日誌


記錄檔分為系統日誌和應用日誌兩部分,其各自的存放位置分別為:

1)        系統日誌的存放位置如下(不同手機可能會有所差異):

A.       /data/local/tmp/*

B.       /data/tmp/*

C.       /data/system/usagestats/*

D.       /data/system/appusagestates/*

E.        /data/system/dropbox/*

F.        /data/tombstones/*

G.       /data/anr/*

H.       /dev/log/main

2)        應用日誌存放位置可以判斷的有:SD卡上尾碼名為“.log”或者“*log.txt”等結尾的檔案。


清理圖片縮圖


在SD卡上的DICM目錄下有一個隱藏的目錄,名字叫“.thumbnails”,這個目錄存放的是系統圖片的緩衝。清理緩衝主要就是清理這個目錄。應用目錄也可能有縮圖檔案,但不容易識別,所以不建議清理,可以放在清理殘留資料時一起清理。


清理失效檔案與空白檔案


判斷標準:

A.       檔案的長度為0則認為是空白檔案,可以刪除

B.       檔案夾中不包含任何檔案或檔案夾,則認為是空白檔案夾,可以刪除。

C.       除了上面兩種情況外,還可以掃描檔案的建立時間,很長時間未使用的檔案認為是無效檔案。



大檔案清理


對於大檔案的識別比較簡單,只判斷檔案大小是否超過一定的閥值(例如:豌豆莢認為大小超過10M即為大檔案)即可。但這裡有兩個需要注意的點:

A.       大檔案一般是視頻檔案或者應用資料(例如百度map的資料),對於這些檔案在清理是建議默為“不選中”狀態。

B.       可以充分利用2.2.1中建立的映射關係,對大檔案是否建議刪除提供更加準確的建議。

對於廣告檔案等的識別和處理這裡不再贅述了,原理都與上面的類似。



總結


通過本篇中的方法基本上可以實現對Android系統中垃圾檔案的全面清理。這裡要強調的是:

A.       垃圾清理是把雙刃劍,一定要有合適的策略,否則反而影響使用者體驗。

B.       在清理垃圾檔案時一定要抱著這樣的態度:寧可錯,不可過。

 

最後,希望本文能夠給所有對垃圾清理和手機管理感興趣的朋友帶來一點協助,將榮幸之至。有任何問題歡迎交流和討論。下一篇將介紹《手機加速》



聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.