Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

Memulai dengan Web Worker

by
Read Time:9 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Yusuf Samin (you can also view the original English article)

Salah satu tujuan banyak desain bahasa JavaScript adalah untuk tetap single-threaded dan, dengan extensi, sederhana. Walaupun saya harus mengakui bahwa, mengingat kekhasan konstruksi bahasa, hal ini sederhana! Tapi apa yang kita maksud dengan menjadi "single-threaded" adalah bahwa ada hanya satu thread kontrol dalam JavaScript; Ya, sayangnya, Engine JavaScript Anda dapat melakukan hanya satu hal pada suatu waktu.

Sekarang, itu tidak terdengar terlalu ketat untuk membuat penggunaan prosesor multi core idle di mesin Anda? HTML5 janji untuk mengubah semua itu.


JavaScript's Single Threaded Model

Web Worker hidup di dunia yang terbatas dengan akses No DOM, sebagai DOM not thread-safe.

Satu menganggap JavaScript signle-threaded natural sebagai penyederhanaan, tetapi yang lain menolak sebagai batasan. Kelompok kedua memiliki titik yang sangat baik, terutama ketika aplikasi modern web membuat penggunaan yang banyak JavaScript untuk menangani event UI, query atau polling sisi server berbasis api, pengolahan data dalam jumlah besar, dan memanipulasi DOM pada respon server.

Untuk dapat melakukan begitu banyak dalam single thread kontrol sementara mempertahankan responsif UI adalah sering tugas yang menakutkan, dan memaksa pengembang untuk hacks dan workarounds (seperti menggunakan setTimeout(), setInterval(), atau menggunakan XMLHttpRequest dan DOM event) untuk mencapai concurrency. Namun, it's worth dicatat bahwa teknik ini pasti menyediakan cara untuk membuat panggilan asynchronous, tetapi non-blocking tidak selalu berarti bersamaan. John Resig menjelaskan mengapa Anda tidak dapat menjalankan apa pun secara paralel di blog-nya.

Keterbatasan

Jika Anda telah bekerja dengan JavaScript untuk jumlah waktu yang wajar, itu sangat mungkin bahwa Anda mengalami kotak dialog menjengkelkan berikut yang menyatakan bahwa sejumlah script mengambil terlalu panjang untuk mengeksekusi. Ya, hampir setiap kali halaman Anda berhenti merespons, alasan dapat dikaitkan dengan beberapa kode JavaScript.

Damn this slow machine !!Damn this slow machine !!Damn this slow machine !!

Berikut adalah beberapa alasan mengapa browser Anda hanya mungkin akan menutup dengan sepatu bot saat menjalankan skrip:

  • Manipulasi DOM yang berlebihan: Manipulasi DOM mungkin adalah operasi yang paling mahal yang dapat Anda lakukan dengan JavaScript. Akibatnya, banyak operasi manipulasi DOM membuat skrip menjadi kandidat yang bagus untuk refactoring.
  • Loop yang tidak berkesudahan: Tidak ada salahnya untuk memindai kode untuk kompleks nested loop. Ini cenderung untuk melakukan lebih banyak pekerjaan daripada yang benar-benar dibutuhkan. Mungkin Anda dapat menemukan solusi yang berbeda yang menyediakan fungsi yang sama.
  • Menggabungkan keduanya: yang terburuk yang bisa kita lakukan berulang-ulang adalah memperbarui DOM dalam lingkaran ketika ada solusi yang lebih elegan, seperti menggunakan DocumentFragment,.

Web Worker datang untuk menyelamatkan

... non-blocking tidak selalu berarti bersamaan...

Berkat HTML5 dan Web Worker, Anda sekarang dapat menambah thread baru--menyediakan asynchrony asli. woker baru dapat berjalan di latar belakang sementara thread proses event UI, bahkan jika thread worker sibuk mengolah jumlah data yang berat. Sebagai contoh, seorang pekerja dapat memproses struktur JSON yang besar untuk mengekstrak informasi yang berharga untuk menampilkan di UI. Tapi cukup saya mengoceh; Mari kita lihat beberapa kode langsung.

Menciptakan Worker

Biasanya, kode yang berkaitan dengan worker tinggal di file JavaScript terpisah. parent thead menciptakan worker baru dengan menentukan script file URI dalam konstruktor Worker, yang asynchronously diload dan mengeksekusi JavaScript file.

Memulai Worker

Untuk memulai Worker, parent thread post pesan untuk worker, seperti ini:

Halaman parent dapat berkomunikasi dengan worker yang menggunakan postMessage API, yang juga digunakan untuk cross-origin pesan. Selain mengirimkan tipe primitif data untuk pekerja, postMessage API juga mendukung melewati struktur JSON. Anda tidak bisa, bagaimanapun, melewati fungsi karena mereka mungkin memiliki referensi ke dasar DOM.

Parent dan worker thread memiliki ruang sendiri terpisah; pesan yang disampaikan ke sana kemari disalin daripada bersama.

Di belakang layar, pesan ini adalah serial di pekerja dan kemudian de serial di akhir penerima. Untuk alasan ini, ini tidak disarankan untuk mengirim sejumlah besar data ke worker.

parent thread juga dapat mendaftar callback untuk mendengarkan pesan yang worker kirim kembali setelah melaksanakan task. Hal ini memungkinkan parent thread untuk mengambil tindakan yang diperlukan (seperti memperbarui DOM) setelah worker telah memainkan bagiannya. Mengambil melihat kode ini:

Objek event berisi dua properti penting:

  • target: digunakan untuk mengidentifikasi para worker yang mengirim pesan; terutama berguna dalam beberapa worker environment.
  • data: pesan dikirim oleh worker kembali ke thread parent.

Worker sendiri terdapat dalam prime.js dan register untuk event message yang diterima dari parent. Ini juga menggunakan API postMessage yang sama untuk berkomunikasi dengan parent.

Web worker hidup dalam lingkungan yang terbatas dan thread-safe.

Dalam contoh ini, kita hanya menemukan nomor Perdana tertinggi berikutnya dan berulang kali posting hasil kembali ke parent thread, yang pada gilirannya update UI dengan nilai baru. Dalam konteks Worker, self dan this merujuk kepada lingkup global. Pekerja baik dapat menambahkan pendengar event untuk event message, atau dapat menentukan penangan onmessage untuk mendengarkan pesan yang dikirim oleh parent thread.

Task mencari nomor Perdana berikutnya tidak jelas kasus penggunaan ideal bagi worker, tetapi telah dipilih untuk menunjukkan konsep lewat pesan di sini. Kemudian, kita menjelajahi mungkin dan praktis penggunaan kasus-mana menggunakan Web worker akan benar-benar menuai manfaat.

Mengakhiri Worker

Worker menggunakan resrource yang intensif; mereka adalah tingkat OS-thread. Oleh karena itu, Anda lakukan tidak ingin membuat sejumlah besar thread worker, dan Anda harus menghentikan worker thread setelah itu menyelesaikan tugasnya. worker dapat menghentikan diri mereka sendiri, seperti ini:

Atau parent thread dapat mengakhiri worker:

Keamanan dan pembatasan

Di dalam worker script, kita tidak memiliki akses ke banyak objek JavaScript yang penting seperti document, window, console, parent dan yang paling penting tidak memiliki akses ke DOM. Tidak memilik akses DOM dan tidak dapat memperbarui halaman terdengar terlalu ketat, namun keputusan desain keamanan penting. Bayangkan malapetaka yang dapat menyebabkan jika beberapa thread mencoba untuk memperbarui satu unsur yang sama. Dengan demikian, Web worker hidup dalam lingkungan yang terbatas dan thread-safe.

Setelah mengatakan bahwa, Anda masih dapat menggunakan worker untuk pengolahan data dan kembalikan hasilnya kembali ke main thread, yang kemudian dapat memperbarui DOM. Meskipun mereka ditolak akses ke beberapa objek JavaScript yang cukup penting, worker diijinkan untuk menggunakan beberapa fungsi seperti setTimeout()/clearTimeout(), setInterval()/clearInterval(), navigator, dll. Anda juga dapat menggunakan objek yang XMLHttpRequest dan localStorage dalam worker.

Same origin restriction

Dalam konteks worker, self dan this merujuk kepada lingkup global.

Untuk berkomunikasi dengan server, worker harus mengikuti same-origin policy. Sebagai contoh, sebuah script yang di-host di http://www.example.com/ tidak dapat mengakses script di https://www.example.com/. Meskipun nama host yang sama, same-original policy menyatakan bahwa protokol harus sama juga. Biasanya, hal ini tidak masalah. Hal ini sangat mungkin bahwa Anda menulis worker, klien, dan melayani mereka dari domain yang sama, tapi mengetahui pembatasan ini selalu berguna.

Isu-isu akses lokal dengan Google Chrome

Google Chrome menempatkan pembatasan pada mengakses pekerja lokal, maka Anda tidak akan dapat menjalankan contoh-contoh ini di setup lokal. Jika Anda ingin menggunakan Chrome, maka Anda harus meng-host file-file ini pada beberapa server atau menggunakan flag --allow-file-access-from-files mulai Chrome dari baris perintah. Untuk OS X, mulai chrome sebagai berikut:

Namun, menggunakan flag ini tidak dianjurkan dalam lingkungan produksi. Dengan demikian, your best bet adalah untuk meng-host file-file ini pada web server dan untuk menguji pekerja web Anda di browser yang didukung.

Debugging Worker dan Error Handling

Tidak memiliki akses ke console membuat ini agak non-sepele, tetapi berkat Chrome Developer Tools, satu dapat debug kode pekerja seolah-olah kode JavaScript lainnya.

Damn this slow machine !!Damn this slow machine !!Damn this slow machine !!

Untuk menangani kesalahan yang dilemparkan oleh web worker, Anda dapat mendengarkan untuk event error populates objek ErrorEvent. Anda dapat memeriksa objek ini untuk mengetahui penyebab kesalahan rinci.

Multiple Worker Thread

Meskipun itu umum untuk memiliki beberapa thread worker membagi pekerjaan antara mereka sendiri, adalah sebuah kata dari hati-hati agar. Spesifikasi resmi menunjukkan bahwa para pekerja ini relatif berat-berat dan diharapkan panjang script yang berjalan di latar belakang. Web Worker tidak dimaksudkan untuk digunakan dalam jumlah besar karena kinerja tinggi start-up biaya dan memori tinggi per instance biaya.

Intro singkat Shared Worker

Spesifikasi menguraikan dua jenis worker: dedicated dan shared. Sejauh ini, kita telah melihat contoh-contoh dedicated worker. Mereka secara langsung terkait dengan creator script/page dalam arti bahwa mereka memiliki hubungan satu untuk satu dengan page/script yang menciptakan mereka. Shared Worker, di sisi lain, dapat dibagi di antara semua halaman dari asal (yaitu: semua halaman atau script pada asal yang sama dapat berkomunikasi dengan shared worker).

Untuk membuat shared worker, hanya memasukan URL script atau nama worker ke konstruktor SharedWorker.

Perbedaan besar dalam cara shared worker digunakan adalah bahwa mereka terkait dengan port untuk melacak script parent mengakses mereka.

Kode snippet berikut menciptakan shared worker, register callback untuk mendengarkan setiap message yang diposting oleh worker dan posting pesan ke shared worker:

Demikian pula, worker dapat mendengarkan untuk event connect, yang diterima ketika klien baru mencoba untuk tersambung ke worker dan kemudian posting pesan itu sesuai.

Karena sifat shared, Anda dapat mempertahankan state bagian yang sama di tab yang berbeda dari aplikasi yang sama, karena kedua halaman tab yang berbeda menggunakan skrip shared worker yang sama untuk memelihara dan report state. Untuk lebih jelasnya mengenai shared worker, saya mendorong Anda untuk membaca spec.


Kasus penggunaan praktis

Web worker tidak dimaksudkan untuk digunakan dalam jumlah besar karena kinerja tinggi start-up biaya dan memori tinggi dan biaya per instance.

real-life skenario mungkin ketika Anda terpaksa harus berurusan dengan API pihak ketiga sinkron yang memaksa thread untuk menunggu hasil sebelum melanjutkan dengan pernyataan berikutnya. Dalam kasus tersebut, Anda dapat mendelegasikan tugas ini kepada pekerja baru spawned untuk meningkatkan kemampuan asinkron untuk keuntungan Anda.

web worker juga unggul dalam pemungutan suara situasi di mana Anda terus-menerus polling tujuan di latar belakang dan posting pesan main thread ketika beberapa data baru tiba.

Anda mungkin juga perlu untuk memproses sejumlah besar data yang dikembalikan oleh server. Secara tradisional, pengolahan banyak data negatif dampak responsif aplikasi, sehingga membuat pengalaman pengguna yang tidak dapat diterima. Solusi yang lebih elegan akan membagi pekerjaan pengolahan antara beberapa worker untuk memproses bebas yang tumpang tindih bagian data.

Kasus penggunaan lain bisa menganalisis video atau audio sumber dengan bantuan beberapa web worker, masing-masing bekerja pada bagian standar dari masalah.


Kesimpulan

Bayangkan kekuatan yang terkait dengan multiple thread di atau di single threaded environment.

Seperti halnya dengan banyak hal dalam HTML5 spec, spec web worker terus berkembang. Jika Anda berencana untuk web worker, itu tidak akan menyakiti untuk memberikan spesifikasi yang terlihat.

Dukungan cross-browser cukup baik untuk didedikasikan pekerja dengan versi terbaru Chrome, Safari dan Firefox. Bahkan IE tidak tertinggal terlalu jauh di belakang dengan IE10 mengambil muatan. Namun, shared worker hanya didukung pada versi terbaru Chrome dan Safari. Anehnya, versi terbaru dari browser Android tersedia dalam Android 4.0 tidak mendukung web wroker, meskipun mereka didukung dalam versi 2.1. Apple juga termasuk dukungan web worker dimulai dengan iOS 5.0.

Bayangkan kekuatan yang terkait dengan multiple thread di jika tidak di single thread environment. Kemungkinan tidak terbatas!

Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.