android緩存機制
Ⅰ 微信Android 客戶端朋友圈功能的緩存機制是怎樣的
安卓圖片的緩存可以根據當前日期,時間為名字緩存到SD卡中的指定圖片緩存目錄, 同時資料庫中做相應記錄,記錄辦法可以採用兩個關鍵欄位控制,一個欄位是該圖片的URL地址,另一個欄位是該圖片的本機地址.取圖片時根據URL在數據中檢索,如果沒有則連接伺服器下載,下載之後再伺服器中作出相應記錄.
Ⅱ android 清除緩存功能如何實現
Android清除本地數據緩存代碼：
/* * 文 件 名: DataCleanManager.java * 描 述: 主要功能有清除內/外緩存，清除資料庫，清除sharedPreference，清除files和清除自定義目錄 */
import java.io.File;
import android.content.Context;
import android.os.Environment;
/** * 本應用數據清除管理器 */
public class DataCleanManager {
/** * 清除本應用內部緩存(/data/data/com.xxx.xxx/cache) * * @param context */
public static void cleanInternalCache(Context context) {
deleteFilesByDirectory(context.getCacheDir());
}
/** * 清除本應用所有資料庫(/data/data/com.xxx.xxx/databases) * * @param context */
public static void cleanDatabases(Context context) {
deleteFilesByDirectory(new File("/data/data/"
+ context.getPackageName() + "/databases"));
}
/**
* * 清除本應用SharedPreference(/data/data/com.xxx.xxx/shared_prefs) * * @param
* context
*/
public static void cleanSharedPreference(Context context) {
deleteFilesByDirectory(new File("/data/data/"
+ context.getPackageName() + "/shared_prefs"));
}
/** * 按名字清除本應用資料庫 * * @param context * @param dbName */
public static void cleanDatabaseByName(Context context, String dbName) {
context.deleteDatabase(dbName);
}
/** * 清除/data/data/com.xxx.xxx/files下的內容 * * @param context */
public static void cleanFiles(Context context) {
deleteFilesByDirectory(context.getFilesDir());
}
/**
* * 清除外部cache下的內容(/mnt/sdcard/android/data/com.xxx.xxx/cache) * * @param
* context
*/
public static void cleanExternalCache(Context context) {
if (Environment.getExternalStorageState().equals(
Environment.MEDIA_MOUNTED)) {
deleteFilesByDirectory(context.getExternalCacheDir());
}
}
/** * 清除自定義路徑下的文件，使用需小心，請不要誤刪。而且只支持目錄下的文件刪除 * * @param filePath */
public static void cleanCustomCache(String filePath) {
deleteFilesByDirectory(new File(filePath));
}
/** * 清除本應用所有的數據 * * @param context * @param filepath */
public static void cleanApplicationData(Context context, String... filepath) {
cleanInternalCache(context);
cleanExternalCache(context);
cleanDatabases(context);
cleanSharedPreference(context);
cleanFiles(context);
for (String filePath : filepath) {
cleanCustomCache(filePath);
}
}
/** * 刪除方法 這里只會刪除某個文件夾下的文件，如果傳入的directory是個文件，將不做處理 * * @param directory */
private static void deleteFilesByDirectory(File directory) {
if (directory != null && directory.exists() && directory.isDirectory()) {
for (File item : directory.listFiles()) {
item.delete();
}
}
}
}
主要功能清除內/外緩存，清除資料庫，清除sharedPreference，清除files和清除自定義目錄
Ⅲ android有哪幾種緩存方式，優缺點是什麼
二級緩存工作機制。
1.所謂二級緩存實際上並不復雜，當Android端需要獲得數據時比如獲取網路中的圖片，我們首先從內存中查找（按鍵查找），內存中沒有的再從磁碟文件或sqlite中去查找，若磁碟中也沒有才通過網路獲取。
2.當獲得來自網路的數據，就以key-value對的方式先緩存到內存（一級緩存），同時緩存到文件或sqlite中（二級緩存）。注意：內存緩存會造成堆內存泄露，所有一級緩存通常要嚴格控制緩存的大小，一般控制在系統內存的1/4。
3.網路中的數據是變化的，數據一旦放入緩存中，再取該數據就是從緩存中獲得，這樣豈不是不能體現數據的變化？在緩存數據時會設置有效時間，比如說30分鍾，若超過這個時間數據就失效並釋放空間，然後重新請求網路中的數據。
Ⅳ 在Android開發中，有哪些好的內存優化方式
我的做法是時間換空間，盡量文件化一些佔用內存的數據。最典型的就是ListView中的Bitmap，可以參考這個開源組件的實現。 其將Bitmap都本地文件緩存，內存中只保留最近使用的4張圖片，在使用中發現還是會偶爾出現OOM，然後我就將其改為完全的讀取文件，內存中不保留圖片，使用以後都自動回收，由此擴展的數據文件也同樣緩存成文件。
除了Bitmap，其他的地方沒想到什麼能佔用這么大內存，網路下載下來的數據文件?需要都留在內存中嗎？目前我做的應用，每次請求的數據大小都比較小，每次Http請求下來的數據都把url轉換成文件名，然後緩存成文件，在下次Http請求的時候先根據url來預讀文件，暫時不用的數據就釋放掉。
經常會OOM我覺得就是在Bitmap處理的時候，比如decodeFile，在往界面上載入圖片時，不用直接載入原圖，可以進行縮放。一張1000*1000的圖片要載入到一個100*100的ImageView上，直接載入進來大多數都會OOM,可以先用inJustDecodeBounds
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
拿到這個圖片的大小，再算好縮放比例
int scale = 0;
scale = (int)(options.outHeight / (float)size);
if (scale <= 0) {
scale = 1;
}
options.inSampleSize = scale;
options.inJustDecodeBounds = false;
再進行decode。
總之就是盡量時間換空間，實際這個時間是非常非常短的，用戶體驗內的。
Ⅳ 安卓運行機制是什麼 安卓手機的工作原理是什麼
android基於Linux內核，很多系統也都基於Linux內核。但是android的特別之處除了開發上的特點以外，還有一個就是程序在運行時的行為和以往我接觸到的程序運行機制有很大不同。在傳統PC機或者其他一些手機上，用戶對應用程序有絕對的掌控權，在應用程序的系統菜單上選擇「退出」或者「關閉」之類的選項會直接殺死進程，而在android系統中不是這樣的。在android中，應用程序的生命周期並不是由應用程序自身直接控制的，而是由系統，當系統需要釋放內存來運行新進程或者保證某些後台進程和前端進程順利執行的時候才會釋放相應應用程序的資源，這個釋放過程有一個重要性的層次。
android中進程的層次如下（重要性由高到低）：
1、前端進程。顧名思義，前端進程就是目前顯示在屏幕上和用戶交互的進程，在系統中前端進程數量很少，而這種進程是對用戶體驗的影響最大，只有系統的內存稀少到不足以維持和用戶的基本交互時才會銷毀前端進程。因此這種進程重要性是最高的。
2、可見進程。可見進程也擁有一個可視化的界面，只是目前不是最上層界面（最上層界面在前端進程裡面），可見進程一般調用了OnPause()，可見進程比前端進程重要性低，但是在交互方面影響還是很大，因為用戶可能隨時切換過去，所以系統不會輕易銷毀它。
3、服務進程。一個服務進程就是一個Service，它調用了startService，就是UNIX中說的守護進程，對用戶不可見，但是保證了一些重要的事件被監聽或者維持著某些狀態，比如網路數據傳輸、後台音樂播放，這類進程在內存不足且為了保證前端交互的順利進行的時候被銷毀。
4、後台進程。這里叫後台進程可能會和一般意義上的後台進程混淆，要說明的是，android里的後台進程是調用了OnStop()的，可以理解成用戶暫時沒有和這個進程交互的願望，所以這里後台進程有點「待銷毀」的意思。
5、空進程。這是一種系統緩存機制，其實就是個進程的外殼，當有新進程創建的時候，這個空進程可以加快進程創建速度，當系統內存不足的時候，首先銷毀空進程。
android中進程重要性層次
Ⅵ android 怎麼去掉listview滑出屏幕的緩存機制
刪除Adapter中getView方法下的那個判斷語句就好了。
Ⅶ android 微博緩存用的什麼機制
實際上並不復雜，當Android端需要獲得數據時比如獲取網路中的圖片，我們首先從內存中查找（按鍵查找），內存中沒有的再從磁碟文件或sqlite中去查找，若磁碟中也沒有才通過網路獲取；當獲得來自網路的數據，就以key-value對的方式先緩存到內存（一級緩存），同時緩存到文件或sqlite中（二級緩存）。注意：內存緩存會造成堆內存泄露，所有一級緩存通常要嚴格控制緩存的大小，一般控制在系統內存的1/4。
理解了二級緩存大家可能會有個問題網路中的數據是變化的，數據一旦放入緩存中，再取該數據就是從緩存中獲得，這樣豈不是不能體現數據的變化？我們在緩存數據時會設置有效時間，比如說30分鍾，若超過這個時間數據就失效並釋放空間，然後重新請求網路中的數據。
Ⅷ 在android中怎樣用雙緩沖機制實現背景圖片的循環移動
不斷的重繪z這一zhang張背景圖.X的坐標不斷減去一個偏移量 如果背景的x坐標小於0的時候在dang'qian當前背景的weightde的地方繪制新de的背景 ha還是原來的bei'ji背景.新bei'j背景的X坐標為原背景的kua寬度
Ⅸ 微信android客戶端的朋友圈緩存機制是怎樣的
你好
很高興為您解答
這個就是在瀏覽頁面後會產生緩存後的垃圾啊
滿意採納下
Ⅹ 如何Android資料庫緩存進行管理
無論大型或小型應用，靈活的緩存可以說不僅大大減輕了伺服器的壓力，而且因為更快速的用戶體驗而方便了用戶。
Android的apk可以說是作為小型應用，其中99%的應用並不是需要實時更新的，而且詬病於蝸牛般的移動網速，與伺服器的數據交互是能少則少，這樣用戶體驗才更好，這也是我們有時舍棄webview而採用json傳輸數據的原因之一。
採用緩存，可以進一步大大緩解數據交互的壓力，特此，我們簡略列舉一下緩存管理的適用環境：
1. 提供網路服務的應用
2. 數據更新不需要實時更新，但是哪怕是3-5分鍾的延遲也是可以採用緩存機制。
3. 緩存的過期時間是可以接受的(不會因為緩存帶來的好處，導致某些數據因為更新不及時而影響產品的形象等)
帶來的好處：
1. 伺服器的壓力大大減小
2. 客戶端的響應速度大大變快(用戶體驗)
3. 客戶端的數據載入出錯情況大大較少，大大提高了應有的穩定性(用戶體驗)
4. 一定程度上可以支持離線瀏覽(或者說為離線瀏覽提供了技術支持)
一、緩存管理的方法
這里的緩存管理的原理很簡：通過時間的設置來判斷是否讀取緩存還是重新下載。
裡面會有一些細節的處理，後面會詳細闡述。
基於這個原理，目前鄙人見過的兩種比較常見的緩存管理方法是:資料庫法和文件法。
二、資料庫法緩存管理
這種方法是在下載完數據文件後，把文件的相關信息如url，路經，下載時間，過期時間等存放到資料庫，下次下載的時候根據url先從資料庫中查詢，如果查詢到當前時間並未過期，就根據路徑讀取本地文件，從而實現緩存的效果。
從實現上我們可以看到這種方法可以靈活存放文件的屬性，進而提供了很大的擴展性，可以為其它的功能提供一定的支持；
從操作上需要創建資料庫，每次查詢資料庫，如果過期還需要更新資料庫，清理緩存的時候還需要刪除資料庫數據，稍顯麻煩，而資料庫操作不當又容易出現一系列的性能，ANR問題，實現的時候要謹慎，具體作的話，但也只是增加一個工具類或方法的事情。
還有一個問題，緩存的資料庫是存放在/data/data/<package>/databases/目錄下，是佔用內存空間的，如果緩存累計，容易浪費內存，需要及時清理緩存。
當然這種方法從目前一些應用的實用上看，我沒有發現什麼問題。
本文我側重強調第二種方法，第一種方法的實現，就此掠過。
三、文件法緩存管理
這種方法，使用File.lastModified()方法得到文件的最後修改時間，與當前時間判斷是否過期，從而實現緩存效果。
實現上只能使用這一個屬性，沒有為其它的功能提供技術支持的可能。
操作上倒是簡單，比較時間即可。本身處理也不容易帶來其它問題，代價低廉。
四、文件法緩存管理的兩點說明
1. 不同類型的文件的緩存時間不一樣。
籠統的說，不變文件的緩存時間是永久，變化文件的緩存時間是最大忍受不變時間。
說白點，圖片文件內容是不變的，直到清理，我們是可以永遠讀取緩存的。
配置文件內容是可能更新的，需要設置一個可接受的緩存時間。
2. 不同環境下的緩存時間標准不一樣。
無網路環境下，我們只能讀取緩存文件，哪怕緩存早就過期。
WiFi網路環境下，緩存時間可以設置短一點，一是網速較快，而是流量不要錢。
移動數據流量環境下，緩存時間可以設置長一點，節省流量，就是節省金錢，而且用戶體驗也更好。
舉個例子吧，最近本人在做的一個應用在wifi環境下的緩存時間設置為5分鍾，移動數據流量下的緩存時間設置為1小時。
這個時間根據自己的實際情況來設置：數據的更新頻率，數據的重要性等。
五、何時刷新
開發者一方面希望盡量讀取緩存，用戶一方面希望實時刷新，但是成都網站製作響應速度越快越好，流量消耗越少越好，是一個矛盾。
其實何時刷新我也不知道，這里我提供兩點建議：
1. 數據的最長多長時間不變，對應用無大的影響。
比如，你的數據更新時間為1天，則緩存時間設置為4~8小時比較合適，一天他總會看到更新，如果你覺得你是資訊類應用，再減少，2~4小時，如果你覺得數據比較重要或者比較受歡迎，用戶會經常把玩，再減少，1~2小時，依次類推。
為了保險起見，你可能需要毫無理由的再次縮減一下。
2. 提供刷新按鈕。
上面說的保險起見不一定保險，最保險的方法使在相關界面提供一個刷新按鈕，為緩存，為載入失敗提供一次重新來過的機會，有了這個刷新按鈕，我們的心也才真的放下來。