คุณและผู้ใช้ต้องการแอปเว็บบนอุปกรณ์เคลื่อนที่ที่ตอบสนองและเลื่อนไปที่การแตะได้อย่างราบรื่น การพัฒนาเบราว์เซอร์ควรเป็นเรื่องง่าย แต่น่าเสียดายที่เว็บเบราว์เซอร์บนอุปกรณ์เคลื่อนที่ตอบสนองต่อเหตุการณ์การแตะระหว่างการเลื่อนได้ทิ้งไว้ในรายละเอียดการใช้งานในข้อกำหนด TouchEvent ด้วยเหตุนี้ วิธีการต่างๆ อาจแบ่งออกเป็น 4 หมวดหมู่โดยประมาณ สถานการณ์นี้ทำให้เกิดความกดดันพื้นฐานระหว่างการนำเสนอความลื่นไหลในการเลื่อนและการคงการควบคุมของนักพัฒนาแอป
การประมวลผลกิจกรรมการสัมผัสที่แตกต่างกัน 4 รูปแบบมีอะไรบ้าง
ความแตกต่างด้านพฤติกรรมระหว่างเบราว์เซอร์ต่างๆ จะแบ่งออกเป็น 4 รูปแบบ
การประมวลผลเหตุการณ์ซิงโครนัสปกติ
ระบบจะส่งเหตุการณ์ Touchmove ในระหว่างการเลื่อนและการบล็อกการอัปเดตการเลื่อนแต่ละครั้งจะบล็อกจนกว่าการจัดการ Touchmove จะเสร็จสมบูรณ์ วิธีนี้เป็นวิธีที่เข้าใจง่ายที่สุดและมีประสิทธิภาพมากที่สุดแต่ไม่ดีต่อประสิทธิภาพในการเลื่อน เนื่องจากหมายความว่าแต่ละเฟรมระหว่างการเลื่อนต้องบล็อกในเทรดหลัก
เบราว์เซอร์: เบราว์เซอร์ Android (Android 4.0.4, 4.3), Safari ในอุปกรณ์เคลื่อนที่ (เมื่อเลื่อน div)
การประมวลผลการแตะเพื่อย้ายแบบอะซิงโครนัส
ระบบจะส่งเหตุการณ์ Touchmove ในระหว่างการเลื่อน แต่การเลื่อนสามารถดำเนินการต่อแบบอะซิงโครนัสได้ (ระบบไม่สนใจเหตุการณ์ Touchmove หลังจากเริ่มเลื่อนแล้ว) ซึ่งอาจทำให้มี "การจัดการซ้ำ" กับเหตุการณ์ต่างๆ เช่น การเลื่อนต่อไปหลังจากที่เว็บไซต์ทำบางอย่างด้วย Touchmove และเรียกใช้ preventDefault ในเหตุการณ์เพื่อบอกเบราว์เซอร์ว่าไม่ต้องจัดการ
เบราว์เซอร์: Safari ในอุปกรณ์เคลื่อนที่ (เมื่อเลื่อนเอกสาร), Firefox
ระงับการแตะขณะเลื่อน
เหตุการณ์ Touchmove จะไม่ส่งหลังจากที่การเลื่อนเริ่มต้น และจะไม่ส่งต่อจนกว่าจะจบเหตุการณ์ Touchend ในรูปแบบนี้ การบอกความแตกต่างระหว่างการแตะอยู่กับที่และการเลื่อนเป็นเรื่องยาก
เบราว์เซอร์: เบราว์เซอร์ Samsung (ส่งเหตุการณ์ mousemove)
ยกเลิกการแตะเมื่อเริ่มการเลื่อน
ทั้งความลื่นไหลในการเลื่อนและการควบคุมสำหรับนักพัฒนาซอฟต์แวร์มีข้อดีที่ต่างกัน และโมเดลนี้จะทำให้เห็นความแตกต่างระหว่างการเลื่อนอย่างราบรื่นและการจัดการเหตุการณ์ ซึ่งคล้ายกับความหมายของเหตุการณ์ของตัวชี้ บางประสบการณ์ที่อาจต้องติดตามนิ้ว เช่น ดึงเพื่อรีเฟรช จะไม่สามารถทำได้
เบราว์เซอร์: Chrome สำหรับเดสก์ท็อป M32 ขึ้นไป, Chrome Android
ทำไมต้องเปลี่ยนแปลง
ปัจจุบัน Chrome สำหรับ Android ใช้โมเดลเก่าของ Chrome ซึ่งก็คือ ให้แตะยกเลิกเมื่อเริ่มต้นเลื่อน ซึ่งเพิ่มประสิทธิภาพการเลื่อน แต่ทำให้นักพัฒนาซอฟต์แวร์เกิดความสับสน โดยเฉพาะอย่างยิ่ง นักพัฒนาซอฟต์แวร์บางรายไม่ทราบเกี่ยวกับเหตุการณ์ Touchcancel หรือวิธีแก้ไข ซึ่งส่งผลให้เว็บไซต์บางแห่งใช้งานไม่ได้ ที่สำคัญไปกว่านั้น เอฟเฟกต์และลักษณะการทำงานของการเลื่อน UI ทั้งหมด เช่น พุลเพื่อรีเฟรช แถบซ่อน และจุดสแนป ใช้งานได้ยากหรือไม่ได้เลย
แทนที่จะเพิ่มฟีเจอร์แบบฮาร์ดโค้ดโดยเฉพาะเพื่อรองรับเอฟเฟกต์เหล่านี้ Chrome มีเป้าหมายที่จะมุ่งเน้นไปที่การเพิ่มข้อมูลพื้นฐานของแพลตฟอร์มที่ทำให้นักพัฒนาซอฟต์แวร์สามารถนำเอฟเฟกต์เหล่านี้ไปใช้ได้โดยตรง ดูแพลตฟอร์มเว็บ Rational สำหรับคำอธิบายทั่วไปของปรัชญานี้
โมเดลใหม่ของ Chrome: โมเดล Async Touchmove ที่มีการควบคุม
Chrome ได้เปิดตัวลักษณะการทำงานใหม่ที่ออกแบบมาเพื่อปรับปรุงความเข้ากันได้กับโค้ดที่เขียนขึ้นสำหรับเบราว์เซอร์อื่นๆ เมื่อเลื่อน รวมถึงเปิดใช้สถานการณ์อื่นๆ ที่ต้องใช้การเหตุการณ์แบบแตะเลื่อนขณะเลื่อน ฟีเจอร์นี้เปิดใช้อยู่โดยค่าเริ่มต้น และคุณจะปิดได้ด้วยการแจ้งว่าไม่เหมาะสมดังนี้ chrome://flags\#touch-scrolling-mode
ลักษณะการทำงานใหม่มีดังนี้
- ระบบจะส่งการแตะครั้งแรกแบบพร้อมกันเพื่อให้สามารถยกเลิกการเลื่อนได้
- ระหว่างการเลื่อนแบบต่อเนื่อง
- ระบบจะส่งเหตุการณ์ touchmove แบบไม่พร้อมกัน
- throttled ถึง 1 เหตุการณ์ต่อ throttled หรือหากเกินขีดจำกัด Slep ของ CSS throttled
- Event.cancelable เป็น false
- มิเช่นนั้น เหตุการณ์ Touchmove จะเริ่มทำงานพร้อมกันตามปกติเมื่อการเลื่อนแบบแอ็กทีฟสิ้นสุดลง หรือเป็นไปไม่ได้เพราะการเลื่อนถึงขีดจำกัดแล้ว
- เหตุการณ์การแตะ ทุกครั้งจะเกิดขึ้นเมื่อผู้ใช้ยกนิ้วขึ้น
คุณลองใช้การสาธิตนี้ได้ใน Chrome สำหรับ Android และสลับธง chrome://flags\#touch-scrolling-mode เพื่อดูความแตกต่าง
บอกให้เราทราบว่าคุณคิดอย่างไร
Async Touchmove Model มีศักยภาพในการปรับปรุงความเข้ากันได้ข้ามเบราว์เซอร์ และเปิดใช้เอฟเฟกต์ท่าทางสัมผัสด้วยการแตะแบบใหม่ได้ เราอยากรับฟังว่านักพัฒนาซอฟต์แวร์คิดอย่างไรและสร้างสรรค์สิ่งใหม่ๆ ที่คุณทำได้ด้วย