AJAX tak segerak dan segerak

Penyegerakan perlu menunggu keputusan dikembalikan sebelum meneruskan Operasi tak segerak secara amnya, adalah perlu untuk memantau hasil tak segerak.
Penyegerakan ialah baris gilir dalam garisan lurus, asynchronous tidak dalam baris gilir dan masing-masing berjalan dengan caranya sendiri.

1. Apakah perbezaan antara segerak dan tak segerak?

Segerak: Serahkan permintaan -> Tunggu pemprosesan pelayan -> permintaan dicetuskan oleh peristiwa ->Pemprosesan pelayan (ini bermakna penyemak imbas masih boleh melakukan perkara lain) ->Pemprosesan selesai

2. Dalam keadaan apa ia digunakan?

1. Berfikiran tunggal: Anda hanya boleh melakukan satu perkara pada masa ini, dan perkara lain mesti menunggu perkara semasa selesai sebelum anda boleh meneruskan perkara seterusnya.

2. Separuh hati: Anda boleh melakukan beberapa perkara pada masa yang sama: tangan kiri anda menekan bar ruang, tangan kanan anda boleh terus memukul tetikus dan mata anda perlu melihat skrin pada masa yang sama, yang sangat sukar.

Apabila Ajax menghantar permintaan, ia dibahagikan kepada segerak dan tak segerak: Kaedah penghantaran tak segerak adalah yang paling biasa digunakan dan lalai Kaedah ini mengelakkan kelewatan masa yang dibawa kepada pengguna melalui pengambilan pelayan. Semasa penghantaran tak segerak, ia hanya berjalan secara senyap di belakang tabir, dan pengguna masih boleh melakukan apa yang dia lakukan tanpa memberi pengguna sebarang perasaan menunggu. Apabila jumlah data yang dihantar adalah besar, masa pengambilan pelayan akan menjadi lebih lama, tetapi pengguna tidak mengetahuinya. Pengguna masih fokus pada operasi pada halaman dan tidak tahu apa yang telah dilakukan oleh pelayan, jadi ia memberikannya pengguna pengalaman yang baik.

Kaedah penghantaran tak segerak adalah sebaliknya. Ia sama seperti saat halaman dimuatkan Selepas permintaan segerak dikeluarkan, penyemak imbas sedang menunggu pelayan menyelesaikan pengambilan dan mengembalikan hasilnya. Pada masa ini, tetikus akan bertukar menjadi bentuk menunggu, mengingatkan pengguna kami bahawa permintaan itu belum lagi dijawab. Anda tidak boleh berbuat apa-apa dan pengguna kami tidak boleh berbuat apa-apa. tunggu... Walaupun pengguna sudah biasa menunggu halaman pembetulan dimuatkan Walaupun masa untuk menyegerakkan permintaan dalam Ajax biasanya tidak lebih lama daripada masa memuatkan keseluruhan halaman, anda perlu tahu betapa menyakitkannya. untuk tidak berbuat apa-apa dan hanya menunggu di sana secara pasif. Oleh itu, permintaan segerak ini harus digunakan dengan berhati-hati...

Pada ketika ini, kita perlu bertanya soalan itu, memandangkan permintaan tak segerak sangat bagus, kenapa tidak gunakan permintaan tak segerak? Cuma jangan buat permintaan segerak. Haha, jangan terlalu tergesa-gesa Jika terdapat situasi sedemikian, hasil permintaan kami dalam langkah ini adalah premis permintaan seterusnya rasa. Jadi adakah anda fikir anda harus menggunakan permintaan segerak atau permintaan tak segerak? Jelas sekali, selaraskan permintaan tersebut Untuk menjadikan langkah seterusnya lebih bermakna, mengapa tidak tunggu seketika untuk pengguna yang dihormati?

Permintaan segerak dan permintaan tak segerak mempunyai kegunaannya sendiri

Kebaikan dan keburukan Ajax                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 tradisional diserahkan, permintaan dihantar ke pelayan web. Pelayan menerima dan memproses borang masuk, dan kemudian mengembalikan halaman web baharu. Pendekatan ini membazirkan banyak lebar jalur kerana kebanyakan kod HTML dalam dua halaman selalunya sama. Memandangkan setiap interaksi aplikasi memerlukan penghantaran permintaan kepada pelayan, masa respons aplikasi bergantung pada masa respons pelayan. Ini menghasilkan antara muka pengguna yang kurang responsif berbanding apl asli. Tidak seperti ini, aplikasi AJAX hanya boleh menghantar dan mendapatkan semula data yang diperlukan ke pelayan Ia menggunakan SOAP atau beberapa antara muka perkhidmatan web berasaskan XML yang lain, dan menggunakan JavaScript pada klien untuk memproses respons daripada pelayan. Oleh kerana lebih sedikit data yang ditukar antara pelayan dan penyemak imbas, kami melihat aplikasi yang lebih responsif sebagai hasilnya. Pada masa yang sama, banyak kerja pemprosesan boleh diselesaikan pada mesin klien yang membuat permintaan, jadi masa pemprosesan pelayan Web juga dikurangkan.

Kelebihan terbesar menggunakan Ajax ialah ia boleh mengekalkan data tanpa mengemas kini keseluruhan halaman. Ini membolehkan aplikasi web bertindak balas terhadap tindakan pengguna dengan lebih cepat dan mengelakkan penghantaran maklumat yang tidak berubah melalui rangkaian.

Ajax tidak memerlukan sebarang pemalam penyemak imbas, tetapi memerlukan pengguna membenarkan JavaScript untuk melaksanakan pada penyemak imbas. Sama seperti aplikasi DHTML, aplikasi Ajax mesti diuji dengan teliti pada banyak pelayar dan platform yang berbeza. Apabila Ajax matang, beberapa perpustakaan program yang memudahkan penggunaan Ajax juga telah keluar. Begitu juga, satu lagi teknologi pengaturcaraan bantuan telah muncul untuk menyediakan fungsi alternatif untuk pengguna yang tidak menyokong JavaScript.

Kelemahan:

Kritikan utama menggunakan Ajax ialah ia boleh memecahkan tingkah laku biasa butang belakang penyemak imbas. Dalam kes halaman yang dikemas kini secara dinamik, pengguna tidak boleh kembali ke keadaan halaman sebelumnya kerana penyemak imbas hanya boleh mengingati halaman statik dalam sejarah. Perbezaan antara halaman yang telah dibaca sepenuhnya dan halaman yang telah diubah suai secara dinamik adalah sangat halus; pengguna selalunya ingin dapat membatalkan operasi mereka sebelum ini dengan mengklik butang belakang, tetapi dalam aplikasi Ajax, ini tidak mungkin. Lakukan ini. Walau bagaimanapun, pembangun telah menghasilkan pelbagai cara untuk menyelesaikan masalah ini, kebanyakannya adalah dengan mencipta atau menggunakan IFRAME tersembunyi untuk menghasilkan semula perubahan pada halaman apabila pengguna mengklik butang kembali untuk mengakses sejarah. (Sebagai contoh, apabila pengguna mengklik semula dalam Peta Google, ia mencari dalam IFRAME tersembunyi dan kemudian mencerminkan hasil carian ke elemen Ajax untuk memulihkan keadaan aplikasi kepada keadaan pada masa itu.)

Perkara yang berkaitan ialah menggunakan kemas kini halaman dinamik menyukarkan pengguna untuk menyimpan keadaan tertentu ke kegemaran. Penyelesaian kepada masalah ini juga telah muncul, kebanyakannya menggunakan pengecam serpihan URL (sering dipanggil sauh, bahagian selepas # dalam URL) untuk menjejaki dan membenarkan pengguna kembali ke keadaan aplikasi tertentu. (Banyak penyemak imbas membenarkan JavaScript mengemas kini sauh secara dinamik, yang membolehkan aplikasi Ajax mengemas kini sauh serentak dengan kandungan yang dipaparkan.) Penyelesaian ini juga menyelesaikan banyak hujah tentang tidak menyokong butang belakang. Apabila membangunkan Ajax, kependaman rangkaian—masa antara permintaan pengguna dan respons pelayan—perlu dipertimbangkan dengan teliti. Tidak memberikan respons yang jelas kepada pengguna [5], data prabacaan yang tidak betul [6], atau pengendalian XMLHttpRequest [7] yang tidak betul akan menyebabkan pengguna berasa tertangguh, iaitu sesuatu yang pengguna tidak mahu lihat dan tidak faham [8 ]. Penyelesaian biasa ialah menggunakan komponen visual untuk memberitahu pengguna bahawa sistem sedang menjalankan operasi latar belakang dan membaca data dan kandungan.

Beberapa peranti pegang tangan (seperti telefon mudah alih, PDA, dsb.) pada masa ini tidak menyokong enjin Ajax dengan baik yang dibuat dengan JavaScript, keserasian JavaScript dan DeBug semuanya menyusahkan Ajax No-refresh reload; , kerana perubahan halaman tidak begitu jelas seperti muat semula muat semula, jadi mudah menimbulkan masalah kepada pengguna - pengguna tidak pasti sama ada data semasa adalah baharu atau telah dikemas kini penyelesaian sedia ada termasuk: Gesaan lokasi dan kawasan kemas kini data; direka untuk lebih jelas, dan pengguna digesa selepas kemas kini data, dsb.; sokongan untuk media penstriman tidak sebaik FLASH dan Java Applet;