Seri Pengoptimalan Kinerja iOS 07｜Akar Penyebab Proses Konvergensi Pemecahan Masalah Kinerja iOS

Saat melakukan pemecahan masalah kinerja iOS, hal yang paling menyebalkan adalah pemandangannya seringkali berantakan sejak awal.

Produk mengatakan beranda macet, pengujian mengatakan ada penurunan bingkai dalam daftar, pengembangan mengira itu mungkin gambar, dan backend mencurigai antarmukanya lambat. Semua orang berbicara seperti sebuah pertanyaan, tetapi ketika Anda mulai melihatnya, Anda sering kali menemukan bahwa mereka tidak menggambarkan hal yang sama sama sekali.

Setelah melakukan pekerjaan semacam ini beberapa kali, perasaan terbesar saya adalah: **Pemecahan masalah kinerja dimulai dengan masalah konvergensi, diikuti dengan analisis data. **

Jika masalahnya tidak diselesaikan terlebih dahulu, semakin banyak alat yang Anda buka, semakin mudah Anda tersesat. Karena setiap indikator yang Anda lihat sepertinya memiliki informasi, namun setiap informasi tidak cukup untuk membentuk suatu kesimpulan.

Artikel berikut tidak membahas tentang “cara memecahkan masalah secara teoritis”, tetapi menulis sesuai dengan ritme yang akan terjadi dalam proyek nyata: Bagaimana masalah hilangnya bingkai di aliran informasi beranda berubah dari “merasa sedikit macet” selangkah demi selangkah hingga ke titik yang dapat diperbaiki secara manual?

Paku adegannya terlebih dahulu, jika tidak semua analisis selanjutnya akan hilang.

Gambaran awal masalah itu sangat biasa:

• Beranda tidak meluncur dengan lancar
• Beberapa model lebih jelas terlihat
• Versi terbaru semakin terasa stuck.

Deskripsi ini terdengar seperti informasi, namun kenyataannya hampir tidak mungkin untuk menggunakannya secara langsung untuk pemecahan masalah. Karena tercampur dengan setidaknya tiga lapisan benda:

*Rentang halaman tidak jelas *Jenis fenomenanya tidak jelas *Syarat untuk kemunculan kembali tidak jelas

Deskripsi yang benar-benar mulai berfungsi akhirnya diringkas menjadi ini:

iPhone 13 Pro, iOS 18, login akun A, mulai dingin untuk masuk ke alur rekomendasi beranda, beralih ke tab “Ikuti” setelah layar pertama dimuat, lalu beralih kembali ke alur rekomendasi, geser ke atas 4 layar berturut-turut, dan lanjutkan menjatuhkan bingkai mulai dari layar ke-3. Masalahnya terutama terjadi pada susunan campuran grafis dan teks serta susunan campuran kartu video.

Pentingnya bagian ini bukan karena ditulis seperti sebuah kasus uji, namun menghilangkan banyak ambiguitas sekaligus:

*Ini adalah kartu alur yang direkomendasikan di beranda *Lebih jelas saat Anda masuk untuk kedua kalinya

• sedang menggulir dan menjatuhkan bingkai *Area di mana gambar dan teks tercampur lebih jelas.

Permulaan penyelidikan yang sebenarnya sering kali dimulai dengan “menetapkan ruang lingkup” ini. Tanpa langkah ini, semua “analisis” selanjutnya mungkin hanya mengejar imajinasi sendiri.

Jangan terburu-buru melihat alatnya terlebih dahulu, tentukan dulu apakah ini adalah freeze sesekali atau frame rate rendah terus menerus.

Empat kata “tidak meluncur mulus” sebenarnya bisa berhubungan dengan masalah yang sangat berbeda.

Hal pertama yang saya lakukan saat itu adalah merekam layar dan menggesernya beberapa kali untuk mengkarakterisasi fenomena tersebut.

Pada akhirnya, ini adalah frame rate rendah berkelanjutan yang sangat khas:

• Setelah memasuki area konten tertentu, beberapa layar berturut-turut tidak akan berjalan mulus. *berat selama seluruh fase penggulungan
• Perasaan subjektif pengguna adalah “bagian ini tidak dapat digeser”

Perbedaan ini sangat penting.

Karena kelambatan sesekali biasanya terlihat seperti:

• Decoding gambar tertentu tiba-tiba muncul di thread utama
• Waktu inisialisasi objek besar salah
• Tata letak tertentu terkadang menjadi berat

Dan frame rendah berkelanjutan terlihat lebih seperti:

• Melakukan pekerjaan berulang setiap frame
• Struktur selnya sendiri terlalu berat
• Hasil asinkron terus diisi ulang selama pengguliran
• Rentang penyegaran status daftar terlalu besar

Jika kedua jenis permasalahan ini tidak dipisahkan sejak awal, data apa pun nantinya akan mudah disalahartikan.

Jalur reproduksi harus ditulis, jika tidak, kata “diubah” tidak akan ada artinya.

Salah satu gejala paling umum dari masalah kinerja adalah “Baru saja terlihat jelas, tapi sekarang sudah hilang.”

Jadi dalam pemecahan masalah itu, langkah pertama yang saya lakukan adalah bodoh, namun sangat berharga: menuliskan jalur perulangan ke dalam langkah-langkah yang tetap.

Yang diselesaikan saat itu adalah:

1. Matikan aplikasi dan mulai lagi
2. Masuk ke akun A
3. Masuk ke alur rekomendasi beranda dan tunggu hingga layar pertama benar-benar stabil.
4. Beralih ke tab “Ikuti”.
5. Beralih kembali ke alur rekomendasi
6. Geser ke atas 4 layar secara berurutan
7. Amati performa frame rate dan okupansi thread utama mulai dari layar ketiga

Ingat juga lingkungan:

*Model peralatan

• Versi sistem *Kondisi jaringan
• Tingkat data
• Apakah akan mengaktifkan sakelar debugging

Pentingnya hal ini tidak hanya untuk memfasilitasi orang lain untuk mereproduksi, tetapi yang lebih penting, untuk memfasilitasi verifikasi selanjutnya.

Karena kalimat yang paling tidak berharga dalam optimasi kinerja adalah:

Saya merasa lebih baik dari sebelumnya.

Tidak ada jalan yang pasti, dan kata “shun” tidak memiliki nilai analitis. Mungkin saja karena datanya berbeda, jaringannya berbeda, halaman tidak meluncur ke paragraf yang sama, atau bahkan jari tidak meluncur begitu cepat kali ini.

Penilaian putaran pertama tidak menemukan akar permasalahannya, namun hanya menentukan pada kaitan mana permasalahannya.

Ketika saya pertama kali mulai menangani masalah seperti ini, saya ingin bertanya:

• Baris kode mana yang lambat?
• Fungsi mana yang paling memakan waktu?
• Perpustakaan mana yang bermasalah?

Namun dalam penyelidikan sebenarnya, hal ini biasanya terlalu dini untuk ditanyakan.

Apa yang saya lakukan pertama kali saat itu adalah segmentasi tautan secara kasar:

Apakah ini masalah data atau masalah rendering?

Langkah ini penting, karena beranda yang lambat dapat dengan mudah membuat orang secara naluriah meragukan antarmukanya.

Saya pertama kali melakukan verifikasi langsung: Usahakan untuk memperbaiki hasil jaringan sebanyak mungkin, sehingga data saat memasukkan alur rekomendasi untuk kedua kalinya berasal dari hasil yang ada, bukan perubahan jaringan.

Hasilnya jelas: Data sudah kembali, dan penggulirannya masih berat, dan stabil.

Langkah ini pada dasarnya dapat menghilangkan “scrolling macet karena antarmuka yang lambat” dari masalah utama.

Antarmuka yang lambat akan memengaruhi waktu layar pertama, tetapi tidak menjelaskan “setelah masuk untuk kedua kalinya, konten tertentu mulai memiliki frame rendah terus menerus”.

Apakah thread utama yang sibuk, atau pekerjaan latar belakang terus kembali ke thread utama?

Hal berikutnya yang harus dilihat adalah apa yang dilakukan thread utama ketika kartu macet.

Tujuan dari langkah ini juga untuk menentukan terlebih dahulu bentuk permasalahannya:

• Thread utama terus sibuk
• Atau panggilan balik latar belakang terlalu padat, dan thread utama terputus satu demi satu.

Hal terakhir yang saya lihat lebih mirip yang pertama: Thread utama tidak selalu fokus pada fase scrolling.

Hal ini menunjukkan bahwa arahnya mulai jelas:

• Fokusnya bukan pada jaringan
• Fokusnya bukan pada satu tugas besar
• Fokusnya lebih seperti tampilan daftar link itu sendiri yang terlalu berat

Apakah ini hanya satu pengecualian atau kelebihan sistem?

Ini adalah penilaian yang saya hargai setiap saat.

Jika hanya satu fungsi yang sesekali habis selama 200 ms, mudah untuk ditangani, cukup tangkap saja. Namun hal itu tidak terjadi pada saat itu.

Hal yang benar-benar menyusahkan pada saat itu adalah bahwa tidak ada gunanya menjadi “pembunuh yang nyata dalam sekejap”, tetapi banyak pengeluaran kecil yang tidak dilebih-lebihkan ditumpuk bersama-sama, dan semuanya jatuh pada jalur kritis yang bergulir.

Masalah seperti ini paling menyebalkan, karena tidak memiliki tumpukan yang jelas seperti crash. Ini lebih seperti sistem memberi tahu Anda bahwa setiap keputusan kecil yang “ditulis seperti ini” di masa lalu kini dibebankan bersama-sama.

Saat ini, Instrumen hanya layak dibuka dan harus dilakukan dengan penuh kecurigaan.

Saya tidak pernah benar-benar menyukai pendekatan “buka semua alat terlebih dahulu, lalu bicara” dalam pemecahan masalah. Sangat mudah untuk menggunakan alat sebagai pengganti pemikiran.

Sebelum masuk ke Instrumen saat itu, sebenarnya ada beberapa keraguan di benak saya:

Kecurigaan 1: Tautan gambar menempatkan karya yang tidak seharusnya ditempatkan dalam periode bergulir ke dalam periode bergulir.

Ini adalah tersangka paling umum dalam skenario arus informasi.

Terutama:

*Ukuran gambar sampul tidak seragam

• Susunan campuran grafis, teks dan kartu video
• Irama pengisian ulang gambar tidak stabil
• Sebelum ditampilkan, pemrosesan seperti sudut membulat, bayangan, dan penskalaan juga dilakukan.

Jika semua pekerjaan ini benar-benar terjadi selama pengguliran, kecepatan bingkai akan sulit distabilkan.

Kecurigaan 2: Presentasi sel terlambat disiapkan

Banyak daftar yang tampak “jelas secara logis” pada awalnya, tetapi ketika Anda benar-benar menelusuri peralatan tersebut, masalah lama akan terungkap:

Banyak pekerjaan persiapan tampilan yang dilakukan saat sel akan ditampilkan.

Misalnya:

• Perakitan teks kaya
• Pemotongan copywriting
• Pemformatan waktu *Perhitungan ketinggian
• Penilaian status UI
• Persiapan benda yang dikubur

Setiap item tidak terlalu besar jika berdiri sendiri, tetapi begitu semuanya dimasukkan ke dalam jalur kritis yang bergulir, item tersebut akan berubah dari “dapat diterima” menjadi “seluruh daftarnya berat”.

Kecurigaan 3: Rentang penyegaran status terlalu besar

Situasi ini sangat umum terjadi pada arsitektur reaktif.

Di permukaan, ini hanyalah perubahan status kartu, namun yang sebenarnya dipicu adalah:

• Pengikatan ulang tingkat bagian
• Terlalu banyak perbedaan lokal
• Gabungan pelaporan paparan dan penyegaran UI
• Callback yang dimuat sebelumnya sering kali kembali ke thread utama

Jenis masalah ini adalah yang paling menjengkelkan, karena belum tentu menyebabkan puncak yang sangat tinggi pada fungsi tertentu, namun pengalaman secara keseluruhan akan selalu buruk.

Yang benar-benar mempersempit arahnya adalah beberapa putaran eksperimen murahan.

Saat itu kami mempersempit masalahnya menjadi beberapa putaran eksperimen yang sangat sederhana.

Eksperimen 1: Ganti semua gambar dengan gambar placeholder

Eksperimen ini sangat kasar, tetapi sangat berguna.

Setelah gambar diganti, pengguliran jelas kembali. Langkah ini tidak secara langsung menjelaskan bahwa akar permasalahannya adalah “terlalu banyak gambar”, namun cukup menunjukkan bahwa link gambar harus menjadi salah satu arahan utama.

Jika Anda terus bertanya saat ini, jawabannya bukan lagi “ya” yang umum, tetapi lebih spesifik:

• Apakah decoding jatuh pada thread utama
• Apakah strategi ukuran tidak konsisten?
• Apakah pengisian ulang gambar menyebabkan tata letak ulang?
• Apakah ada terlalu banyak proses tambahan yang dilakukan sebelum ditampilkan?

Eksperimen 2: Proses awal bagian teks dinamis sel

Dengan perubahan ini, pengguliran juga meningkat secara signifikan.

Hal ini menunjukkan bahwa arah sebaliknya juga benar: Memang sudah terlambat untuk menyiapkan daftarnya sebelum disajikan, dan ada lebih dari satu atau dua tugas tersebut.

Dengan kata lain, masalahnya adalah link gambar dan link presentasi diduplikasi bersama.

Eksperimen 3: Nonaktifkan sementara tindakan tepi ini seperti eksposur, pramuat, dan pemutaran otomatis

Setelah putaran eksperimen ini, kecepatan bingkai terus stabil.

Pada titik ini masalahnya pada dasarnya sudah jelas: Ini adalah aliran informasi beranda yang membawa terlalu banyak pekerjaan “lakukan saja” selama tahap pengguliran.

Tugas-tugas ini biasanya terlihat masuk akal:

• Gambar perlu diisi ulang
• Paparan harus dilaporkan
• Pramuat perlu dilakukan
• Kartu video perlu dihangatkan

Namun ketika hal-hal tersebut terjadi bersamaan di jalur kritis yang sedang berjalan, hal-hal tersebut akan menurunkan seluruh daftar.

Akar permasalahan sebenarnya pada akhirnya adalah serangkaian keputusan yang buruk

Ketika akhirnya mendarat, masalah sebenarnya mungkin adalah kombinasi pukulan berikut:

• Strategi ukuran gambar tidak seragam, sehingga menimbulkan biaya pemrosesan sebelum ditampilkan
• Beberapa gambar terlambat diterjemahkan
• Pekerjaan persiapan tampilan sel dilakukan di tempat di thread utama
• Eksposur dan panggilan balik pramuat terlalu padat selama periode pengguliran
• Daftar perubahan keadaan lokal memicu rentang penyegaran yang lebih besar dari yang diharapkan

Seperti inilah sebenarnya banyak masalah kinerja.

Ini bukanlah akhir dari “baris 357 ditemukan”, Namun pada akhirnya, Anda akan menemukan bahwa desain beberapa lapisan tidak cukup terkendali, dan akhirnya akan diselesaikan bersama pada tahap penggulungan.

Oleh karena itu, saya semakin tidak menyukai argumen bahwa “harus ada fungsi kunci untuk masalah kinerja”. Tentu saja hal ini terjadi dalam proyek nyata, tetapi lebih sering daripada tidak, ini adalah “serangkaian bentuk buruk yang telah menumpuk dalam waktu lama”.

Fase verifikasi paling takut dengan perasaan subjektif. Anda harus kembali ke jalur yang sama untuk membandingkan.

Setelah modifikasi, masalah tidak diselesaikan secara langsung, tetapi jalur pengulangan asli diambil kembali.

Perangkat yang sama, akun yang sama, metode peralihan yang sama, geser ke area konten yang sama, lalu lihat:

• Apakah frame drop masih terjadi secara stabil?
• Apakah thread utama masih fokus pada periode waktu yang sama?
• Apakah perilaku pengisian ulang dan tepi gambar masih bersaing dengan pengguliran untuk bersaing dengan thread utama?

Pada langkah ini, saya juga melihat efek sampingnya:

*Setelah link gambar tersambung, apakah ada peningkatan memori yang signifikan?

• Jika Anda melakukan terlalu banyak pra-pemrosesan, apakah layar pertama akan menjadi lebih lambat?
• Pelaporan paparan tertunda. Apakah statistik akan terpengaruh?

Kesalahan yang sering dilakukan dalam pengoptimalan kinerja: Mereka hanya fokus pada “apakah suatu indikator terlihat bagus”, namun tidak melihat apakah indikator tersebut telah menggantikan masalah lainnya.

Namun dalam pekerjaan nyata, pengoptimalan selalu tentang pertukaran pengalaman secara keseluruhan. Pertukaran yang dapat diterima disebut optimasi, pertukaran masalah lain tidak disebut optimasi.

Jenis artikel ini kemungkinan besar ditulis sebagai omong kosong, namun juga merupakan tempat paling realistis untuk pemecahan masalah kinerja.

Banyak artikel ringkasan yang akhirnya akan ditulis:

• Definisikan masalahnya terlebih dahulu
• Untuk menetapkan hipotesis
• Untuk memverifikasi hasilnya

Kata-kata ini memang benar, tetapi bisa dengan mudah berubah menjadi omong kosong belaka.

Perbedaan dalam pengalaman nyata bukanlah apakah Anda dapat mengucapkan kata-kata ini, tetapi apakah Anda pernah mengalami momen-momen berikut:

*Awalnya semua orang bilang sepertinya masalahnya sama, tapi nyatanya masalahnya sama sekali tidak sama.

• Arah yang sekilas terlihat paling mirip dengan akar permasalahan hanyalah petunjuk palsu pada akhirnya.
• Setiap indikator pada alat tampak tidak normal, tetapi hanya ada satu jalur utama yang sebenarnya
• Jawaban akhirnya adalah serangkaian biaya tambahan kecil yang bertambah seiring waktu

Setelah Anda melakukan hal-hal ini beberapa kali, secara alami Anda akan memahami satu hal:

**Nilai sebenarnya dari pemecahan masalah kinerja adalah “dapatkah saya mengubah adegan kacau menjadi tautan yang bisa diterapkan?” **Hal ini tidak bisa dilakukan, semakin banyak alat maka akan semakin berantakan. Dengan melakukan ini, Anda bisa semakin dekat dengan akar penyebab banyak masalah tanpa melalui semua grafik.

Saat saya melihat masalah kinerja saat ini, hal yang paling saya pedulikan adalah apakah kami dapat membuat tim menyetujui hal-hal berikut secepat mungkin:

Kami sekarang sedang menyelidiki masalah yang sama, dan kami sudah mengetahui kaitan mana yang paling sering menjadi penyebab masalah tersebut.

Selama hal ini dilakukan, perbaikan selanjutnya biasanya tidak terlalu membingungkan. Hal yang paling sulit adalah mengumpulkan masalah ke dalam bentuk yang bisa diatasi.