Seri Pengoptimalan Kinerja iOS 01｜Tujuan dan Cakupan Pengoptimalan Kinerja iOS

Ketika topik pengoptimalan kinerja disebutkan, reaksi pertama biasanya adalah:

• Gagap atau tidak
• Tidak ada bingkai yang jatuh
• Apakah cepat untuk memulainya?

Tentu saja, ini semua adalah masalah kinerja, tetapi jika Anda hanya memahami pengoptimalan kinerja sebagai “membuat laman lebih cepat”, perhatian Anda nantinya akan mudah teralihkan. Karena masalah kinerja dalam proyek nyata pada dasarnya adalah sekelompok masalah kualitas yang bercampur menjadi satu.

Pada produk yang sama, masalah kinerja mungkin muncul sebagai:

• Layar pertama terbuka perlahan
• Daftarnya tidak meluncur mulus
• Sesekali bingkai terjatuh di halaman detail
• Memori tidak turun kembali saat naik
• Konsumsi daya tidak normal
• Sangat lambat untuk masuk kembali ke halaman setelah beralih dari latar belakang ke latar depan.

Jadi pertanyaan pertama yang benar-benar perlu dijawab oleh pengoptimalan kinerja adalah:

Kelambatan seperti apa yang dimaksud dengan “lambat” yang sedang kita bicarakan sekarang?

1. Optimalisasi kinerja adalah mengoptimalkan kualitas lari secara keseluruhan.

Masalah kinerja iOS yang sebenarnya setidaknya dapat dibagi ke dalam kategori berikut:

• Waktu mulai
• Halaman macet dan bingkai turun
• Penggunaan memori dan daur ulang
• Tenaga dan panas
• Efisiensi penggunaan jaringan dan sumber daya

Tampaknya semua jenis masalah ini dapat diklasifikasikan sebagai “kinerja”, namun penyebab, metode pemecahan masalah, dan metode pengoptimalannya sangat berbeda.

Misalnya:

• Startup lambat, sering kali terkait dengan tautan inisialisasi dan jalur start dingin
• Keterlambatan daftar sering kali terkait dengan beban kerja thread utama, tata letak, dan decoding gambar.
• Memori tinggi mungkin terkait dengan strategi caching, siklus hidup objek, dan penyimpanan gambar
• Baterai tinggi sering kali disebabkan oleh seringnya polling, tugas di latar belakang, dan penyegaran yang tidak valid

Jika Anda tidak mengklasifikasikan masalahnya terlebih dahulu, kesibukan palsu akan mudah muncul di kemudian hari: Saya membuka banyak alat dan melihat banyak indikator, namun saya tidak pernah benar-benar mendekati inti masalahnya.

2. Performa yang dirasakan pengguna dan performa indeks sistem bukanlah hal yang sama, namun keduanya penting

Masalah kinerja secara kasar dapat dibagi menjadi dua perspektif:

1. Masalah kinerja yang dirasakan pengguna

Pengguna dapat langsung merasakannya, seperti:

• Halaman macet saat dibuka.
• Daftar bingkai geser yang jatuh
• Hasil pencarian keluar sangat lambat
• Saat aplikasi dibuka, layar menjadi kosong dalam waktu lama

Jenis masalah ini biasanya menjadi prioritas utama karena berdampak langsung pada pengalaman dan retensi.

2. Masalah kinerja indikator

Pengguna mungkin tidak dapat mendeskripsikannya dengan jelas, namun secara bertahap akan muncul sebagai:

• Demam
• Konsumsi daya
• Sering terbunuh di latar belakang
• Memori tetap pada tingkat tinggi untuk waktu yang lama

Masalah seperti ini belum tentu langsung berubah menjadi ulasan negatif, namun perlahan-lahan akan menjadi bumerang bagi kualitas keseluruhan produk.

Masalah bagi banyak tim adalah: Fokus saja pada yang pertama dan pikirkan “jangan jatuhkan frame”; atau hanya fokus pada indikator alat, lupa bahwa pengguna sebenarnya tidak peduli dengan angka tertentu, tetapi peduli apakah pada akhirnya akan macet, menghasilkan panas, dan menghabiskan daya.

3. Banyak yang disebut “optimasi kinerja” yang pada dasarnya merupakan masalah batas rekayasa.

Ini adalah poin yang paling diremehkan.

Banyak masalah kinerja yang akhirnya diselidiki, dan masalah sebenarnya terletak pada hilangnya kendali di tingkat teknik:

• Halaman ini mengambil terlalu banyak pekerjaan sehingga harus ditenggelamkan
• Terlalu banyak logika yang tidak perlu dimasukkan ke dalam fase inisialisasi
• Pemuatan gambar, caching, dan decoding tidak berlapis
• Batasan antara penggunaan kembali daftar dan pembaruan data menjadi kabur
• Data yang sama diproses beberapa kali

Artinya optimalisasi kinerja sering kali berupa “pembayaran utang struktural”.

Oleh karena itu, jika batasan tanggung jawab suatu proyek pada awalnya sangat membingungkan, masalah kinerja selanjutnya seringkali bukan merupakan masalah tersendiri, namun merupakan salah satu manifestasi dari masalah struktural.

4. Kesalahan penilaian paling umum dalam pengoptimalan kinerja: Mengaitkan semua kelambatan dengan “rendering” atau “perangkat”

Situasi yang umum terjadi adalah ketika Anda melihat sebuah kartu, hal pertama yang Anda pikirkan adalah:

• Apakah peralatannya terlalu tua?
• Apakah terlalu banyak animasi?
• Apakah karena SwiftUI sendiri kurang bagus?

Tentu saja hal ini mungkin terjadi, namun situasi yang lebih umum dalam proyek nyata adalah:

• Terlalu banyak pemrosesan data yang dilakukan pada thread utama
• Penguraian gambar saat menggulir daftar
• Terlalu banyak pembaruan tidak valid yang dipicu oleh satu perubahan status
• Banyak inisialisasi non-kritis dilakukan saat layar pertama dibuka

Dengan kata lain, masalahnya seringkali bukan pada “kerangka rendering”, tetapi pada “membiarkan thread utama mengambil terlalu banyak pekerjaan yang tidak proporsional dengan tindakan pengguna saat ini.”

Jadi optimasi kinerja harus dijawab terlebih dahulu:

• Di lapisan manakah kemacetan saat ini terjadi?
• Pekerjaan ini akan dilakukan saat ini
• Bukankah itu seharusnya terjadi di sini?

5. Pengoptimalan kinerja adalah serangkaian “kemampuan klasifikasi masalah”

Situasi yang umum terjadi adalah ketika Anda memikirkan pengoptimalan kinerja, Anda akan mencari:

• Kiat pengoptimalan startup
• Daftar tip pengoptimalan
• Tip cache gambar

Teknik ini tentu berguna, namun dapat dengan mudah berubah menjadi pengetikan buta jika masalahnya tidak dikategorikan terlebih dahulu.

Titik awal yang lebih praktis biasanya adalah:

1. Masalahnya adalah startup, lagging, memori, atau konsumsi daya.
2. Apakah masalah ini merupakan tipe persepsi pengguna atau tipe indikator?
3. Apakah terkonsentrasi pada halaman tertentu atau pada seluruh aplikasi?
4. Apakah berulang secara konsisten atau hanya muncul secara sporadis pada jalur tertentu saja?

Langkah ini sepertinya bukan sekedar “pamer keahlian”, tapi menentukan apakah penyelidikan selanjutnya akan ada arahnya.

6. Pengoptimalan kinerja sering kali kembali ke “tanggung jawab dan batasan”

Karena masalah kinerja pada dasarnya menunjukkan: Pada titik tertentu, sistem mengambil terlalu banyak pekerjaan yang tidak seharusnya dilakukan.

Misalnya:

• Inisialisasi berlebihan dilakukan saat halaman dibuka.
• Perhitungan decoding dan tata letak dilakukan secara bersamaan saat menggulir daftar
• Strategi caching tertentu menyebabkan memori terisi dalam waktu lama
• Perubahan keadaan tertentu menyebabkan tampilan multi-layer direkonstruksi berulang kali

Pertanyaan-pertanyaan ini akhirnya memaksa adanya jawaban ulang:

• Siapa yang harus melakukan pekerjaan ini?
• Kapan hal itu harus dilakukan?
• Apakah itu perlu dilakukan setiap saat?
• Apakah bisa ditunda, dipisah, atau di-cache?

Oleh karena itu, optimalisasi kinerja sering kali melibatkan “reorganisasi distribusi kerja sistem”.

7. Kesimpulan: Yang sebenarnya perlu dioptimalkan dalam optimalisasi kinerja adalah ketidakseimbangan antara pengalaman pengguna dan sumber daya sistem.

Singkatnya, saya akan mengatakan:

Yang benar-benar perlu dioptimalkan oleh pengoptimalan kinerja iOS adalah ketidaksesuaian antara beban kerja sistem dan persepsi pengguna di balik masalah tertentu seperti startup, lagging, memori, dan konsumsi daya.

Jadi langkah pertama adalah selalu membedakan jenis masalahnya:

• Dimana kelambatannya?
• Apa yang penting?
• Dimana dibelanjakan?
• Ini akan terjadi saat ini

Hanya jika masalah ini diklarifikasi terlebih dahulu, pengoptimalan selanjutnya tidak akan menjadi akumulasi pengalaman tanpa tujuan.