Dengan Android L, virtual machine compiler di Android akan mulai berpindah ke ART (Android RunTime) dan khusus untuk 64 bit hanya tersedia ART. Lalu, apa yang kita ketahui tentang ART vs Dalvik? Dan apa artinya ini untuk kode aplikasi yang sudah ada?
ART adalah sebuah AOT (ahead of time) compiler yang berarti dex2oat berjalan hanya sekali yaitu ketika instalasi awal aplikasinya. Dalvik adalah JIT (just in time) compiler yang berjalan hanya ketika aplikasi dipanggil. Dengan mengorbankan waktu instalasi menjadi lebih lama, Android Runtime membebaskan prosesor nantinya ketika aplikasi dipanggil.
Sebagai tambahan, terdapat garbage collector dan memory allocator baru di Android Runtime yang akan mengurangi jumlah dan durasi perhentian. Ini berarti ART menyajikan rensponsifitas yang lebih baik dan lebih sedikit penarikan daya. Namun perlu diingat semakin kecil memory footprint ketika runtime berarti semakin besar keperluan kapasitas penyimpanan untuk biner yang dikompilasikan. ART dapat bekerja dengan perangkat ARM, x86, dan MIPS dan menampilkan kemajuan dalam menjalankan kalkulasi floating point.
Untuk kodingannya apakah ada yang berubah? Kabar baiknya adalah ART itu backward compatibel dengan menggunakan kode format byte Dex (Dalvik executeable). Jadi, kebanyakan aplikasi yang ada seharusnya dapat langsung dijalankan (dan bahkan lebih baik performanya).
Namun, ada beberapa hal mungkin dapat dicek dan dioptimalkan di ART:
- Cek untuk ART dengan melihat nilai versi yang dihasilkan dari System.getProperty(“java.vm.version”). ART versinya adalah “2.0.0” atau lebih besar.
- Jika kamu menggunakan JNI untuk menjalankan kode C/C++, pastikan untuk menggunakan CheckJNI (set debuggable=”true” di manifes). Lihat Debugging Android JNI with CheckJNI (catatan: setelan ini hanya untuk ketika prerelease debugging dan seharusnya tidak perlu diset ke “true” untuk kode versi rilis publik)
- Gunakan peralatan versi terbaru. ART melakukan verifikasi kode byte yang lebih ketat ketika instalasi aplikasi dibanding Dalvik. Kode yang diproduksi oleh alat pembuat Android seharusnya dapat bekerja namun beberapa peralatan setelah pemrosesan (seperti peralatan obfuscation) mungkin akan menghasilkan file yang tidak valid (dibolehkan di Dalvik tapi ditolak oleh ART).
- Pertimbangkan apakah akan menghapus beberapa pengecekan eksepsi (yang mana tidak diperlukan lagi karena ART melihat semua kode sekaligus, namun perlu diingat Dalvik tetap akan ada untuk beberapa waktu).
- Hapus hampir semua panggilan System.gc(), terutama mereka yang mengurangi fragmentasi atau kejadian tipe GC_FOR_ALLOC.
- Jangan menyimpan pointer ke data instance Object dan jangan mengirimkan pointer yang dimodifikasi ke Release…ArrayElements(). Garbage collector mungkin akan memindahkan objek ke memori dan panggilan Get dan Release ke ArrayElements() mungkin akan membuat memori korup. Jika kamu melakukan perubahan ke elemen array yang didapat, kamu harus memanggil fungsi yang sesuai:
- Tidak ada perubahan di array > gunakan mode JNI_ABORT (lepas memori, tidak ada kopi kembali).
- Ada perubahan, tapi tidak perlu referensikan mereka > gunakan kode 0 (perbaharui objek array dan lepas memori).
- Ada perubahan dan harus mengkomit mereka > gunakan JNI_COMMIT (yang mana memperbaharui objek array yang ada dan mempertahankan kopinya).
- Jangan mencoba utuk melihat medan Object karena mereka sekarang memiliki medan privat. Ketika mengiterasi sebuah hierarki class sebagai bagian dari framework serialisasi, stop ketika Class.getSuperclass()==java.lang.Object.class (jangan lanjut sebelum null diberikan)
- Gunakan error handling dan logging tambahan di ART
- Throwing dan logging yang lebih baik di NoSuchMethodError dari GetMethodID() dan GetStaticMethodID() dan dari panggilan RegisterNatives (mungkin dikarenakan metodenya dihilangkan oleh peralatan seperti ProGuard).
- Menggunakan NoSuchFieldError (bukan null) dari GetFieldID() dan GetStaticFieldID()
- Peringatan ketika subclass mencoba untuk mengganti metode paket-privat. Untuk mengannti metode sebuah class, deklarasikan metodenya sebagai public atau proctected.
- Beberapa masalah yang ditandai oleh verifikator ART termasuk:
- Alur kontrol yang tidak valid
- moniterenter/monitorexit yang tidak seimbang
- Ukuran tipe list yang besarnya 0
- Perhatikan pada pelaksanaan spesifikasi JNI yang lebih ketat teramsuk metode CallNonvirtual—Method() yang memerlukan metodanya untuk mendeklarasikan sebuah class, bukan subclass.
- Perhatikan besar dari unified thread stack yang mana seharusnya tidak berbeda dengan dua stack Dalvik (secara asalnya 32 KB stack Java dan 1 MB native stack). Kapanpun ketika ukuran stack secara eksplisit diset harus dicek – terasukan panggilan Java ke Thread constructor termasuk penambahan ukuran jika StackOverflowError terjadi.
- Perhatikan ukuran pthread ( pthreat_attr_setstack() dan pthreat_attr_setstacksize() ) karena panggilan-panggilan termasuk AttachCurrentThread() akan mengeluarkan eror.
- Hapus depedensi apa pun pada format file .odex yang terinstal di /system/framework, /data/dalvik-cache, atau di folder keluaran optimalisasi DexClassLoader. Ketika ART mencoba untuk mengikuti peraturan penamaan dan penguncian yang sama di ELF, aplikasi seharusnya tidak bergantung pada format file.
- Gunakan Mockito terbaru untuk secara benar Proxy InvocationHandler.invoke() menerima null (bukan array kosong) jika tidak ada argumen yang disediakan.
- Cek semua notifikasi yang kamu kirimkan. Ada skema warna yang baru di Android L.
- Gunakan android.app.Norification.Builder.setColor() untuk mengeset warna aksen di lingkaran di belakang gambar icon aplikasimu.
- Ingat untuk hanya menggunakan kanal alpha untuk icon notifikasi utama dan action icon
- Cek notifikasi heads up (notifikasi yang menggunakan fullScreenIntent atau notifikasi prioritas tinggi dengan ringtone / vibrasi)
Referensi:
* Artikel ini adalah hasil kerja sama dengan Intel Developer Zone. Artikel asli bisa dilihat di link ini.