更相容且更流暢的觸控操作

您和您的使用者希望行動版網站應用程式能夠流暢回應並流暢地捲動至觸控操作。開發這些方法應該可以輕鬆簡單,但幸好,行動版網路瀏覽器在捲動期間回應觸控事件的方式,如 TouchEvent 規格中的實作詳細資料。因此,方法可以大致分為 4 種類別。在這種情況下,會發生捲動流暢度和維護開發人員控制項之間的基本張力。

四種不同的觸控事件處理模型?

瀏覽器之間的行為差異可細分為四個模式。

  1. 一般的同步事件處理

    系統會在捲動時傳送觸控移動事件,並每個捲動更新區塊,直到觸控移動處理作業完成為止。這會是最簡單瞭解也是最強大功能,但對於捲動效能的影響不佳,因為這表示捲動過程中的每個影格都必須在主執行緒上封鎖。

    瀏覽器:Android 瀏覽器 (Android 4.0.4、4.3)、Mobile Safari (捲動 div 時)

  2. 非同步觸控移動處理

    系統會在捲動時傳送觸控移動事件,但捲動可以非同步繼續 (系統會在捲動開始後忽略觸控移動事件)。這可能會導致事件「重複處理」;舉例來說,在網站完成觸控移動後繼續捲動,並呼叫事件上的 preventDefault,告知瀏覽器不要處理事件。

    瀏覽器:行動版 Safari (捲動文件時)、Firefox

  3. 捲動時隱藏觸控移動

    觸控移動事件在捲動開始後不會傳送,並在觸控事件結束後才會繼續。在這個模型中,很難分辨靜止的觸碰和捲動之間的差異。

    瀏覽器:Samsung 瀏覽器 (已傳送 Mousemove 事件)

  4. 捲動開始時輕觸取消

    應用程式只有捲動流暢度和開發人員控制方式,才能明確地在捲動和事件處理之間取捨,類似於指標事件規格的語意。部分體驗可能需要追蹤手指 (例如下拉即可重新整理) 才能使用。

    瀏覽器:Chrome 電腦版 M32 以上版本、Chrome Android

為什麼要改變?

Android 版 Chrome 目前使用 Chrome 的舊版模型:開始捲動時輕觸取消功能,可提升捲動效能,但會導致開發人員混淆。尤其是有些開發人員不知道觸控取消事件或如何處理,這會導致部分網站無法運作。更重要的是,整個類別的 UI 捲動效果和行為 (例如提取重新整理隱藏的長條貼齊點) 很難或無法實作。

Chrome 並不是新增專門的硬式編碼功能來支援這些效果,而是專注於新增平台基本功能,讓開發人員直接實作這些效果。如要瞭解這個理念的一般說明,請參閱 A Rational Web Platform

Chrome 的新模型:經過調節的非同步觸控移動模型

Chrome 推出了新行為,目的是改善捲動時與為其他瀏覽器編寫的程式碼相容,以及支援其他需要在捲動時取得觸控移動事件的情況。這項功能預設為啟用,您可以使用以下標記 chrome://flags\#touch-scrolling-mode 關閉。

新的行為如下:

  • 「第一個」觸控移動會同步傳送,允許取消捲動
  • 進行捲動時
    • 觸控移動事件是以非同步方式傳送
    • throttledthrottled為 1 個事件,或是超過 CSS throttled slop 區域
    • Event.cancelablefalse
  • 否則,觸控移動事件會在主動捲動終止時照常觸發,或因為已超過捲動限制,而無法照常觸發
  • 使用者舉起手指時,「一律」會發生觸控事件

您可以在 Android 版 Chrome 中試用這個示範模式,然後切換 chrome://flags\#touch-scrolling-mode 標記來查看差異。

分享寶貴意見

非同步觸控移動模型 (Async Touchmove 模型) 能夠提升跨瀏覽器的相容性,並支援全新的觸控手勢效果。我們很希望瞭解開發人員的看法,以及瞭解他們可以運用哪些創意。