Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Android

Mendeteksi dan mengatasi masalah kinerja di Android

by
Difficulty:IntermediateLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Sandi Muamar (you can also view the original English article)

Pengenalan

Tidak peduli seberapa inovatif dan berguna aplikasi Android Anda adalah, jika laggy, rentan terhadap pembekuan, atau babi memori, tidak ada yang akan ingin menggunakannya.

Kinerja sangat penting, tetapi juga sesuatu yang mudah untuk melupakan saat Anda sibuk menempatkan sentuhan akhir untuk antarmuka pengguna indah Anda atau datang dengan fitur baru dan menarik untuk app Anda.

Begitulah, sampai Google Play Play negatif ulasan mulai bergulir masuk.

Dalam artikel ini, Anda akan mendapatkan sebuah kursus kilat dalam masalah kinerja umum setiap Developer Android perlu menyadari. Anda akan belajar bagaimana untuk menguji apakah masalah ini terjadi dalam proyek Anda sendiri, menggunakan tools yang disediakan oleh Android SDK — ditambah satu tool yang sudah diinstal pada perangkat Android Anda.

Jika Anda menemukan masalah kinerja di app, jelas Anda akan ingin untuk memperbaikinya. Jadi sepanjang jalan kita juga akan melihat bagaimana untuk menggunakan perangkat Android SDK untuk mengumpulkan informasi lebih lanjut tentang apa pun masalah kinerja yang Anda menemukan. Setelah Anda memiliki informasi ini, Anda akan memiliki pemahaman yang lebih baik tentang bagaimana untuk menyempurnakan kinerja aplikasi Anda dan akhirnya membuat aplikasi bahwa orang akan cinta menggunakan.

1. overdraw

Langkah 1: Masalah

Antarmuka pengguna aplikasi Anda adalah sambungan ke pengguna, tetapi menciptakan sesuatu yang terlihat bagus adalah hanya setengah pertempuran. Anda juga perlu memastikan antarmuka pengguna Anda menuliskan cepat dan berjalan lancar.

Salah satu penyebab paling umum dari antarmuka pengguna tidak responsif laggy adalah overdraw. Overdraw adalah dimana Anda membuang-buang waktu proses GPU dengan mewarnai di pixel yang hanya mendapatkan berwarna lagi oleh sesuatu yang lain.

Sebagai contoh, bayangkan latar belakang biru dengan beberapa teks di atasnya. Android tidak hanya cat daerah biru yang terlihat ke pengguna, cat seluruh latar belakang biru dan kemudian menarik teks di atas. Ini berarti bahwa beberapa piksel berwarna dua kali, yang adalah overdraw.

Beberapa overdraw, seperti pada contoh di atas, tidak dapat dihindari. Terlalu banyak overdraw, namun, dapat memiliki dampak nyata pada kinerja aplikasi Anda sehingga Anda akan ingin meminimalkan overdraw sedapat mungkin.

Hal ini relatif mudah untuk memeriksa aplikasi Anda untuk overdraw. Overdraw dalam jumlah besar dapat menunjukkan masalah mendasar dengan antarmuka pengguna aplikasi Anda, seperti view dangan yang berlebihan-lebih pada nanti. Untuk alasan ini, ketika Anda menguji aplikasi Anda untuk masalah kinerja, overdraw adalah tempat yang masuk akal untuk memulai.

Langkah 2: Mendeteksi Overdraw

Kabar baiknya adalah bahwa perangkat Android Anda sudah memiliki fitur built-in yang memungkinkan Anda memeriksa jumlah overdraw dalam aplikasi apapun yang diinstal pada perangkat Anda.

Karena fitur ini hidup pada perangkat Anda, langkah pertama adalah menginstal aplikasi yang Anda inginkan untuk menguji pada perangkat Android Anda. Kemudian, untuk memeriksa jumlah overdraw, hanya membuka Settings perangkat Anda, pilih Developer Options, dan ketuk Debug GPU Overdraw diikuti oleh Show overdraw areas..

On your device select Settings Developer Options Debug GPU Overdraw Show overdraw area

Alat ini menggunakan blok warna untuk menyorot jumlah overdraw yang berbeda. Satu-satunya hal tersisa untuk dilakukan adalah peluncuran aplikasi yang Anda inginkan untuk menguji dan melihat apa situasi overdraw.

Launch your app and check the amount of overdraw
  • Tidak ada warna: Overdraw tidak ada. Ini berarti pixel hanya dicat sekali.
  • Biru: Overdraw 1 x. Pixel dicat dua kali.
  • Hijau. Overdraw x 2. Pixel dicat tiga kali. Sebagai aturan umum, Anda harus bertujuan untuk overdraw maksimum 2 x.
  • Cahaya merah: overdraw 3 x. Tergantung pada aplikasi Anda, kecil daerah lampu merah mungkin tidak dapat dihindari, tetapi jika Anda melihat menengah atau besar daerah merah maka Anda harus menyelidiki apa yang menyebabkan begitu banyak overdraw.
  • Merah tua: overdraw 4 x. Pixel dicat 5 kali, atau bahkan mungkin lebih. Anda pasti ingin mencari tahu apa yang menyebabkan daerah merah gelap.

Langkah 3: Meminimalkan Overdraw

Sekali Anda telah mengidentifikasi area signifikan overdraw, cara termudah untuk mengurangi overdraw ini adalah untuk membuka file XML aplikasi Anda dan mencari daerah yang tumpang tindih, khususnya setiap drawables yang tidak terlihat oleh pengguna, dan latar belakang apapun yang sedang ditarik di atas satu sama lain.

Anda juga harus mencari tempat-tempat yang mana latar belakang atribut diatur ke putih, meskipun orang tua sudah memiliki dicat dengan latar belakang putih. Semua hal ini dapat menyebabkan signifikan overdraw.

Sistem Android otomatis dapat mengurangi kasus-kasus sederhana dari overdraw, tapi perlu dicatat bahwa ini tidak meluas ke tampilan kustom yang kompleks dimana Android tidak memiliki wawasan ke dalam bagaimana Anda menggambar konten Anda.

Jika Anda menggunakan kompleks tampilan kustom dalam aplikasi Anda, maka Anda dapat menentukan batas-batas drawable untuk pandangan Anda menggunakan metode clipRect. Untuk informasi lebih lanjut, saya sarankan mengunjungi Android dokumentasi resmi.

2. Android Rendering Pipeline

Langkah 1: Masalah

Penyebab umum lainnya masalah kinerja, adalah aplikasi Anda lihat hirarki. Untuk membuat setiap view, Android berjalan melalui tiga tahap:

  1. ukuran
  2. tata letak
  3. Menggambar

Waktu yang dibutuhkan Android untuk menyelesaikan tahap ini sebanding dengan jumlah view dalam hirarki Anda. Ini berarti bahwa salah satu cara termudah untuk mengurangi kecepatan rendering aplikasi Anda adalah untuk mengidentifikasi dan menghapus setiap view yang tidak memberikan kontribusi untuk gambar akhir pengguna melihat pada perangkat mereka.

Bahkan jika semua view dalam hirarki Anda diperlukan, jalan ini disusun dapat memiliki dampak yang signifikan pada fase ukuran proses pengubahan. Secara umum, semakin dalam hirarki view Anda, semakin lama dibutuhkan untuk menyelesaikan tahap pengukuran.

Selama proses render, setiap view menyediakan dimensi ke parent view. Jika parent view menemukan masalah dengan salah satu dimensi ini, itu dapat memaksa setiap child untuk remeasure.

Remeasurements bahkan dapat terjadi ketika tidak ada kesalahan. Sebagai contoh, layout relatif sering harus mengukur anak-anak mereka dua kali untuk mendapatkan segala sesuatu sesuai. Linear layout dengan child yang menggunakan layout_weight parameter rutin mengukur setiap child dua kali.

Tergantung pada bagaimana view Anda diatur, pengukuran dan remeasurements dapat mahal, memakan waktu proses yang memiliki dampak nyata pada kecepatan rendering aplikasi Anda.

Kunci untuk memastikan antarmuka pengguna Anda menuliskan cepat dan lancar, adalah untuk menghapus setiap tidak perlu dilihat dan mencari kesempatan untuk meratakan tata letak Anda.

Android SDK termasuk tool, Hierarchy Viewer, yang memungkinkan Anda memvisualisasikan hirarki seluruh view Anda. Alat ini membantu Anda menemukan view yang berlebihan dan bersarang layout.

Step 2: Penggunaan Hierarchy Viewer

Sebelum kita mengambil melihat lebih dekat pada tool Hierarchy Viewer, ada beberapa kebiasaan, Anda harus menyadari. Pertama, hirarki penampil hanya dapat berkomunikasi dengan aplikasi berjalan, bukan aplikasi source code anda. Ini berarti Anda akan perlu menginstal aplikasi yang Anda inginkan untuk menguji baik pada perangkat Android Anda atau menggunakan sebuah emulator.

Ada lain, lebih besar menangkap meskipun. Secara default, Hierarchy Viewer hanya dapat berkomunikasi dengan perangkat yang menjalankan versi development dari sistem operasi Android. Jika Anda tidak memiliki perangkat pengembang, Anda dapat berkeliling pembatasan ini dengan menambahkan kelas ViewServer aplikasi Anda.

Setelah Anda siap untuk mengambil Hierarchy Viewer untuk spin, peluncuran Android Studio dan pilih Tools dari toolbar, diikuti oleh Android dan Android Device Monitor.

Select Tools Android Android Device Monitor

Klik tombol Lihat Hierarchy View di sebelah kanan seperti ditunjukkan pada gambar di bawah.

Select the Hierarchy View button from the toolbar

Sepanjang sisi kiri layar adalah tab Windows yang berisi daftar semua perangkat Android yang terdeteksi dan emulator. Pilih perangkat Anda dan Anda akan melihat daftar proses yang berjalan pada perangkat. Pilih proses Anda ingin mengambil melihat lebih dekat dan tiga bidang Hierarchy Viewer akan diperbarui secara otomatis.

Ini tiga jendela menyediakan tiga berbeda representasi visual dari view hierarchy:

  • Tree View: View Anda lihat hirarki, di mana setiap node mewakili satu view.
  • Tree Overview: Peta representasi dari hirarki view Anda. View ini sangat berguna untuk mengidentifikasi peluang untuk meratakan tata letak Anda.
  • Layout View: Blok representasi dari view hierarchy Anda.

Ini tiga jendela yang terkait. Jika Anda memilih pandangan dalam satu jendela, itu akan muncul disorot dalam dua lainnya. Anda dapat menggunakan semua tiga jendela secara simultan untuk memburu dilihat setiap berlebihan bersembunyi di tampilan hierarki.

Select a view in one window and itll appear highlighted in the other two

Jika Anda tidak yakin apakah view yang benar-benar memberikan kontribusi apa-apa untuk gambar akhir, cukup pergi ke Tree View dan klik node yang bersangkutan. Anda akan melihat preview bagaimana pandangan ini akan muncul pada layar sehingga Anda dapat melihat persis apa view ini memberikan kontribusi untuk app Anda.

Tapi hanya karena view berkontribusi sesuatu untuk diberikan gambar akhir tidak berarti itu tidak juga berkontribusi terhadap masalah kinerja yang besar. Anda telah melihat bagaimana Anda dapat menggunakan Hierarchy Viewer jelas tempat bersarang layout, tetapi bagaimana jika bersarang menguras kinerja ini tidak begitu jelas? Atau bagaimana jika sesuatu yang lain yang menyebabkan view untuk membuat perlahan-lahan?

Kabar baiknya adalah bahwa Anda juga dapat menggunakan hirarki Viewer untuk profil berapa lama dibutuhkan setiap pandangan untuk bergerak melalui berbagai tahapan proses pengubahan. Ini memberi Anda cara untuk nol dalam pada masalah render yang mungkin tidak jelas pada pandangan pertama.

Bagian berikutnya akan menunjukkan cara menggunakan hirarki Viewer untuk profil pandangan yang berbeda dalam tata letak Anda spot masalah render yang mungkin bersembunyi di bawah permukaan.

Langkah 3: Per-Node Profiling

Cara termudah untuk mengidentifikasi hambatan dalam antarmuka pengguna Anda adalah dengan mengumpulkan data tentang berapa lama dibutuhkan masing-masing pandangan Anda untuk menyelesaikan ukuran, tata letak, dan menarik tahapan proses pengubahan.

Tidak hanya dapat Anda menggunakan hirarki Viewer untuk mengumpulkan informasi ini, hirarki Viewer juga menampilkan data ini dalam cara yang mudah untuk memahami, visual sehingga Anda dapat melihat sekilas view yang tidak berperforma baik.

Hirarki Viewer tidak menampilkan render kali secara default. Anda dapat menambahkan informasi ini dengan pergi ke Tree View dan memilih simp ul akar bagian pohon Anda ingin menguji. Selanjutnya, memanggil fitur profil hirarki penampil dengan mengklik ikon hijau, merah dan ungu diagram Venn seperti ditunjukkan pada gambar di bawah.

 To invoke Hierarchy Viewers profiling feature click the green red and purple Venn diagram icon

Tiga titik-titik berwarna akan muncul pada setiap node dalam bagian ini dari hirarki. Kiri-ke-kanan, titik-titik ini mewakili:

  • waktu yang dibutuhkan untuk mengukur view
  • waktu yang dibutuhkan untuk tata letak view
  • waktu yang dibutuhkan untuk draw view

Setiap titik juga memiliki warna yang ditetapkan:

  • Hijau: Untuk bagian ini waktu render, pandangan ini lebih cepat daripada setidaknya setengah dari node diprofilkan. Sebagai contoh, sebuah titik hijau di posisi tata letak berarti view ini memiliki waktu tata letak lebih cepat daripada setidaknya 50% dari node diprofilkan.
  • Kuning: Untuk bagian ini waktu render, view ini paling lambat 50% dari semua node diprofilkan.
  • Merah: Untuk bagian ini waktu render, view ini adalah yang paling lambat dari semua node diprofilkan.

Setelah mengumpulkan data ini, tidak hanya akan Anda tahu view Anda perlu mengoptimalkan, tapi Anda akan tahu persis bagian mana dari proses pengubahan menyebabkan pandangan itu untuk membuat lebih lambat.

Hanya menyadari bahwa meskipun dilihat dengan titik-titik kuning dan merah mungkin tempat yang logis untuk memulai upaya pengoptimalan, indikator kinerja ini adalah relatif terhadap diprofilkan node lain dalam hirarki view. Dengan kata lain, Anda selalu akan memiliki beberapa view yang diurai dengan lebih lambat daripada yang lain.

Sebelum Anda mulai menjelajahi kode untuk cara untuk mengoptimalkan pandangan tertentu, tanyakan pada diri Anda apakah view ini memiliki alasan yang baik untuk membuat lebih lambat dari node diprofilkan lain atau apakah ini benar-benar adalah kesempatan untuk mengurangi waktu render aplikasi Anda.

3. Memeory Leak

Langkah 1: Masalah

Meskipun Android lingkungan dikelola memori, jangan biarkan ini membuai Anda ke dalam rasa aman palsu — memori leak dapat masih terjadi. Hal ini karena garbage collection (GC) hanya dapat menghapus objek yang sudah mengenali sebagai terjangkau. Jika itu tidak melihat objek tidak terjangkau, maka objek yang tidak akan mendapatkan garbage collected.

Objek-objek ini terjangkau menggantung di sekitar, mencemari tumpukan Anda, dan mengambil ruang berharga. Sebagai aplikasi Anda terus leak objek, jumlah ruang yang dapat digunakan semakin kecil dan lebih kecil, yang pada gilirannya memicu lebih sering dan lebih lama GC peristiwa.

Ini adalah berita buruk untuk dua alasan. Pertama, sementara event GC biasanya tidak memiliki dampak nyata pada kinerja aplikasi Anda, banyak GC event yang terjadi di ruang kecil waktu dapat mengakibatkan laggy, tidak responsif user interface. Masalah kedua adalah bahwa perangkat mobile cenderung singkat pada memori untuk mulai dengan, sehingga memory leak dapat dengan cepat meningkat menjadi OutOfMemoryError, yang crash aplikasi Anda.

Memory leak bisa sulit untuk mendeteksi. Anda mungkin hanya menyadari bahwa memori adalah masalah untuk app Anda ketika pengguna mulai mengeluh. Syukurlah, Android SDK memiliki beberapa tool yang berguna yang dapat Anda gunakan untuk menjelajahi aplikasi Anda untuk tanda-tanda memory leak mereka kadang-kadang halus.

Langkah 2: Memori Monitor

Memori Monitor adalah cara mudah untuk mendapatkan gambaran tentang penggunaan memori aplikasi Anda dari waktu ke waktu. Perhatikan bahwa alat ini dapat hanya terhubung ke aplikasi berjalan, jadi pastikan Anda ingin menguji aplikasi diinstal pada perangkat Android Anda dan bahwa perangkat terpasang ke komputer Anda.

Alat ini dibangun dalam Android Studio, sehingga Anda mengaksesnya dengan mengklik tab Memory ke bagian bawah IDE Anda. Segera setelah memori Monitor mendeteksi aplikasi berjalan, itu mulai merekam penggunaan memori aplikasi Anda.

Memory Monitor is built into Android Studio you can access it by clicking the Memory tab

Jika memori Monitor tidak mulai merekam, periksa bahwa perangkat Anda dipilih dalam menu drop-down perangkat.

Jika memori Monitor kembali No debuggable applications pesan, buka Android Studio Tools menu, pilih Android dan membuat yakin Enable adb integration dipilih. Fitur ini bisa temperamental, jadi Anda mungkin perlu untuk Enable adb integration mengaktifkan dan menonaktifkan beberapa kali. Ini juga dapat membantu untuk menghapus perangkat Android dan kemudian menyambungkan kembali.

Setelah memori Monitor telah terdeteksi aplikasi berjalan, akan menampilkan jumlah memori aplikasi Anda menggunakan biru gelap dan belum dialokasikan memori warna biru muda.

Menghabiskan waktu berinteraksi dengan perangkat sementara mengawasi bagaimana penggunaan memori app's perubahan dalam memori Monitor. Akhirnya, memori dialokasikan akan tumbuh sampai tidak ada memory yang tersisa. Pada titik ini, sistem akan membebaskan memori dengan memicu acara GC. Setiap kali Anda melihat penurunan yang signifikan dalam memori dialokasikan, ini adalah tanda bahwa acara GC telah terjadi.

GC peristiwa normal, tetapi perlu khawatir jika Anda melihat aplikasi Anda mengalokasikan banyak memori dalam jangka waktu yang pendek atau GC peristiwa menjadi lebih sering. Ini adalah kedua tanda tanda-tanda bahwa kebocoran memori terjadi di app.

Jika Anda menggunakan memori Monitor untuk melacak tersangka memori kebocoran selama jangka waktu yang signifikan, Anda dapat melihat sistem Android mengkompensasi tuntutan memori berkembang aplikasi Anda dengan memberikan aplikasi Anda lebih tinggi memori langit-langit, di mana titik siklus dimulai lagi.

Akhirnya, Anda mungkin bahkan melihat aplikasi Anda memakan memori begitu banyak bahwa sistem tidak bisa lagi membuat setiap lebih banyak memori yang tersedia untuk aplikasi Anda. Jika Anda melihat ini terjadi, maka ada sesuatu yang tidak beres dengan cara aplikasi Anda menggunakan memori.

Langkah 3: Android Device Monitor

Alat lain yang dapat membantu Anda mengumpulkan informasi lebih lanjut tentang Memory Leak dan masalah lain yang berhubungan dengan memori Monitor perangkat Android Heap tab.

Heap tab dapat membantu Anda mendiagnosis kebocoran memori dengan menampilkan berapa banyak memori sistem telah mengalokasikan aplikasi Anda. Seperti telah disebutkan, jika memori dialokasikan terus meningkat, maka ini adalah indikasi yang kuat bahwa aplikasi Anda memiliki memory leak.

Tapi tool ini juga menyediakan banyak data tentang penggunaan heap aplikasi Anda, termasuk jenis objek aplikasi Anda mengalokasikan, jumlah objek dialokasikan, dan seberapa banyak ruang objek-objek ini mengambil. Informasi tambahan ini bisa tak ternilai ketika Anda sedang melacak memory leak dan masalah lain yang berkaitan dengan memori dalam aplikasi Anda.

Untuk mengakses tool bantu ini, meluncurkan Android perangkat Monitor dan pilih DDMS tab. Di panel Devices, pilih perangkat Anda dan proses yang Anda ingin memeriksa. Kemudian, pilih tab Heap, seperti ditunjukkan pada gambar di bawah, dan menghabiskan waktu berinteraksi dengan aplikasi Anda.

Launch Android Debug Monitor select DDMS and then click the Heap tab

Output tumpukan hanya ditampilkan setelah event GC, sehingga untuk mengisi tab ini dengan data Anda akan baik harus menunggu untuk acara GC terjadi secara alami atau Anda dapat memaksa GC dengan mengklik tombol Cause GC.

Setelah event GC telah terjadi, Heap tab akan memperbarui banyak informasi tentang penggunaan tumpukan aplikasi Anda. Data ini akan menyegarkan setelah setiap event GC.

Kesimpulan

Dalam tutorial ini, kita telah membahas beberapa masalah kinerja yang paling umum yang Anda harus menyadari ketika mengembangkan aplikasi Android, overdraw, memory leak, dan slow rendering antarmuka pengguna.

Anda juga harus mengatasi beberapa tool yang dapat Anda gunakan untuk memeriksa apakah masalah ini terjadi dalam proyek Anda sendiri Android, dan telah melihat bagaimana untuk mengumpulkan informasi lebih lanjut tentang masalah kinerja apa pun yang terjadi dalam aplikasi Anda sendiri. Semakin banyak informasi yang Anda miliki, semakin baik kesempatan Anda memiliki melacak penyebab masalah dan memperbaikinya.

Android SDK memiliki banyak alat-alat lain yang dapat membantu Anda mendiagnosis dan mengatasi masalah kinerja. Jika Anda ingin mempelajari lebih lanjut, maka halaman dokumentasi Android resmi di Traceview dan dmtracedump dan alokasi Tracker berisi informasi lebih lanjut.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.