Seri Konkurensi Swift 01｜Alasan mengapa Swift memperkenalkan async/menunggu

Saat Anda melihat async/await untuk pertama kalinya, Anda akan memahaminya sebagai “versi penulisan panggilan balik yang ditingkatkan”.

Pemahaman ini hanya setengah benar.

Jika Anda hanya ingin menulis kode yang lebih pendek dan gaya yang lebih sinkron, maka bahasa lain telah melakukan hal serupa. Apa yang benar-benar ingin diselesaikan Swift adalah model asinkron lama menjadi semakin sulit untuk mendukung kompleksitas proyek iOS modern.

Di masa lalu, Anda mungkin hanya perlu memproses klik tombol untuk mengirim permintaan, namun sekarang halaman biasa mungkin melibatkan:

• Memuat banyak sumber daya secara paralel di layar pertama
• Batalkan tugas lama saat meninggalkan halaman
• Cache lokal dan permintaan jarak jauh bersaing untuk status yang sama
• Secara otomatis menyegarkan token setelah status login berakhir
• Pembaruan UI thread utama dan pemrosesan latar belakang terjadi diselingi

Ketika bisnis mencapai kompleksitas ini, masalah asynchronous bukan lagi sekedar masalah penulisan, namun masalah desain sistem. Arti penting dari async/await adalah ia memajukan jenis masalah ini dari “kebiasaan tingkat perpustakaan” menjadi “aturan tingkat bahasa”.

1. Masalah sebenarnya dengan model lama adalah aliran kontrol rusak

Semua orang suka menggunakan “callback hell” untuk menjelaskan masalah metode penulisan asinkron yang lama, tetapi jika Anda hanya berhenti pada “lekukan terlalu dalam”, Anda masih salah paham.

Masalah sebenarnya dengan panggilan balik adalah bahwa bisnis ** awalnya berupa sebuah baris, tetapi kodenya dipecah menjadi banyak fragmen terpisah. **

Misalnya, proses inisialisasi yang sangat umum:

1. Tarik informasi pengguna saat ini
2. Tentukan modul halaman beranda berdasarkan izin pengguna
3. Tarik kembali data beranda
4. Jika gagal, catat titik-titik yang tersembunyi
5. Terakhir kembali ke thread utama untuk mengupdate UI

Ini adalah tautan yang diurutkan dengan sangat jelas dalam pikiran saya. Namun pada era penyelesaiannya, link ini seringkali terpecah menjadi:

• penutupan permintaan
• Penutupan keputusan izin
• Beberapa lapisan penanganan kesalahan
• Saklar ulir utama
• Beberapa cabang pengembalian awal

Seiring bertambahnya panjang kode, menjadi sulit untuk dijelaskan secara sekilas:

• Apa proses utamanya?
• Cabang mana yang akan patah
• Siapa yang harus disalahkan bila suatu langkah gagal?
• Haruskah Anda melanjutkan setelah meninggalkan halaman?

Kesulitan sebenarnya dalam mempertahankan logika asynchronous adalah niat dan ekspresi tidak berhubungan.

2. Masalah terbesar dalam penyelesaian adalah meninggalkan terlalu banyak semantik kunci pada konvensi

menyelesaikannya bukanlah hal yang buruk. Banyak API yang mendasarinya masih sangat berguna saat ini, dan masih cocok dalam skenario tertentu yang memerlukan beberapa callback, keluaran streaming, dan menjembatani sistem lama.

Masalahnya adalah ketika suatu sistem sangat bergantung pada penyelesaian, sebagian besar semantik penting hanyalah “kebiasaan tim” dan bukan aturan bahasa.

Misalnya, hal-hal berikut ini sering dipahami secara default dalam model penyelesaian:

• Apakah panggilan balik ini akan dipanggil satu kali atau beberapa kali?
• Apakah keberhasilan dan kegagalan saling eksklusif?
• Di thread mana callback akan kembali?
• Apakah penelepon memiliki kemampuan untuk membatalkan
• Jika benda tersebut dilepaskan di tengah jalan, apakah hasil tetap harus diberikan?

Anda akan menemukan bahwa ini adalah isu inti dari sistem konkuren.

Ketika semantik ini dipelihara melalui dokumentasi, penamaan, dan pengalaman, semakin besar proyeknya, semakin mudah semantiknya menyimpang. Hal yang paling menyakitkan pada akhirnya biasanya adalah ketidakmampuan untuk berpikir secara stabil tentang bagaimana sebuah kode asinkron akan dijalankan.

3. Swift memperkenalkan async/await, yang pada dasarnya memperketat aturan kode asynchronous.

Nilai async/await bukan hanya tentang:

fetchUser { result in
  ...
}

Ganti dengan:

let user = try await fetchUser()

Lebih penting lagi, hal ini mengembalikan banyak hal yang semula tersebar di konvensi kembali ke tingkat bahasa.

Misalnya sekarang:

• Fungsi async memiliki titik balik yang jelas
• Kegagalan disebarkan melalui throw dan bukan melalui gaya panggilan balik hasil yang berbeda
• await secara eksplisit memberitahukan bahwa ini adalah titik jeda
• Rantai panggilan asinkron dapat dibaca tanpa berpindah di antara beberapa penutupan.

Arti penting dari hal ini bukanlah “terlihat bagus” tetapi “peraturannya lebih ketat”.

Ketakutan sebenarnya terhadap sistem yang kompleks adalah aturan yang longgar. Begitu aturannya dilonggarkan, kode tersebut menjadi semakin bergantung pada “orang ini kebetulan memahami konteksnya”.

4. Ini tidak hanya meningkatkan keterbacaan, tetapi juga kewajaran

Situasi yang umum adalah: Saya dapat memahami penyelesaiannya, mengapa saya harus mempelajari async/await?

Pertanyaannya bukanlah apakah Anda dapat memahaminya saat ini, namun:

• Apakah kamu masih bisa mengerti dengan cepat setelah tiga bulan?
• Ketika rekan kerja mengambil alih, dapatkah mereka menyimpulkan proses berdasarkan kode itu sendiri?
• Jika terjadi bug, apakah bisa berjalan dari pintu masuk ke pintu keluar?

Inilah perbedaan antara “keterbacaan” dan “kewajaran”.

Keterbacaannya adalah “Apakah kode ini enak dipandang hari ini?” Kewajarannya adalah “Dapatkah saya menilai berdasarkan kode ini: bagaimana kegagalan ditransmisikan, bagaimana pembatalan berlaku, dan pada tingkat mana status diubah.”

Misalnya, masalah berikut seringkali sangat sulit diatasi dalam model lama:

• Setelah pengguna meninggalkan halaman, apakah rantai permintaan ini masih ada?
• Jika langkah ketiga gagal, di manakah status halaman terakhir akan berhenti?
• Ketika dua hasil asinkron muncul secara bersamaan, siapa yang memenuhi syarat untuk menulis UI?

async/await tentu saja tidak akan secara otomatis menjawab pertanyaan-pertanyaan ini untuk tim, namun setidaknya memungkinkan pertanyaan-pertanyaan ini ditempatkan dalam struktur proses yang lebih jelas daripada disembunyikan dalam penutupan yang terfragmentasi.

5. Masalah ini menjadi semakin penting dalam proyek iOS

Salah satu perubahan terbesar dalam proyek iOS saat ini adalah “asinkroni telah berubah dari kemampuan marjinal menjadi kemampuan tulang punggung.”

Di masa lalu, asynchronous lebih tentang “klik dan kirim permintaan”. Sekarang secara asinkron berpartisipasi langsung dalam siklus hidup halaman, mesin status, lapisan cache, sistem izin, sistem titik tersembunyi, dan bahkan berpartisipasi dalam perancangan kecepatan respons seluruh produk.

Situasi umum untuk halaman bisnis nyata adalah:

• Akan ada permintaan layar pertama segera setelah halaman dibuka.
• Beberapa modul menggunakan cache lokal untuk menghindar
• Beberapa permintaan bergantung pada profil pengguna atau konfigurasi eksperimental
• Operasi tertentu memerlukan pencegahan masuk kembali
• Beberapa hasil harus dikembalikan ke thread utama untuk mengubah status dengan aman

Berdasarkan premis ini, jika sistem asinkron masih “setiap orang menulis penyelesaiannya sendiri”, kode akan segera beralih dari “dapat bekerja” menjadi “tidak ada yang berani berubah”.

Jadi yang benar-benar menarik perhatian async/await adalah bahwa asinkron telah menjadi metode kerja default di aplikasi modern.

6. Ini adalah pintu masuk ke seluruh model konkurensi Swift.

Jika Anda hanya melihat fitur tata bahasa ini, async/await tampaknya merupakan ekspresi asinkron yang lebih baik.

Namun jika Anda melihat Swift Concurrency secara keseluruhan, ini sebenarnya membuka jalan bagi kemampuan berikut:

• Task: Memperjelas batasan tugas dan siklus hidup
• MainActor: Membatasi semantik eksekusi status terkait UI
• Actor: Isolasi keadaan bersama yang bisa berubah
• Konkurensi terstruktur: memasukkan subtugas ke dalam siklus hidup tugas induk

Dengan kata lain, Swift tidak hanya mencoba menyediakan API asinkron yang lebih nyaman, namun juga mencoba mengubah “konkurensi” dari teknik sedikit demi sedikit menjadi serangkaian model yang dapat disusun, masuk akal, dan dapat diperiksa bahasa.

Hal ini juga menunjukkan bahwa async/await tidak bisa dianggap hanya sebagai “lebih mudah untuk ditulis”. Apa yang sebenarnya terhubung di baliknya adalah serangkaian filosofi desain konkurensi yang baru.

7. Tidak otomatis menyelesaikan semua masalah, namun mengubah sifat masalah.

Perlu juga diperjelas di sini: dengan async/await, bug konkurensi tidak akan hilang secara otomatis.

Itu tidak menyelesaikan:

• Desain batas negara yang salah
• Tugas lama menimpa hasil baru
• ViewModel mengambil terlalu banyak tanggung jawab secara bersamaan
• Strategi pembatalan misi tidak dipikirkan sama sekali

Tapi itu mengubah satu hal yang sangat penting: Banyak masalah yang bukan lagi “karena ungkapannya terlalu membingungkan dan saya bahkan tidak bisa melihat seperti apa masalahnya”, tetapi “masalahnya sudah diungkapkan dengan jelas”.

Ini mungkin terdengar seperti sebuah langkah mundur, namun sebenarnya ini adalah sebuah langkah maju yang besar. Karena hanya jika masalahnya dapat diungkapkan, proses debug, peninjauan, dan pemfaktoran ulang dapat menjadi efektif.

8. Kesimpulan: Swift memperkenalkan async/menunggu untuk tidak menulis lebih sedikit penutupan

Singkatnya, saya akan mengatakan:

Swift memperkenalkan async/await untuk membuat kode asinkron dapat dimengerti, masuk akal, dan dipelihara kembali.

Jadi ini adalah langkah pertama dalam meningkatkan model konkurensi.

Setelah Anda memahami hal ini, saat Anda melihat Task, Actor, dan MainActor nanti, Anda tidak akan menganggapnya sebagai titik sintaksis yang tersebar, namun Anda akan memahami bahwa apa yang dilakukan Swift adalah hal yang lebih besar: **Klasifikasi ulang konkurensi dari “keterampilan empiris” menjadi “aturan bahasa”. **