編輯:關於Android編程
在開發應用的時候,很多時候都會涉及大量圖片的加載和高精度圖片的加載,這兩種操作都是會導致應用程序OOM(OutOfMemory)的問題發生,合理的圖片加載和圖片內存管理就是必須解決的問題,以下將提供一個比較完善的技術方案,解決這兩個問題。
首先,我們必須明確為什麼會發生OOM(OutOfMemory)的問題,其原因就是因為在APP運行過程中,所使用的系統內存超出了當前APP的最大可用內存,就發生了OOM的問題。下面,我們來估算一下在一台中高檔的手機上面,加載多少圖片會導致OOM:假設系統分配給APP的最大可用內存為32M,加載一張512*512分辨率的圖片,會占用2M的內存空間,這樣,在APP中加載16張圖片,就會出現OOM,事實上,當加載10張圖片以上,都極容易導致OOM,因為APP運行中還是會占用內存的。(PS:圖片占用內存計算:Android中Bitmap的默認加載使用ARGB_8888,每個像素會占用4byte,因為每個像素有兩個Chanel,因此一個512*512的圖片,無論什麼格式,加載進入內存都占用512*512*4*2=2MB,所以,Android圖片占用內存大小,只與圖片的分辨率(像素)以及加載使用的色彩模式有關)
要解決OOM的問題,從兩方面進行優化:1.合理加載資源 2.合理回收資源
合理加載資源
合理加載資源,既如果展示圖片的ImageView只有128*96的像素大小,這時候把一張1024*768的圖片完全加載到內存中,很明顯是錯誤的行為。這個時候,就需要把要加載的圖片進行壓縮加載,就是合理地加載資源。
下面,來進行圖片的壓縮講解,設置BitmapFactory.Options中inSampleSize的值就可以實現等比例壓縮。比如我們有一張2048*1536像素的圖片,將inSampleSize的值設置為4,就可以把這張圖片壓縮成512*384像素。原本加載這張圖片需要占用26M的內存,壓縮後就只需要占用1.5M了。下面的方法可以根據傳入的寬和高,計算出合適的inSampleSize值:
public static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) { // 源圖片的高度和寬度 final int height = options.outHeight; final int width = options.outWidth; int inSampleSize = 1; if (height > reqHeight || width > reqWidth) { // 計算出實際寬高和目標寬高的比率 final int heightRatio = Math.round((float) height / (float) reqHeight); final int widthRatio = Math.round((float) width / (float) reqWidth); // 選擇寬和高中最小的比率作為inSampleSize的值,這樣可以保證最終圖片的寬和高 // 一定都會大於等於目標的寬和高。 inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio; } return inSampleSize; }
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, int reqWidth, int reqHeight) { // 第一次解析將inJustDecodeBounds設置為true,來獲取圖片大小 final BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeResource(res, resId, options); // 調用上面定義的方法計算inSampleSize值 options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight); // 使用獲取到的inSampleSize值再次解析圖片 options.inJustDecodeBounds = false; return BitmapFactory.decodeResource(res, resId, options); }經過以上的兩步操作,即可實現合理的加載圖片資源。
合理回收資源
合理回收資源,既對加載在內存中的圖片資源進行合理的回收,避免因為不再使用的圖片資源還留存在內存中的情況出現。而要實現合理回收資源,最核心的一個類就是:LruCache,這個類非常適用於保存圖片內存,它的主要算法原理是把最近使用的對象用強引用存儲在 LinkedHashMap 中,並且把最近最少使用的對象在緩存值達到預設定值之前從內存中移除。
下面給出具體的使用方法:
private LruCachemMemoryCache; @Override protected void onCreate(Bundle savedInstanceState) { // 獲取到可用內存的最大值,使用內存超出這個值會引起OutOfMemory異常。 // LruCache通過構造函數傳入緩存值,以KB為單位。 int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024); // 使用最大可用內存值的1/8作為緩存的大小。 int cacheSize = maxMemory / 8; mMemoryCache = new LruCache (cacheSize) { @Override protected int sizeOf(String key, Bitmap bitmap) { // 重寫此方法來衡量每張圖片的大小,默認返回圖片數量。 return bitmap.getByteCount() / 1024; } }; } public void addBitmapToMemoryCache(String key, Bitmap bitmap) { if (getBitmapFromMemCache(key) == null) { mMemoryCache.put(key, bitmap); } } public Bitmap getBitmapFromMemCache(String key) { return mMemoryCache.get(key); }
Dialog 使用總結Dialog 是Android中對話框相關的類,起到相關提示的作用。Dialog在Android 中主要分為以下幾類:AlertDialog :警告
2.7導航欄及菜單2.7.1 ActionBarActionBar是Android3.0(API 11)開始增加的新特性,ActionBar出現在活動窗口的頂部,可以顯示
先看一下singleTop啟動模式的說明:可以有多個實例,但是不允許此Activity的多個實例疊加。即,如果此Activity有實例在棧頂的時候,啟動這個Activit
之前的博文《Android 中使用ExpandableListView 實現分組的實例》我簡單介紹了使用ExpandableListView實現簡單的好友分組功能,今天我