Seri Pengoptimalan Kinerja iOS 05｜Praktik efektif untuk pengoptimalan startup iOS

Pengoptimalan startup adalah topik yang dapat dengan mudah diubah menjadi “kumpulan potongan-potongan”.

Orang biasanya mengingat banyak pengalaman:

• Lakukan lebih sedikit inisialisasi
• Pemuatan lambat
• Jadikan layar pertama sederhana
• Jangan membuat terlalu banyak permintaan saat startup

Tentu saja, saran-saran ini semuanya benar, namun jika penilaian intinya tidak dipahami, sering kali kesimpulannya menjadi “Sepertinya kita telah mengubah banyak hal, namun startup masih belum jauh lebih cepat.”

Kunci sebenarnya dari pengoptimalan startup adalah pertanyaan yang sangat sederhana:

Tugas mana yang benar-benar termasuk dalam jalur kritis yang harus diselesaikan sebelum pengguna melihat layar pertama, dan tugas mana yang mudah dimasukkan ke dalam fase permulaan karena kemudahannya?

1. Akar penyebab lambatnya startup biasanya karena jalur kritisnya semakin gemuk.

Banyak proyek yang tidak lambat untuk dimulai pada awalnya. Perlambatan sebenarnya biasanya terjadi karena seiring dengan meningkatnya fungsionalitas, semakin banyak logika yang dimasukkan ke dalam “lakukan segera setelah aplikasi dimulai” secara default:

• Inisialisasi konfigurasi
• Inisialisasi titik terkubur
• Persiapan lingkungan jaringan
• Pemulihan status pengguna
• Permintaan halaman beranda
• Pembacaan cache lokal
• Berbagai pendaftaran SDK

Semuanya tampak masuk akal dengan sendirinya, namun masalahnya adalah ketika semuanya digabungkan ke dalam fase startup, jalur kritisnya menjadi semakin berat.

Jadi masalah nyata yang paling umum dalam optimasi startup adalah: **Pekerjaan yang seharusnya tidak diperas pada saat ini telah lama menumpuk pada saat ini. **

2. Pertama-tama bedakan antara cold start, hot start, dan “waktu tersedia” yang benar-benar dirasakan pengguna.

Jika lapisan ini tidak dibedakan dengan jelas, optimasi selanjutnya akan mudah menjadi bias.

Karena “startup lambat” yang disebutkan oleh pengguna mungkin merujuk pada hal yang berbeda:

• Tidak ada layar dalam waktu lama setelah mengklik ikon
• Halaman beranda sudah keluar, namun belum dapat dioperasikan.
• Bingkai beranda keluar lebih dulu, dan butuh waktu lama untuk menyelesaikan kontennya.

Ini sebenarnya berhubungan dengan tahapan kelambatan yang berbeda.

Dari sudut pandang teknik, setidaknya kita harus membedakan:

• Cold start: proses dari awal
• Awal yang hangat: proses telah dilanjutkan dalam memori
• Momen ketika pengguna benar-benar tersedia: titik waktu ketika pengguna dapat melihat dan mulai berinteraksi

Untuk memulai pengoptimalan, Anda perlu tahu persis di mana Anda kehilangan waktu.

3. Langkah pertama yang paling bermanfaat adalah melapisi pekerjaan pada fase startup.

Saya biasanya membagi pekerjaan di fase startup menjadi tiga kategori:

1. Harus diselesaikan sebelum layar pertama

Misalnya:

• Kerangka antarmuka paling dasar
• Inisialisasi ketergantungan inti
• Status pengguna kunci yang harus diketahui segera setelah startup

2. Selesai sesegera mungkin setelah layar pertama muncul

Misalnya:

• Pengambilan data sekunder
• Beberapa penyegaran konfigurasi
• Konten tambahan UI yang tidak penting

3. Bisa tertunda atau dilatarbelakangi

Misalnya:

• Persiapan titik pemakaman tertentu
• Tidak mempengaruhi pembersihan cache pada halaman saat ini
• Pemanasan sumber daya halaman sekunder

Langkah ini lebih berharga daripada trik satu poin apa pun karena ini mengarah langsung pada pemahaman: Ternyata banyak kelambatan yang terjadi karena “kita tidak seharusnya melakukannya sekarang”.

4. Alasan mengapa banyak optimasi startup tidak memberikan manfaat adalah karena mereka hanya menulis kode lokal lebih cepat tetapi tidak mengubah jalur kritis.

Ini adalah kesalahpahaman yang sangat umum.

Misalnya, mengoptimalkan periode inisialisasi tertentu dari 40 md hingga 10 md terdengar bagus. Namun jika inisialisasi ini tidak muncul pada jalur kritis, maka optimasi yang paling efektif mungkin adalah “jangan lakukan di sini sama sekali”.

Jadi untuk menilai apakah optimasi startup layak dilakukan, yang paling sering saya lihat adalah:

• Apakah ini bekerja pada jalur kritis?
• Apakah bisa dikeluarkan dari jalur kritis?
• Apakah ini sesuatu yang saat ini harus diandalkan oleh pengguna?

Ini lebih penting daripada sekedar menonton fungsinya yang membutuhkan waktu.

5. Pemuatan konten halaman beranda sering kali memperlambat pengalaman startup

Banyak aplikasi yang tampaknya dimulai dengan lambat, bukan karena prosesnya sangat lambat, namun karena konten yang tersedia di layar pertama muncul terlambat.

Misalnya:

• Kerangka beranda telah dirender
• Tapi Anda harus menunggu beberapa permintaan kembali sebelum seperti “benar-benar tersedia”
• Beberapa modul menunggu satu sama lain
• Cache lokal tidak dimuat terlebih dahulu

Kelambatan yang dialami pengguna saat ini sebenarnya lebih mirip dengan “masalah strategi konten layar pertama” dan bukan sekadar masalah teknis startup.

Oleh karena itu, pengoptimalan startup sering kali terikat pada strategi layar pertama:

• Modul mana yang harus muncul secara bersamaan
• Modul mana yang dapat digunakan sebagai layar kerangka?
• Konten manakah yang dapat menampilkan hasil cache terlebih dahulu?

Banyak yang disebut startup lambat sebenarnya disebabkan oleh pengaturan konten yang tidak masuk akal di layar pertama.

6. Penilaian yang mendekati pertarungan sebenarnya: yang saat ini lambat adalah “inisialisasi” atau “perakitan layar pertama”

Keduanya sering kali bercampur aduk.

Inisialisasi lambat

Pertanyaannya lebih bias:

-SDK

• Layanan global
• Pembacaan konfigurasi
• Injeksi ketergantungan

Perakitan layar pertama lambat

Pertanyaannya lebih bias:

• Modul halaman beranda terlalu berat
• Melakukan terlalu banyak pekerjaan segera setelah halaman muncul
• Rantai ketergantungan data layar pertama terlalu panjang

Pengoptimalan dalam dua arah ini sangat berbeda. Yang pertama memerlukan pembongkaran inisialisasi dan penundaan eksekusi, sedangkan yang kedua memerlukan pemeriksaan ulang struktur halaman dan strategi konten.

7. Kesimpulan: Premis untuk memulai optimasi agar benar-benar menguntungkan adalah dengan terlebih dahulu menarik jalur kritis.

Singkatnya, saya akan mengatakan:

Optimasi startup sangat menguntungkan. Di permukaan, nampaknya ada banyak keterampilan. Bahkan, lebih dekat untuk membedakan terlebih dahulu: tugas mana yang termasuk dalam jalur kritis yang harus diselesaikan sebelum layar pertama, dan mana yang hanya beban yang sudah lama dimasukkan ke dalam fase startup.

Ketika jalur kritis tidak jelas, optimasi dapat dengan mudah berubah menjadi ketekunan parsial. Setelah jalur kritis jelas, banyak arah optimasi akan menjadi sangat jelas.