Seri Pengoptimalan Kinerja iOS 02|Titik awal pemecahan masalah kinerja iOS: kelambatan, pengaktifan lambat, memori tinggi, dan baterai tinggi
Menemukan jenis masalah terlebih dahulu, lalu memutuskan alat dan jalur analisis lebih efektif daripada memulai pemecahan masalah secara menyeluruh.
Ketika banyak tim menyebutkan pemecahan masalah kinerja, reaksi pertama mereka adalah “membuka Instrumen”. Hal ini memang benar, namun jika Anda tidak membedakan jenis masalahnya terlebih dahulu, Anda dapat dengan mudah terjerumus ke dalam keadaan berikut:
- Aku melihat banyak gambar
- Saya juga mencatat banyak indikator
- Tapi masih belum tahu di mana letak masalah utamanya
Jadi langkah pertama yang saya tekankan adalah selalu klasifikasi.
Karena jenis masalah kinerja yang berbeda, pintu masuk pemecahan masalah juga sangat berbeda. Jika Anda salah arah pada awalnya, semakin banyak alat yang Anda miliki nantinya, semakin mudah Anda kewalahan dengan informasi.
1. Pertama tanyakan dengan jelas: Apa sebenarnya yang dikeluhkan pengguna?
Langkah ini terdengar mendasar, namun di situlah banyak pemecahan masalah yang tersesat.
Anda harus terlebih dahulu mencoba menerjemahkan pertanyaan ke dalam kata-kata yang lebih spesifik, daripada kata-kata umum “Aplikasi agak lambat”.
Misalnya:
- Apakah lambat untuk memulai dingin atau lambat untuk memulai panas?
- Apakah halaman tertentu dibuka dengan lambat, atau seluruh aplikasi lambat?
- Apakah gulirnya macet, atau responsnya lambat setelah diklik?
- Apakah semakin macet setelah digunakan dalam waktu lama, atau langsung macet setelah dinyalakan?
- Apakah demam parah atau konsumsi daya tidak normal?
Begitu permasalahan dibuat spesifik, ruang lingkup analisis akan sangat berkurang.
2. Startup yang lambat, lagging, memori tinggi, dan baterai tinggi pada awalnya merupakan empat jalur pemecahan masalah yang berbeda.
Meskipun semuanya disebut “masalah kinerja”, dalam hal pemecahan masalah, masalah tersebut harus diperlakukan sebagai empat jenis masalah yang berbeda.
1. Startup lambat
Anda harus lebih memperhatikan:
- Apakah start dingin dan start panas lambat?
- Apa yang dilakukan thread utama selama fase startup
- Apakah terlalu banyak inisialisasi yang dilakukan sebelum merender halaman beranda?
- Apakah tugas-tugas non-kritis telah ditempatkan pada jalur kritis?
2. Bingkai tersendat/jatuh
Anda harus lebih memperhatikan:
- Apa yang dilakukan thread utama pada saat frame dijatuhkan
- Apakah tata letak, gambar, decoding, pemrosesan data, atau terlalu banyak pembaruan status?
- Apakah hanya muncul di halaman tertentu atau daftar tertentu
3. Memori tinggi
Anda harus lebih memperhatikan:
- Apakah ini puncak yang tinggi, ataukah itu merupakan titik tertinggi jangka panjang yang tidak akan turun kembali? -Apakah gambar, cache, kebocoran objek, atau objek berukuran besar disimpan terlalu lama?
- Apakah masalah terjadi setelah jalur fungsi tertentu
4. Baterai/panas tinggi
Anda harus lebih memperhatikan:
- Apakah ada terlalu banyak tugas latar belakang?
- Apakah polling, positioning, dan permintaan jaringan terlalu sering
- Apakah CPU terus digunakan -Apakah beberapa halaman memiliki penyegaran yang tidak valid atau tugas aktif jangka panjang
Berbagai jenis permasalahan harus didekati dari arah yang berbeda. Menggabungkannya hanya akan menghasilkan banyak informasi pada saat yang sama, tetapi tidak ada kesimpulan yang nyata.
3. Jika masalah tidak dapat direproduksi secara stabil, jangan terburu-buru menggali lebih dalam.
Ini adalah langkah yang cenderung dilewati oleh banyak tim.
Jika masalah masih dalam keadaan ini:
- “Terkadang bisa lambat”
- “Kadang-kadang macet”
- “Teman sekelas bilang ponselnya panas”
Hal terpenting saat ini adalah membuat kondisi perulangan sespesifik mungkin:
- perangkat yang mana
- Versi sistem yang mana
- Jalur operasi yang mana
- Start dingin atau start hangat
- Wi-Fi masih lemah
- Login atau mode tamu
Karena ketakutan terbesar dalam pemecahan masalah kinerja adalah kaburnya batasan masalah. Tanpa jalur reproduksi yang stabil, semua analisis selanjutnya akan mudah melayang.
4. Saya lebih suka mempersempit ruang lingkupnya terlebih dahulu daripada mengejar penjelasan yang lengkap.
Situasi yang umum adalah ketika melakukan pemecahan masalah kinerja, Anda ingin “menjelaskan keseluruhan masalah secara menyeluruh” dari awal. Namun dalam pekerjaan nyata, cara yang lebih efisien biasanya dibagi menjadi dua langkah:
Langkah pertama: Persempit cakupannya
Pertama-tama mari kita cari tahu di mana letak masalahnya:
- mulai tautan
- halaman tertentu
- daftar
- adegan gambar tertentu
- tugas latar belakang
Langkah Kedua: Penggalian Dalam yang Ditargetkan
Setelah mempersempit cakupan, gunakan alat dan data yang lebih spesifik untuk mengidentifikasi hambatan.
Nilai dari barisan ini adalah: Pertama-tama buatlah “peta masalah” daripada mencari jawaban secara membabi buta dalam indikator-indikator yang masif.
5. Penilaian yang sangat praktis: Apakah ini “masalah jalur kritis” atau “masalah akumulasi jangka panjang”
Kedua jenis ini sering digabungkan, namun logika pemecahan masalahnya berbeda.
Masalah jalur kritis
Misalnya:
- Lambat mulai dari dingin
- Halaman terbuka perlahan
- Respon lambat setelah diklik
Masalah jenis ini lebih seperti “terlalu banyak pekerjaan yang dilakukan pada saat tertentu”, dan yang perlu dicari adalah hambatan pada saat kritis.
Masalah akumulasi jangka panjang
Misalnya:
- Semakin lama semakin mentok setelah digunakan.
- Memori semakin tinggi
- Baterai terus tinggi
Jenis masalah ini lebih seperti “strategi operasi sistem jangka panjang tidak sehat”. Yang perlu diperhatikan adalah masalah biaya kumulatif dan siklus hidup.
Pembedaan ini sangat praktis, karena akan menentukan secara langsung apakah akan fokus pada proses sesaat atau melihat tren dalam jangka waktu tertentu.
6. Kesalahpahaman umum: menarik kesimpulan sebelum mengklasifikasikan jenis
Sangat mudah untuk membuat penilaian prematur berikut dalam pemecahan masalah kinerja:
- “Ini pasti masalah gambar”
- “Ini seharusnya kesalahan SwiftUI”
- “Ini sepertinya kebocoran memori”
Tebakan ini terkadang benar, tetapi jika Anda menarik kesimpulan terlalu dini, analisis selanjutnya akan mudah berkisar pada satu hipotesis saja.
Jadi saya lebih suka menjawab dulu:
- Masalah apa ini?
- Di jalur manakah hal itu terjadi?
- Apa saja syaratnya agar bisa kambuh kembali?
- Apakah bersifat sporadis atau stabil?
Lebih penting mengklasifikasikan masalah dengan benar terlebih dahulu daripada menebak alasannya terlebih dahulu.
7. Urutan awal yang mendekati pertarungan sebenarnya
Jika seseorang melontarkan pertanyaan kinerja kepada saya hari ini, saya biasanya akan memulai dengan urutan ini:
- Menanyakan secara jelas tentang fenomena yang dirasakan pengguna.
- Tentukan apakah itu startup, lagging, memori atau baterai.
- Konfirmasikan apakah dapat direproduksi secara stabil.
- Konfirmasikan apakah masalahnya terkonsentrasi pada halaman atau jalur tertentu.
- Putuskan alat apa yang akan digunakan selanjutnya.
Urutan ini terlihat sangat sederhana, namun dapat secara signifikan mengurangi situasi “alat banyak terbuka, tetapi arahnya masih tidak jelas”.
8. Kesimpulan: Bagilah masalahnya terlebih dahulu baru gunakan alat, efisiensinya akan jauh lebih tinggi
Singkatnya, saya akan mengatakan:
Langkah pertama yang paling penting dalam memecahkan masalah kinerja iOS adalah dengan terlebih dahulu membagi masalah menjadi beberapa jenis seperti “startup lambat, lag, memori tinggi, dan baterai tinggi”, lalu tentukan jalur analisisnya.
Karena jika masalah kinerja tidak diklasifikasi terlebih dahulu, berapapun banyaknya informasi yang muncul kemudian, akan sulit untuk mendapatkan jawabannya.
What to read next
Want more posts about iOS Performance Optimization?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #iOS?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home