Android各版本間API的差別 - Bitmap

概述

Bitmap在API Level 1中就已經有了, 只不過隨着SDK更新, Google對它的一些內外部接口/實現進行了一些優化或者調整, 主要是內存資源的管理方面. 

差別

• 內存資源回收: Android 2.3(API Level 10)- 因爲存儲圖像數據的Buffer分配在Native內存中, 而且只能經過 recycle( ) 來顯式釋放Buffer , 而3.0+中，該Buffer則分配在Dalvik Heap中, 所以 recycle( ) 一般當成兼容向下版本的調用. p.s. 該Buffer可在Android源碼Bitmap.java中找到.

• On Android Android 2.2 (API level 8) and lower, when garbage collection occurs, your app's threads get stopped. This causes a lag that can degrade performance. Android 2.3 adds concurrent garbage collection, which means that the memory is reclaimed soon after a bitmap is no longer referenced. 
• On Android 2.3.3 (API level 10) and lower, the backing pixel data for a bitmap is stored in native memory. It is separate from the bitmap itself, which is stored in the Dalvik heap. The pixel data in native memory is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash. As of Android 3.0 (API level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap.

• 內存重利用: 3.0+容許開發者將已存在的Bitmap.Buffer分配給新的Bitmap來使用, 不過Bitmap之間的大小要嚴格相同, 而4.4(API Level 19)+則改變這一情況.
• BitmapFactory.Options: 詳見SDK API Reference.

擴展閱讀

上述都只是針對單個Bitmap的內存管理, 可是在開發中, 不免會須要管理大量的Bitmap, 那應該怎麼辦?

在API Level 12中, 能夠經過LruCache來緩存大量的內存Bitmap. 除此以外, 在Android源碼中, 能夠找到, 一個名爲DiskLruCache的類, 它能夠文件形式緩存Bitmap.

參考資料

Google Taining