Masalah Android, Memory dan Bitmap

“Ngoding” adalah hal yang mengasyikkan bagi kalangan programmer ๐Ÿ˜€
Tentunya yang menghasilkan hehe.

Namun secara tidak sadar, kadang kita tidak begitu memperhatikan bagaimana keterbatasan resource (memori, ukuran layar, dan bandwidth)

Mengabaikan hal tersebut, tentu akan berakibat pada kekecewaan pada pengguna aplikasi kita.

Mengingat pengguna aplikasi itu memiliki berbagai macam perangkat dan model yang berbeda-beda (dengan memory, ukuran layar dan bandwidth yang berbeda pula), khususnya perangkat mobile atau gadget.

Jika kamu telah banyak menghabiskan waktu dengan Android SDK bawaan Google, mungkin sudah mencoba mempraktekan membaca file JPEG ke dalam Bitmap menggunakan function Media.getBitmap. Sudah bisa dipastikan pasti ketemu masalah error :

bitmap size exceeds VM budget

Apa itu?

Ketika saya menarik analogi hal yang berbeda, yaitu pada PHP, mungkin sudah pernah mengotak-atik php.ini, di mana ada memory_limit PHP..yup, kita bakal ngotak-atik itu ketika masalah upload gambar tiba2 muncul pesan error memory size error.

Nah di android, ada file yang serupa dengan php.ini, yaitu build.prop, di situ kamu bisa mengatur memory limitnya, yaitu DalvikVM.heapsize. Di file build.prop juga kita dapat mengatur hal-hal lain, selain memory limit VM ini.

Yak, semua activity app android, bekerja pada Dalvik Virtual Machine ini, dengan bahasa pemrograman Java pada tingkat aplikasi dan bahasa pemrograman C/C++ pada tingkat library.

Namun, alangkah sulitnya, ketika kita mencoba menerapkan “setting vm.heapsize” di berbagai gadget, di mana Aplikasi sebagian besar berjalan pada gadget dengan setting heapsize=16mb.

Akan menjadi kesulitan, jikalau kita mencoba membaca file yang besar dan banyak dalam satu atau dua waktu, yang dihitung-hitung ukurannya lebih besar dari 16mb, bakal muncul pesan kesalahan : bitmap size exceeds VM budget ini.

Dan untuk mengatasi hal tersebut, perlu adanya recycling atau daur ulang “cache” memory, yang membuat kebutuhan akan memory tercukupi dari waktu ke waktu.

Jadi apa yang harus programmer lakukan?

Satu hal yang penting, kita hanya butuh membaca apa yang dibutuhkan dan masuk ke dalam memory. Jikalau file gambarnya besar atau banyak, dalam 1 gambar bertipe JPEG misal 10 MB, dibutuhkan trim/memangkas ukuran/resolusi gambar tersebut ke dalam beberapa bit.

// baca file bitmap
public Bitmap readBitmap(Uri selectedImage) {
Bitmap bm = null;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 5;
AssetFileDescriptor fileDescriptor =null;
try {
fileDescriptor = this.getContentResolver().openAssetFileDescriptor(selectedImage,”r”);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
finally{
try {
bm = BitmapFactory.decodeFileDescriptor(fileDescriptor.getFileDescriptor(), null, options);
fileDescriptor.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return bm;
}

Pada function di atas, terdapat sedikit “jamu” buat nge-trim bitmap yang ukurannya besar, menjadi beberapa bagian kecil options.inSampleSize. Mengurangi size gambar menjadi 1/5 dari ukuran aslinya (atau 20% dari ukuran sebenarnya)

๐Ÿ™‚

Namun ada hal praktis lain yang bisa dipraktekkan, yaitu “daur ulang” seperti yang saya bilang di atas tadi.

Ketika kita berhubungan dengan Bitmap, tentunya memungkinkan untuk “daur ulang” ini, karena terdapat method recycle() di Bitmap ini.

Apa fungsinya?

Fungsinya yaitu membebaskan memory yang terkait dengan pixel bitmap, dan menandai bitmap tersebut sebagai bitmap yang “mati”, yang berarti tidak akan pernah dipakai lagi ketika function getPixels() atau setPixels() dipanggil.

Hal ini berarti, bitmap yang mati ini bisa diisi sebagai “cache” baru di dalam memory untuk dipakai untuk proses Bitmap berikutnya. ๐Ÿ˜€

Contohnya sebagai berikut :

public static void clearBitmap (Bitmap bm) {

bm.recycle ();

bm = null;

System.gc ();

}

Beberapa kasus juga membuktikan masalah OOM (Out Of Memory) ini bisa diatasi dengan System.gc(); ini.

System.gc() berfungsi buat nge-cleanup memory //garbage collector, dalam artian sampah-sampah “cache” ini dibersiin oleh System class tersebut.

@Override

public void onLowMemory(){

super.onLowMemory();

ImageLoader.clearCache();

}

Tentunya dengan hal tersebut di atas, masalah VM Budgets ini dapat teratasi ๐Ÿ˜€

3 thoughts on “Masalah Android, Memory dan Bitmap

  1. mas, untuk penempatan recycle sendiri disimpan setelah proses atau sebelum proses manipulasi? trus apakah setiap variable bertipe Bitmap harus melakukan recycle? atau hanya representasi dari pangkal aliran data saja?

    1. Sbg pertimbangan, GC itu bekerja kalo di-call aja, mas. Kalo gk dicall ya gak jalan. Nah, biar gk numpuk RAM-used nya. Sebaiknya ya call recycle nya sebelum proses manipulasi atau sebelum mengeksekusi variable bitmap yang lain.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.