กรณีใช้งานสำหรับ Web Workers คืออะไร [ปิด]

174

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้

ปิดให้บริการใน4 ปีที่แล้ว

ปรับปรุงคำถามนี้

ฉันกำลังมองหา scenarious จริงของโลกสำหรับการใช้เว็บแรงงาน API

javascript html web-worker

— Sergey Ilinsky
แหล่งที่มา

พวกเขาสนับสนุนแพลตฟอร์มมือถือ / webkit หรือไม่

— dmp

ไม่ทราบแน่ชัด แต่จะเดาว่าเป็นเช่นนั้น

— Sergey Ilinsky

รองรับ @danp Browser: caniuse.com/webworkers

— Dheeraj Vepakomma

ฉันเขียนกรณีที่เราใช้ผู้ปฏิบัติงานเว็บเป็นครั้งแรกจากนั้นพิจารณาว่าเราทำได้ดีกว่าถ้าไม่มี - windward.net/blogs/web-workers-abandon/#.Vl3QdXarQ-U

— David Thielen

คำตอบ:

143

John Resig (จากชื่อเสียงของ jQuery) มีตัวอย่างที่น่าสนใจมากมายเกี่ยวกับการใช้งานเว็บที่นี่ - เกมกราฟิก crypto
การใช้งานอื่นคือ Web I / O - กล่าวอีกนัยหนึ่งคือการสำรวจ URL ในพื้นหลัง ด้วยวิธีนี้คุณจะไม่บล็อก UI ที่รอผลการสำรวจ
การใช้งานจริงอื่น ๆ : ใน Bespin พวกเขากำลังใช้ Web Workers เพื่อทำการเน้นไวยากรณ์ซึ่งคุณไม่ต้องการบล็อกการแก้ไขรหัสของคุณในขณะที่คุณใช้แอพ
จากMozilla : ผู้ปฏิบัติงานทางเดียวที่มีประโยชน์คือให้โค้ดของคุณทำการคำนวณโดยใช้ตัวประมวลผลโดยไม่บล็อกเธรดส่วนต่อประสานผู้ใช้

เป็นตัวอย่างที่ใช้งานได้จริงลองนึกถึงแอพที่มี #s ใหญ่ (นี่คือโลกแห่งความจริง BTW - นำมาจากแอพที่ฉันตั้งโปรแกรมไว้ ~ 2 ปีก่อน) คุณสามารถเปลี่ยนหนึ่ง # ในตารางผ่านช่องใส่และตัวเลขอื่น ๆ ในคอลัมน์ที่แตกต่างกันได้รับการคำนวณอีกครั้งในกระบวนการที่ค่อนข้างเข้มข้น

เวิร์กโฟลว์เก่าคือ: เปลี่ยน # รับกาแฟในขณะที่จาวาสคริปต์ crunches ผ่านการเปลี่ยนแปลงตัวเลขอื่น ๆ และหน้าเว็บไม่ตอบสนองเป็นเวลา 3 นาที - หลังจากที่ฉันปรับให้เป็นนรกและย้อนกลับ กลับด้วยกาแฟ เปลี่ยน # วินาที ทำซ้ำหลายครั้ง คลิกปุ่ม SAVE

เวิร์กโฟลว์ใหม่กับผู้ปฏิบัติงานอาจเป็น: เปลี่ยน # รับข้อความสถานะว่ามีการคำนวณสิ่งใหม่ แต่คุณสามารถเปลี่ยน #s อื่น ๆ ได้ เปลี่ยน #s เพิ่มเติม เมื่อทำการเปลี่ยนแปลงเสร็จแล้วให้รอจนกว่าการเปลี่ยนแปลงสถานะเป็น "การคำนวณทั้งหมดเสร็จสมบูรณ์คุณสามารถตรวจสอบ #s สุดท้ายและบันทึกได้"

— DVK
แหล่งที่มา

ลิงค์ที่ยอดเยี่ยม! ฉันไม่เคยได้ยินเรื่องของคนงาน ... mmm คนงาน (ใช้เวลานานในการอาบน้ำอุ่น ... )

— Peter Rowell

ฉันรู้ว่านี่เป็นคำตอบสองปี แต่ฉันแค่อยากพูดถึงว่าคุณไม่จำเป็นต้องใช้ Web Workers สำหรับรายการ # 2 (การสำรวจ URL) XHR เกิดขึ้นแบบอะซิงโครนัสและไม่บล็อก ไม่จำเป็นต้องเรียกใช้คำขอ XHR บนเธรดแยกต่างหาก (แน่นอนในแอพที่ทันสมัยที่คุณต้องการใช้ WebSockets แทนการสำรวจ)

— josh3736

@ josh3736 - คุณถูกต้อง แต่ตอนนี้ฉันอยากรู้ว่าการทำคำร้องขอ XHR aync หลายขนานสามารถทำให้เบราว์เซอร์ไม่มีความสุขได้หรือไม่? นอกจากนี้คุณต้องใช้ทรัพยากรในท้องถิ่นเพื่อประมวลผลการตอบสนอง XHR ซึ่งคนงานอาจเป็นประโยชน์

— DVK

หากคำขอแบบขนานทั้งหมดไปยังเซิร์ฟเวอร์เดียวกันคุณจะได้รับขีด จำกัดต่อชื่อโฮสต์หนึ่งระหว่าง 2 และ 9การเชื่อมต่อพร้อมกัน (ฉันคิดว่าข้อ จำกัด นี้จะใช้กับการเชื่อมต่อทั้งหมดไม่ว่าจะเริ่มจากเธรดหลักหรือผู้ปฏิบัติงาน) แน่นอนถ้าคุณมี 10 คำขอพร้อมกันที่ทำงานพร้อมกันในครั้งเดียวคุณอาจต้องคิดใหม่เกี่ยวกับการออกแบบแอปพลิเคชันของคุณ

— josh3736

ยกตัวอย่างง่ายๆของฉัน แต่สิ่งที่คุณอ้างถึงเป็น "#" ในตัวอย่างของคุณด้านบน?

— เฉลียวฉลาด

ฉันใช้มันเพื่อส่งข้อมูลจำนวนมากจากเบราว์เซอร์ไปยังเซิร์ฟเวอร์ เห็นได้ชัดว่าคุณสามารถทำได้ด้วยการโทร AJAX ปกติ แต่ถ้าใช้การเชื่อมต่อที่มีค่าต่อชื่อโฮสต์ นอกจากนี้หากผู้ใช้เปลี่ยนหน้าในระหว่างกระบวนการนี้ (เช่นคลิกลิงก์) วัตถุ JavaScript ของคุณจากหน้าก่อนหน้าจะหายไปและคุณไม่สามารถดำเนินการเรียกกลับได้ เมื่อใช้ผู้ปฏิบัติงานเว็บกิจกรรมนี้เกิดขึ้นนอกแบนด์ดังนั้นคุณจึงมั่นใจได้ว่าจะเสร็จสมบูรณ์

— Kevin Hakanson
แหล่งที่มา

แต่คุณต้องแลกเปลี่ยนข้อความกับเว็บเวิร์ค เมื่อค่าใช้จ่ายในการดำเนินการนี้สมควรได้รับผลประโยชน์?

— Danielo515

กรณีการใช้งานอื่น:

การบีบอัด / ยกเลิกการบีบอัดไฟล์ในพื้นหลังหากคุณมีรูปภาพจำนวนมากและไฟล์สื่ออื่น ๆ ที่แลกเปลี่ยนจากเซิร์ฟเวอร์ในรูปแบบที่บีบอัด

— SBR
แหล่งที่มา

สิ่งนี้ไม่ควรเกิดขึ้นใน JavaScript รูปภาพถูกบีบอัดแล้ว (PNG, JPEG) โดยใช้อัลกอริธึมที่ออกแบบมาเพื่อบีบอัดข้อมูลรูปภาพอย่างมีประสิทธิภาพ การโยนการบีบอัดอีกชั้นหนึ่งที่ด้านบนสามารถเพิ่มขนาดข้อมูล สำหรับข้อมูลประเภทอื่น (เช่นไฟล์ JSON ขนาดใหญ่) การบีบอัดควรได้รับการจัดการโดยเบราว์เซอร์โดยใช้ HTTP gzipping มาตรฐาน หากคุณกำลังทำการบีบอัดใน JavaScript, คุณอาจทำมันผิด

— josh3736

ฉันเห็นผู้ใช้บางรายตัดสิทธิ์การใช้งาน แต่นี่คือสิ่งที่ฉันตั้งใจจะพูด พิจารณาแอปพลิเคชั่นเช่น MS word เช่นเครื่องมือแก้ไขเอกสารที่ทรงพลังซึ่งคุณสามารถฝังรูปภาพไฟล์เพลงข้อมูล excel แผ่น ฯลฯ ในไฟล์เดียว และพิจารณาว่าคุณมีไคลเอ็นต์ที่ทำงานบนเว็บและเดสก์ท็อปไคลเอ็นต์และไคลเอ็นต์ IOS / Android สำหรับกรณีการใช้งานประเภทนี้คุณสามารถจัดเก็บเนื้อหาไฟล์ทั้งหมดในไฟล์ซิปแล้วคลายซิปที่ไคลเอ็นต์แต่ละรายการ

— sbr

bookmarkap Instapaper บีบอัดหน้าที่กำลังบันทึกก่อนที่จะส่งไปยังเซิร์ฟเวอร์ ช่วยประหยัดเวลาและแบนด์วิดธ์

— stevendaniels

@ josh3736 สิ่งเดียวที่เบราว์เซอร์สามารถทำได้คือ gunzip ไฟล์จากเว็บเซิร์ฟเวอร์ (หรือแคชเบราว์เซอร์) ไม่สามารถขยายข้อมูลจากที่จัดเก็บในตัวเครื่องหรือจาก websocket และไม่สามารถบีบอัดได้เลย แอพพลิเคชั่นบนเว็บกำลังส่งข้อมูลเพิ่มขึ้นเรื่อย ๆ และการบีบอัดข้อมูลสำหรับสิ่งนี้มีประโยชน์อย่างยิ่ง ถูกต้องหนึ่งปีที่ผ่านมาเมื่อมีการโพสต์สิ่งนี้: หากคุณนึกถึงกรณีใช้งานที่ไม่ถูกต้องสำหรับการบีบอัด JavaScript คุณอาจขาดจินตนาการ

— Adria

@Adria: มาตรฐาน WebSocket อยู่ในขั้นตอนของการเพิ่มการสนับสนุนการบีบอัด หากคุณกำลังจัดการกับภาพที่สร้างขึ้นในเบราว์เซอร์ ( <canvas>) คุณสามารถรับข้อมูลภาพในรูปแบบที่บีบอัด (เช่น png) ประเด็นของฉันไม่ใช่ว่าจะไม่เหมาะสมที่จะบีบอัดใน JS; ประเด็นของฉันคือในกรณีส่วนใหญ่มันไม่และสำหรับกรณีส่วนใหญ่ - โดยเฉพาะอย่างยิ่งการจัดการกับภาพซึ่งเป็นสิ่งที่คำตอบนี้พูดถึง - มีทางเลือกที่ดีกว่าในการกลิ้งการบีบอัดของคุณเอง

— josh3736