() translation by (you can also view the original English article)
Aplikasi Android yang paling populer memiliki kesamaan: mereka memberikan pengalaman pemakai yang luar biasa. Di sini, saya akan berbagi sejumlah tips yang akan membantu aplikasi Anda tetap hebat.
Apapun jenis aplikasi yang Anda pikirkan, atau audiens target Anda, mendesain pengalaman aplikasi yang dahsyat bisa membantu dalam memastikan keberhasilan aplikasi Anda. Di artikel ini, saya akan membagikan 6 hal yang harus dan tidak boleh Anda lakukan untuk meyakinkan aplikasi Anda memberikan pengalaman terbaik untuk para pengguna akhir.
Karena membuat dan meluncurkan suatu aplikasi android adalah proses yang memiliki sekian tahap, saya akan menyentuh tiap bagian siklus pengembangan Android—mulai membuat keputusan sulit tentang versi Android mana yang harus Anda dukung, untuk membuat produk yang akan menarik audies global, hingga menganalisis kinerja aplikasi Anda pasca peluncuran.
1. Jangan Terpaku Mencoba untuk Mendukung Semua Versi Android
Adalah wajar jika kita ingin aplikasi kita bisa tampil bagi sebanyak mungkin pengguna, tetapi jangan terjebak dengan mengasumsikan bahwa mendukung lebih banyak versi Android selalu merupakan pendekatan terbaik.
Kunci untuk menarik audiens yang lebih banyak adalah dengan memberikan pengalaman pengguna sebaik mungkin, sedangkan hanya terpatok untuk mendukung sebanyak mungkin versi Android bisa merusak pengalaman pengguna secara keseluruhan.
Isu utamanya adalah, seiring Anda berupaya melihat kembali sejarah rilis Android, akan semakin sulit untuk menjadikan aplikasi Anda bekerja dengan baik pada rilis-rilis termutakhir.
Terkadang, mungkin ada satu titik yang jelas ketika aplikasi Anda tidak kompatibel dengan rilis Android terkini. Misalnya, jika aplikasi Anda secara mutlak membutuhkan akses ke Bluetooth Energi Rendah (BLE), maka aplikasinya tidak akan bisa berjalan di versi yang lebih mutakhir dari Android 4.3—versi yang di situ dukungan BLE mulai ditambahkan.
Meskipun demikian, terkadang garis pemisahnya tidak begitu jelas dan Anda bisa berdebat dengan diri sendiri apakah akan memodifikasi atau membuang sejumlah fitur yang tidak terlalu penting, untuk membuat sesuatu yang bisa berjalan di versi Android tertentu. Kompromi-kompromi kecil bisa secara berangsur menurunkan kualitas pengalaman pengguna, jadi senantiasalah memperhatikan dampak-dampak perubahan tersebut pada para pengguna Anda.
Selain itu, mengustomisasi, mengoptimasi, dan menguji aplikasi Anda untuk tiap versi Android butuh waktu dan tenaga, jadi Anda juga butuh bertanya pada diri Anda sendiri apakah investasi tersebut sebanding dengan potensi keuntungannya. Pada dasarnya, berapa banyak pengguna yang berpotensi didapatkan dengan mendukung tiap versi Android? Anda bisa mengetahui indikasi banyaknya perangkat Android yang menjalankan masing-masing rilis platform Android, dengan memeriksa statistik di Google's Dashboard.
Kesimpulannya, tidak ada jawaban yang sepenuhnya benar atau salah, jadi Anda harus menimbang berbagai kekurangan dan kelebihan serta menentukan apa yang paling masuk akal untuk proyek Anda.
Begitu Anda menentukan versi Android apa saja yang akan didukung, tambahkan informasi ini ke file build.grandle level modul dengan menggunakan minSdkVersion (API terendah kompatibilitas aplikasi Anda), targetSdkVersion (API tertinggi yang Anda uji aplikasinya dengan itu), dan compileSdkVersion (versi Android SDK yang harus digunakan Gradle untuk mengkompilasi aplikasi Anda).
Untuk memastikan aplikasi Anda mendapat manfaat dari fitur Android terbaru sembari tetap kompatibel dengan rilis yang lebih terdahulu, direkomendasikan Anda mengatur nilai mindSdkValue serendah mungkin, sedangkan pengaturan targetSdkVersion dan compileSdkVersion dibuat sesuai versi terkini Android SDK.
2. Desainlah untuk Berbagai Ukuran Layar
Sembari mengerjakan aplikasi Android Anda, wajar jika Anda menghabiskan banyak waktu menguji aplikasi Anda pada smartphone atau tablet Android Anda sendiri. Terutma sepanjang tahap awal pengembangan aplikasi, membuat sejumlah perangkat virtual android (Android Virtual Devices/AVD) mungkin hal terakhir yang Anda pikirkan.
Meskipun demikian, jangan kehilangan gambar besarnya! Mudah saja terpaku untuk mendesain bagi satu ukuran layar yang secara fisik ada di hadapan Anda, tetapi penting bagi aplikasi Anda untuk tampil dan berfungsi dengan baik bagi berbagi macam perangkat Android.
Sistem Android akan secara otomatis mengubah ukuran layout, drawable, dan sumber daya lainnya sehingga tampil dengan ukuran yang sesuai untuk layar perangkat tersebut, tapi untuk pengalaman pengguna terbaik Anda harus menargetkan untuk menciptakan ilusi bahwa aplikasi Anda didesain khusus untuk perangkat pengguna tersebut. Mengandalkan pada penskalaan otomatis saja tidak akan membereskan masalah.
Untuk memastikan aplikasi Anda menyuguhkan pengalaman pengguna terbaik bagi sejumlah besar perangkat, Anda harus menyediakan sumber-sumber daya alternatif yang dioptimalkan untuk berbagai perangkat, seperti drawable yang menyasar generalisasi density bucket oleh Android, dan mengubah tata letak Android yang dioptimalkan untuk mode lanskap.
Begitu Anda selesai membuat sumber-sumber daya alternatif, Anda harus membuat direktori-direktori alternatif yang ditandai dengan kualifikasi konfigurasi yang sesuai, dan kemudian menempatkan sumber-sumber daya di dalam direktori tersebut—misalnya direktori res/layout-land akan berisi tata letak yang didesain untuk orientasi lanskap. Sistem Android akan secara otomatis memuat sumber daya yang paling sesuai dengan konfigurasi layar saat itu pada runtime.
Meskipun kebanyakan konfigurasi kualifikasi bersifat relatif langsung, menyediakan sumber daya yang menyasar ukuran layar yang berbeda-beda sedikit lebih kompleks, mengharuskan Anda secara tepat menentukan nilai dpi yang sumber daya tersebut harus dipakai oleh sistem. Jadi, pada dasarnya Anda harus memberitahu sistem, "Saya ingin menggunakan layout ini ketika aplikasi saya ditampilkan di perangkat dengan lebar layar 800 dpi atau lebih."
Anda mencapai nilai tersebut dengan menguji aplikasi Anda pada berbagai perangkat android virtual (AVD) yang berbeda dan mencatat semua ukuran layar yang sumber daya default tampak kesulitan dengannya—misalnya, mungkin tata letak default Anda terlihat berantakan begitu dijalankan pada perangkat yang ambang batas dpi-nya di bawah nilai tertentu.
Ada tiga kualifikasi ukuran layar yang bisa Anda pakai dalam proyek Anda:
smallestWidth sw<value>dp. Memungkinkan Anda mengatur ruang horisontal minimum yang harus ada sebelum sistem bisa menggunakan sumber daya di direktori ini. Misalnya, jika Anda mengatur tata letak yang membutuhkan 800 dpi atau lebih, Anda akan membuat direktori res/layout-sw800dp. Perhatikan bahwa
smallestWidthsuatu perangkat adalah nilai tetap yang tidak berubah ketika pengguna mengganti orientasi perangkat mereka antara potret dan lanskap.Available screen width w<value>dp. Ruang horisontal minimal yang harus ada sebelum sistem bisa menggunakan sumber daya ini. Nilai
w<value>dpperangkat berubah ketika pengguna berpindah antara mode potret dan lanskap.Available screen height: h<value>dp. Panjang minimal yang harus ada sebelum sistem bisa menggunakan sumber daya ini. Nilai
h<value>dpperangkat akan berubah tergantung pada posisi pemakai memegangnya, apakah lanskap atau potret.
Merancang untuk berbagai ukuran layar sebagian besar adalah tentang membuat versi alternatif sumber daya proyek Anda dan menambahkannya ke direktori yang tepat—lalu coba dan coba lagi. Meskipun demikian, ada beberapa tambahan trik yang bisa digunakan ketika membuat sumber daya alternatif yang sungguh dapat membantu dalam menciptakan ilusi yang seakan aplikasi Anda dirancang khusus untuk perangkat pengguna tersebut.
Gunakan drawables yang density-specific dikombinasikan dengan gambar 9-patch. Jika sistem harus mengubah ukuran gambar agar sesuai dengan layar yang ada, secara default sistem akan mengubah ukuran keseluruhan suatu gambar, ini bisa mengakibatken gambar jadi kabur, terpikselasi, atau tampak janggal. Untuk hasil yang sebaik mungkin, Anda harus menspesifikasi berapa piksel tepatnya yang harus direplikasi sistem jika akan mengubah gambar Anda, dengan menyajikan drawable proyek Anda sebagai gambar 9-patch. Sediakan berbagai versi 9-patch untuk tiap drawable, tiap 9-patch tersebut menyasar densitas layar yang berbeda, dan sistem akan memuat gambar 9-patch yang paling sesuai untuk densitas layar yang ada dan jika diperlukan akan meregangkan bagian gambar 9-patch yang 'bisa diregangkan'. Anda bisa membuat gambar 9-patch dengan menggunakan PNG editor apa saja, atau Anda bisa menggunakan editor Draw 9-patch yang termasuk dalam Android SDK (bisa ditemukan di sdk/tools/Draw9patch.bat).
Buat sejumlah file dimens.xml. Direkomendasikan agar Anda mendefinisikan nilai tata letak di file dimens.xml yang berbeda daripada melakukan hard-code ke dalam proyek Anda. Meskipun begitu, Anda bisa selangkah lebih maju dan membuat berbagai file dimens.xml yang menyasar ukuran dan densitas layar yang berbeda-beda. Misalnya, Anda bisa membuat file values-ldpi/dimens.xml yang di situ Anda mendefinisikan nilai yang harus digunakan aplikasi Anda ketika dipasang di perangkat yang masuk kategori kerapatan rendah. Kemudian sistem akan memuat dimensi yang sesuai untuk perangkat yang ada, dan menerapkannya ke tata letak anda.
Pertimbangkan untuk menggunakan fragmen. Fragmen menyediakan Anda cara membagi satu
Activitytunggal ke dalam beberapa komponen terpisah yang menampilkan dengan cara yang berbeda-beda, tergantung konfigurasi layar yang berlaku. Sebagai contoh, Anda mungkin memilih untuk menampilkan sejumlah fragmen berdampingan dalam suatu layout multi-panel ketika aplikasi Anda dipasang di suatu perangkat yang layarnya lebih besar dan sebagai aktivitas yang berbeda ketika ruannya lebih terbatas. Cara termudah menambahkan fragmen ke layout Anda adalah dengan memasukkan elemen<fragment>ke dalam file sumber daya layout-nya. Sebagai alternatif, Anda bisa menambahkan beberapa fragmen melalui kode aplikasi—metode ini mungkin lebih rumit, tapi memberi Anda fleksibilitas untuk menambah, menghapus, atau mengganti fragmen pada saat runtime.
3. Pertimbangkan Mendukung Bahasa-Bahasa yang Berbeda
Android adalah sistem operasi global, jadi jika aplikasi Anda akan menyuguhkan pengalaman pengguna yang terbaik bagi audiens global, Anda harus mempertimbangkan untuk menerjemahkan aplikasi Anda ke berbagai bahasa dan, wilayah-wilayah yang berbeda.
Pada umumnya, bagian terbesar dalam melokalkan suatu aplikasi adalah dengan menerjemahkan file strings.xml suatu proyek ke bahasa-bahasa yang berbeda yang ingin Anda dukung. Kecuali Anda juga fasih dalam bahasa target, Anda akan membutuhkan bantuan seorang penerjemah. Jika Anda tidak punya ide menghubungi penerjemah mana, layanan Developer Console di Google Play App Translation bisa menunjukkan pada Anda para penerjemah potensial.
Begitu Anda memilih penerjemah, Anda harus melihat dengan cermat file strings.xml Anda sebelum mengirimkannya untuk diterjemahkan. Periksa apakah ada salah ejaan atau salah ketik, dan pastikan strings.xml Anda diformat sedemikian rupa sehingga mudah dibaca. Pahami bahwa penerjemahnya mungkin bukan seorang developer Android.
Anda juga harus memberikan sebanyak mungkin konteksnya, jadi pastikan Anda memberikan komentar pada tiap string untuk menjelaskan untuk apa string tersebut, dan di mana atau kapan akan muncul di aplikasi Anda, dan tiap batasan yang harus dipahami penerjemah. Misalkan, jika suatu string panjangnya harus di bawah 10 karakter agar sesuai dengan ruang yang tersedia di layout, maka hal ini harus diketahui dengan jelas oleh penerjemah.
Sekalinya penerjemah mengembalikan file strings.xml Anda yang sudah diterjemahkan, Anda harus membuat direktori untuk tiap file alternatif, artinya Anda harus menggarap qualifier konfigurasi yang akan digunakan.
Kualifikasi konfigurasi lokal terdiri dari sebuah Kode ISO, yang pada dasarnya adalah kode bahasa, dan pilihan negara atau kode daerah, yang didahului dengan huruf kecil r. Misalnya, jika anda ingin memberikan Bahasa Perancis (fr) untuk orang yang terletak di Kanada (acan), maka anda perlu membuat direktori res/values-fr-rcan.
Jika anda memberikan teks lokal, ingatlah bahwa beberapa kalimat mungkin berkembang atau menyusut secara signifikan selama terjemahan, jadi anda harus menguji tata letak anda untuk mengakomodasi semua versi pada proyek anda.
Cara termudah untuk menguji sumber daya lokal anda adalah memasang aplikasi anda di AVD dan kemudian meniru berbagai pengaturan lokasi dan bahasa. Pada titik ini, sistem akan memuat versi lokal sumber daya anda dan menampilkannya di aplikasi anda.
Anda dapat mengubah setelan lokal dalam AVD yang sedang berjalan dengan mengeluarkan perintah berikut pada Debug Bridge (adb):
1 |
adb shell |
Diikuti oleh:
1 |
setprop persist.sys.locale fr-CAN;stop;sleep 5;start |
Perhatikan, anda harus mengganti fr-CAN dengan konfigurasi apa pun yang ingin anda uji coba.
Jika anda telah merancang aplikasi anda dengan praktik terbaik, maka tata letak anda harus cukup fleksibel untuk menampilkan sebagian besar string lokal anda. Namun, jika panjang senar anda bervariasi secara dramatis, anda mungkin perlu memberikan tata letak alternatif yang dioptimalkan untuk lokasi yang berbeda.
Sementara file proyek strings.xml anda umumnya merupakan sumber utama yang anda perlukan untuk dilokalkan, anda juga harus mempertimbangkan apakah ada sumber lain yang mungkin perlu anda terjemahkan seperti drawables yang berisi teks, video, atau audio yang berisi dialog, atau sumber daya yang mungkin tidak sesuai untuk lokal yang anda targetkan
Setelah yakin bahwa anda telah menyediakan semua sumber daya terlokalisasi yang diperlukan dan anda telah melakukan pengujian sendiri, anda harus mempertimbangkan untuk mengatur tes beta dengan penutur asli di setiap lokasi target anda. Penutur asli sering kali mengalami kesalahan yang mungkin ditanggung oleh penerjemah, dan mungkin dapat memberi anda beberapa saran tentang bagaimana anda dapat membuat aplikasi anda lebih menarik bagi pendengar anda. Anda bisa mengatur jenis pengujian beta yang ditargetkan ini melalui Konsol Pengembang Google Play.
Saat anda akhirnya siap meluncurkan aplikasi anda, pastikan anda meluangkan waktu untuk membuat versi lokal dari laman aplikasi Google Play anda, karena ini akan membuat aplikasi anda lebih menarik bagi pengguna internasional yang menjelajahi Google Play store. Anda juga harus mencoba dan menyediakan tangkapan layar yang dengan jelas menampilkan teks yang dilokalkan di dalam aplikasi anda, sehingga pengguna tidak bertanya-tanya apakah anda baru saja menterjemahkan halaman aplikasi Google Play anda, dan bukan teks sebenarnya di dalam aplikasi anda.
Dan kerja keras tidak berakhir begitu anda meluncurkan aplikasi anda! Begitu anda menarik perhatian pemirsa internasional anda, anda harus mengatasinya dengan memberikan dukungan terus-menerus di berbagai bahasa-bahkan jika itu berarti beralih ke penerjemah mesin seperti Google Translate. Paling tidak, anda harus mengawasi ulasan Google Play anda, untuk melihat apakah pengguna di lokasi tertentu melaporkan masalah serupa, yang mungkin menunjukkan adanya masalah dengan satu atau beberapa sumber daya lokal aplikasi anda.
4. Jangan lupa tentang aksesibilitas!
Sebagai pengembang aplikasi, anda harus memastikan bahwa setiap orang dapat menikmati penggunaan aplikasi anda, jadi penting untuk mempertimbangkan bagaimana aplikasi anda dapat diakses oleh orang-orang yang mungkin mengalaminya tanpa suara, warna atau visual lainnya, atau siapa saja yang berinteraksi dengan perangkat Android mereka melalui alat aksesibilitas seperti pembaca layar.
Android dirancang dengan aksesibilitas dalam pikiran, sehingga memiliki sejumlah fitur akses bawaan yang dapat anda manfaatkan tanpa harus membuat perubahan mendasar pada kode aplikasi anda.
Mari kita lihat sejumlah tweak kecil yang dapat anda lakukan pada proyek anda, yang akan berdampak besar pada aksesibilitas aplikasi anda:
Pertimbangkan untuk Menyediakan Deskripsi Konten Tambahan
Layanan aksesibilitas seperti TalkBack membaca teks di layar secara keras, menjadikannya alat penting untuk membantu pengguna yang memiliki masalah terkait penglihatan berinteraksi dengan perangkat Android mereka.
Saat merancang aplikasi Android anda, anda harus mempertimbangkan betapa mudahnya pengguna menavigasi aplikasi anda menggunakan teks di layarnya saja. Jika anda perlu memberikan beberapa konteks tambahan, anda dapat menambahkan deskripsi konten ke komponen UI aplikasi anda, yang kemudian akan dibacakan dengan keras oleh layanan seperti TalkBack. Untuk menambahkan deskripsi konten, buka file sumber tata letak proyek anda dan tambahkan atribut android:contentDescription ke komponen UI yang dimaksud, diikuti dengan deskripsi yang ingin anda gunakan.
Dukungan Fokus Navigasi
Pengguna dengan penglihatan terbatas atau ketangkasan manual terbatas mungkin merasa lebih mudah berinteraksi dengan perangkat mereka menggunakan pengontrol terarah, seperti trackpad, D-pad atau keyboard, atau perangkat lunak yang mengemulasi pengendali terarah. Untuk memastikan aplikasi anda mendukung jenis navigasi fokus, anda harus menambahkan atribut android:focusable="true" ke setiap komponen navigasi aplikasi anda.
Saat pengguna menavigasi aplikasi anda menggunakan kontrol terarah, fokus akan beralih dari satu elemen UI ke elemen lainnya dengan sebuah perintah yang ditentukan secara otomatis dengan menggunakan algoritma. Namun, anda dapat mengganti default ini dan menentukan komponen UI mana yang harus mendapatkan fokus saat pengguna bergerak ke arah tertentu, dengan menambahkan atribut XML berikut ke komponen UI anda: android:nextFocusUp, android:nextFocusDown, android:nextFocusLeft, dan android:nextFocusRight. Sebagai contoh:
1 |
<?xml version="1.0" encoding="utf-8"?>
|
2 |
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" |
3 |
xmlns:tools="http://schemas.android.com/tools" |
4 |
android:id="@+id/activity_main" |
5 |
android:layout_width="match_parent" |
6 |
android:layout_height="match_parent" |
7 |
tools:context="com.jessicathornsby.myapplication.MainActivity"> |
8 |
|
9 |
<TextView
|
10 |
android:layout_width="wrap_content" |
11 |
android:layout_height="74dp" |
12 |
android:text="Hello World!" |
13 |
android:id="@+id/textView" |
14 |
android:focusable="true" |
15 |
android:nextFocusDown="@+id/checkBox" |
16 |
/>
|
17 |
|
18 |
<CheckBox
|
19 |
android:text="CheckBox" |
20 |
android:layout_width="wrap_content" |
21 |
android:layout_height="wrap_content" |
22 |
android:id="@+id/checkBox" |
23 |
android:layout_weight="1" |
24 |
android:focusable="true" |
25 |
android:nextFocusUp="@+id/textView" |
26 |
/>
|
27 |
|
28 |
</LinearLayout>
|
Bualah agar Ukuran Teks Anda Bisa Diatur
Pengguna dengan gangguan penglihatan dapat memilih untuk meningkatkan ukuran font yang muncul di perangkat mereka. Untuk memastikan perubahan font apa pun tercermin dalam aplikasi anda, tentukan teks anda dalam skala piksel-dan jangan lupa untuk menguji dampak berbagai ukuran font Android pada UI aplikasi anda, kalau-kalau anda perlu melakukan beberapa penyesuaian pada tata letak.
Gunakan Fitur Sasaran Sentuhan yang Disarankan
Untuk membantu orang dengan ketangkasan manual menavigasi aplikasi anda, disarankan agar anda menetapkan semua target sentuh menjadi 48 x 48 dpi atau lebih tinggi, dan pastikan jarak antara target ini minimal 8 dpi.
Pertimbangkan Menonaktifkan Kontrol Waktu habis
Beberapa komponen UI dapat hilang secara otomatis setelah jangka waktu tertentu telah berlalu - misalnya, kontrol pemutaran video sering kali hilang begitu video diputar selama beberapa saat.
Masalahnya adalah bahwa layanan aksesibilitas seperti Talkback tidak membaca kontrol sampai pengguna memusatkan perhatian pada mereka, jadi jika kontrol waktu habis hilang sebelum pengguna memiliki kesempatan untuk memusatkan perhatian padanya, maka mereka tidak akan sadar bahwa kontrol ini bahkan ada. Untuk alasan ini, anda harus mempertimbangkan untuk meningkatkan kontrol batas waktunya menjadi permanen kapan pun layanan aksesibilitas diaktifkan.
5. Menempatkan Kinerja Aplikasi anda ke Tes
Hanya karena aplikasi anda tidak mogok atau membuang kesalahan selama pengujian, tidak secara otomatis berarti kinerjanya baik, karena beberapa masalah kinerja dapat menjadi berbahaya dan sulit dikenali saat pengujian reguler. Tidak ada yang suka menggunakan aplikasi yang membutuhkan waktu lama untuk dimuat, tertinggal setiap kali anda mencoba dan berinteraksi dengannya, dan melahap memori yang ada, jadi anda harus selalu meletakkan aplikasi anda melalui sejumlah tes berbasis kinerja sebelum melepaskannya ke pasar. .
Android SDK hadir dengan berbagai macam alat yang dapat anda gunakan untuk menguji kinerja aplikasi anda secara spesifik. Pada bagian ini, kita akan melihat beberapa yang pastinya ingin anda gunakan; Namun, masih banyak lagi yang perlu diselidiki (anda akan menemukan lebih banyak informasi di dokumen Android resmi).
Perhatikan bahwa semua alat ini hanya dapat berkomunikasi dengan aplikasi yang sedang berjalan, jadi anda harus memastikan aplikasi yang ingin anda uji terpasang pada perangkat AVD atau perangkat fisik yang terhubung ke mesin pengembangan anda.
Sebelum memulai, perlu dicatat bahwa jika anda mengidentifikasi masalah dengan kinerja aplikasi anda, disarankan agar anda memberi kode sebelum mencoba mengatasi masalah ini. Anda kemudian dapat mengatur kode anda lagi setelah anda yakin telah memperbaiki masalah, dan anda akan dapat melihatnya persis apa dampak perubahan anda terhadap kinerja aplikasi anda.
Anda bisa menggunakan kode waktu anda menggunakan TraceView, yang anda akses dengan memilih Android Device Monitor's DDMS tab, lalu memilih perangkat dan proses yang ingin anda profilkan, dan mengeklik Mulai Metode Profiling (di mana kursor diposisikan di tangkapan layar berikut).
Pada titik ini anda bisa memilih salah satunya Trace based profiling (melacak masuk dan keluar dari setiap metode) atau Contoh pembuatan profil berdasarkan (mengumpulkan tumpukan panggilan pada frekuensi yang ditentukan oleh anda). Setelah memilih, luangkan waktu untuk berinteraksi dengan aplikasi anda. Bila sudah siap untuk melihat hasilnya, anda bisa memuatkan trace file ke viewer dengan mengeklik ikon Hentikan Metode Profil. File jejak menampilkan eksekusi setiap thread sebagai baris terpisah, sehingga anda dapat melihat dengan pasti berapa lama untuk menjalankan setiap bagian proyek anda.
Mengidentifikasi Overdraw
Saat sistem menarik UI aplikasi anda, layar akan dimulai dengan penampung tingkat tertinggi dan kemudian berhasil melewati hierarki tampilan anda, berpotensi menarik penayangan satu sama lain dalam proses yang dikenal sebagai penawaran berlebih. Meskipun sejumlah overdraw tertentu tidak dapat dihindari, anda dapat mengurangi waktu yang dibutuhkan aplikasi anda untuk ditahan dengan mengidentifikasi dan menghapus contoh overdraw yang berlebihan atau tidak perlu.
Jika anda memiliki perangkat yang menjalankan Android 4.2 atau lebih tinggi, anda dapat memeriksa jumlah penawaran berlebih di aplikasi yang terpasang pada perangkat tersebut, dengan memilih Pengaturan > Developer Options > Debug GPU Overdraw > Pilih daerah overdraw. Sistem kemudian akan menambahkan overlay berwarna untuk setiap area layar, yang menunjukkan bahwa jumlah kali setiap pixel telah ditarik:
Tanpa warna. Pixel ini dicat sekali
Biru. Overdraw 1x. Pixel ini dilukis dua kali.
Hijau. Overdraw 2x.
Merah terang. Overdraw 3x.
Merah gelap. Overdraw 4x atau lebih.
Sebagian besar aplikasi mencakup beberapa tingkat overdraw, namun jika anda melihat banyak jenis penawaran berlebihan di aplikasi anda, maka anda harus melihat apakah ada cara untuk mengurangi frekuensi piksel digambar ulang, dan salah satu metode yang efektif adalah menghapus tampilan yang tidak perlu. .
Perisai Hirarki Monitor Perangkat Android memberikan ikhtisar tingkat tinggi dari keseluruhan hierarki tampilan aplikasi anda, yang dapat membantu anda mengidentifikasi tampilan yang tidak menyumbang apa pun ke gambar akhir yang diberikan pengguna di layar.
Untuk meluncurkan Hierarchy Viewer, klik tombol Tampilan hirarki pada Android Device Monitor's, lalu pilih perangkat dan Aktivitas yang ingin anda periksa, diikuti dengan warna ikon biru Memuat tampilan hirarki ke tampilan pohon.
anda mungkin juga ingin mengekspor keluaran Hierarchy Viewer sebagai dokumen Photoshop. Ini adalah teknik yang sangat efektif untuk mengidentifikasi pandangan yang tidak menyumbang apa pun ke versi final UI, karena setiap tampilan ditampilkan sebagai lapisan Photoshop terpisah, yang berarti anda dapat menyembunyikan dan mengungkapkan setiap lapisan dan melihat secara tepat dampak apa yang akan terjadi pada akhir gambar yang dilihat pengguna di layar.
Untuk membuat dokumen PSD, cukup mengklik ikon Tangkap lapisan jendela sebagai dokumen Photoshop/ Capture the window layers as a Photoshop document.
Spotting Memory Leaks/ Bercak kebocoran memori
Pengumpulan sampah (GC) adalah perilaku sistem normal yang penting untuk memastikan aplikasi dan perangkat anda secara keseluruhan terus berjalan dengan lancar.
Namun, jika aplikasi anda tidak mengelola memori dengan benar-mungkin ini akan menyebabkan memori bocor atau mengalokasikan sejumlah besar objek dalam waktu singkat - maka ini dapat memicu GC yang lebih sering yang juga berjalan lebih lama. Anda dapat melihat peristiwa GC apa yang terjadi di aplikasi anda di jendela utama Android Studio; Buka tab Android Monitor menuju bagian bawah jendela, diikuti oleh tab Monitor. Alat Monitor Memori kemudian akan mulai merekam penggunaan memori aplikasi anda secara otomatis.
Jika anda terus berinteraksi dengan aplikasi anda, maka pada akhirnya anda akan melihat penurunan tiba-tiba pada jumlah memori yang dialokasikan, yang menunjukkan bahwa peristiwa GC telah terjadi. Ulangi proses ini, pastikan anda menjelajahi berbagai area aplikasi anda, dan lihat dampaknya terhadap GC ini. Jika anda melihat perilaku GC yang aneh, maka anda ingin menyelidiki lebih lanjut karena ini mungkin menunjukkan adanya masalah dengan cara aplikasi anda menggunakan memori.
Ada beberapa alat yang dapat anda gunakan untuk mengumpulkan lebih banyak informasi tentang penggunaan memori aplikasi anda. Pertama, anda bisa menggunakan tab Heap pada Android Device Monitor untuk melihat berapa banyak tumpukan memori yang digunakan disetiap proses, yang akan menandai proses yang melahap memori yang ada.
Untuk menggunakan alat Heap, pilih tab DDMS pada Android Device Monitor, diikuti dengan proses yang ingin anda periksa, lalu klik tombol Update heap. Tab Heap tidak akan menampilkan data apapun sampai setelah peristiwa GC terjadi, namun jika anda merasa tidak sabar, anda selalu dapat memicu acara GC dengan mengklik tombol Cause GC.
Alat lain yang dapat membantu anda mengumpulkan informasi tentang penggunaan memori aplikasi anda adalah Pelacak Alokasi, yang memungkinkan anda melihat dengan tepat objek yang dialokasikan aplikasi anda ke memori. Untuk menggunakan Allocation Tracker, pilih tab DDMS pada Android Device Monitor, diikuti oleh Alokasi Tracker dan proses yang ingin anda periksa.
Klik tombol Start Tracking dan luangkan waktu untuk berinteraksi dengan aplikasi anda, terutama bagian yang anda duga mungkin menyebabkan masalah pengelolaan memori aplikasi anda. Untuk melihat semua data yang telah dikumpulkan Allocation Tracker selama periode sampling, pilih tombol Start Tracking, diikuti oleh tombol Get Allocations.
6. Gunakan Alat Analytics
Memahami audiens anda adalah bagian penting dalam membuat aplikasi yang sukses.
Memiliki akses ke data tentang siapa audiens anda dan bagaimana mereka menggunakan aplikasi anda berarti anda dapat membuat keputusan yang lebih tepat tentang bagaimana membangun kesuksesan aplikasi anda - dan memperbaiki area di mana aplikasi anda tidak berjalan dengan baik.
Mengumpulkan data pengguna semacam ini sangat berguna untuk memungkinkan anda mengidentifikasi tren di berbagai bagian pemirsa anda. Misalnya, anda mungkin memutuskan bahwa segmen tertentu dari audiens anda sangat berharga-mungkin mereka mengumpulkan persentase pembelian terbesar dalam aplikasi, atau mereka menginvestasikan jumlah waktu di atas rata-rata di aplikasi anda. Dengan berbekal informasi ini, anda dapat mengambil langkah ekstra untuk mendukung pengguna ini, memastikan pengguna anda yang paling berharga tetap terlibat dengan aplikasi anda.
Di sisi lain, anda mungkin menemukan area di mana aplikasi anda sedang berjuang. Misalnya, mungkin pengguna yang menjalankan versi Android tertentu memiliki tingkat keterlibatan yang jauh lebih rendah, atau lebih cenderung mencopot pemasangan aplikasi anda. Dalam skenario ini, anda mungkin ingin menguji aplikasi anda pada versi Android tertentu ini untuk melihat apakah ada bug atau kesalahan lainnya yang mungkin merusak pengalaman pengguna untuk bagian basis pengguna anda ini.
Pada dasarnya, semakin banyak data yang dapat anda kumpulkan tentang pemirsa dan tingkah lakunya, semakin besar peluang anda untuk membuat pengguna anda tetap bahagia, menarik pengguna baru, dan umumnya memberikan pengalaman hebat yang serba untuk semua orang yang berhubungan dengan aplikasi anda.
Pada bagian ini, saya akan melihat dua layanan yang dapat memberi banyak informasi untuk anda: Firebase Analytics dan Konsol Pengembang Google Play.
Firebase
Anda dapat menggunakan Firebase Analytics untuk mengumpulkan data tentang pengguna anda, seperti usia, jenis kelamin, dan lokasi mereka, ditambah informasi tentang lebih dari 500 acara dalam aplikasi. Anda bahkan dapat menentukan acara kustom anda sendiri jika diperlukan.
Untuk menambahkan Firebase Analytics ke proyek anda, anda memerlukan layanan Google Play 10.0.1 atau versi yang lebih tinggi dan Google Repository versi 26 atau lebih tinggi, jadi buka Pengelola SDK dan pastikan komponen ini terbaru. Anda juga perlu menjalankan Android Studio 1.5 atau lebih tinggi, dan mendaftar untuk akun Firebase gratis.
Jika anda menjalankan Android 2.2 atau yang lebih baru, anda dapat menghubungkan aplikasi anda ke Firebase Analytics menggunakan Asisten Firebase. Buka Android Studio, luncurkan proyek yang dimaksud, dan:
Memilih Alat > Firebase dari toolbar Android Studio.
Klik untuk memperluas bagian Analytics, lalu pilih link Log an Analytics event.
Klik tombol Hubungkan ke Firebase.
Dalam dialog yang muncul, pilih untuk membuat proyek Firebase baru.
Klik tombol Hubungkan ke Firebase/ Connect to Firebase.
Setelah beberapa saat, anda seharusnya akan melihat pesan Terhubung.
Kemudian Klik tombol Tambahkan analytics ke aplikasi anda/ Add analytics to your app
Dalam dialog berikutnya, klik Terima perubahan/ Accept changes.
Dan itu dia! anda sekarang dapat melihat semua data Firebase Analytics anda dengan masuk ke Konsol Firebase, memilih proyek yang ingin anda periksa, lalu memilih Analytics. Data ini akan diperbarui secara berkala sepanjang hari.
Konsol Pengembang
Anda juga dapat memperoleh wawasan berharga tentang kinerja dan perilaku pengguna aplikasi anda melalui Konsol Pengembang.
Untuk melihat data ini, masuk ke akun Konsol Pengembang anda, pilih aplikasi yang ingin anda periksa, lalu pilih Dasbor dari menu sebelah kiri.
Konsol Pengembang berisi banyak informasi bermanfaat, jadi anda perlu meluangkan waktu untuk menjelajahi berbagai bagiannya secara mendetail. Namun, ada beberapa area yang mungkin menarik perhatian:
Kinerja Akuisisi Pengguna/ User Acquisition Performance. Bagian ini berisi rincian tentang bagaimana pengguna menemukan cantuman Google Play aplikasi anda, misalnya persentase pengguna yang mendarat di laman anda melalui UTM-tagged Link, iklan AdWords, atau jumlah orang yang menemukan aplikasi anda hanya dengan browsing Google Play Store.
Keuangan. Jika anda menerapkan strategi monetisasi, seperti produk dalam aplikasi atau opsi langganan, anda dapat menggunakan Konsol Pengembang untuk meninjau kinerja keuangan aplikasi anda. Keuangan ini merupakan bagian berisi informasi seperti jumlah rata-rata setiap pengguna yang membayar berinvestasi di aplikasi anda, berapa banyak pendapatan dihasilkan oleh setiap produk yang anda tawarkan melalui aplikasi anda, dan berapa banyak setiap bagian basis pengguna anda dibelanjakan, berdasarkan faktor-faktor seperti lokasi geografis, usia, dan versi Android yang mereka gunakan.
Crashes & ANRs. Bagian ini berisi semua data yang diajukan pengguna tentang kesalahan aplikasi dan aplikasi yang tidak merespons (ANR), memberi anda kesempatan untuk mengidentifikasi dan memperbaiki masalah apa pun yang mungkin terjadi di aplikasi anda sebelum pengguna mulai meninggalkan ulasan negatif di Google Play. Perhatikan bahwa mogok yang tidak dilaporkan oleh pengguna anda tidak akan muncul di Konsol Pengembang.
Anda mungkin juga ingin mempertimbangkan untuk mendownload aplikasi Konsol Pengembang Google Play, yang memungkinkan anda meninjau semua informasi ini saat dalam perjalanan.
Kesimpulan
Pada artikel ini, kami melihat enam hal yang seharusnya dan tidak seharusnya dilakukan saat anda mengembangkan aplikasi Android. Apa saja aturan emas anda untuk merancang pengalaman pengguna yang hebat? Tinggalkan komentar di bawah ini dan beri tahu kami.
Sementara itu, lihat beberapa kursus dan tutorial kami yang lain tentang pemrograman Android!
