您和使用者都希望行動網頁應用程式能夠順暢回應觸控操作，並流暢捲動畫面。開發這些事件應該很簡單，但很遺憾，行動網路瀏覽器如何在捲動期間回應觸控事件，這部分在 TouchEvent 規格中並未提供實作細節。因此，方法可大致分為 4 類。這種情況顯示了在提供流暢捲動體驗與維持開發人員控管權限之間的根本衝突。
四種不同的觸控事件處理模式？
瀏覽器之間的行為差異可分為四種模式。
一般同步事件處理
觸控移動事件會在捲動期間傳送，且每次捲動更新都會阻斷，直到觸控移動處理完成為止。這麼做雖然最容易理解且最強大，但會影響捲動效能，因為這表示捲動期間的每個影格都必須在主執行緒上阻斷。
瀏覽器：Android 瀏覽器 (Android 4.0.4、4.3)、Mobile Safari (捲動 div 時)
非同步 touchmove 處理
觸控移動事件會在捲動期間傳送，但捲動可能會以非同步方式進行 (系統會在捲動開始後忽略觸控移動事件)。這可能會導致事件「雙重處理」，例如在網站對 touchmove 執行某些操作後，繼續捲動並呼叫事件的 preventDefault，告知瀏覽器不要處理該事件。
瀏覽器：行動版 Safari (捲動文件時)、Firefox
捲動畫面時抑制觸控移動
捲動開始後不會傳送 Touchmove 事件，且必須等到 touchend 事件後才會恢復。在這個模型中，很難分辨靜止觸控和捲動之間的差異。
瀏覽器：Samsung Browser (傳送 mousemove 事件)
Touchcancel on scroll start
您無法同時擁有流暢捲動和開發人員控管功能，而這個模型清楚說明瞭流暢捲動和事件處理之間的取捨，類似於 Pointer Events 規格語意。某些可能需要追蹤手指的體驗 (例如拉動重新整理) 無法使用。
瀏覽器：Chrome 電腦版 M32 以上版本、Chrome Android 版
變更原因
Android 版 Chrome 目前使用 Chrome 的舊版模式：在捲動開始時觸發 touchcancel，這可提升捲動效能，但會讓開發人員感到困惑。特別是，部分開發人員不瞭解 touchcancel 事件或如何處理這類事件，導致部分網站無法正常運作。更重要的是，整個類別的 UI 捲動效果和行為 (例如拉動更新、隱藏式列和對齊點) 很難或無法順利實作。
與其新增特別的硬式編碼功能來支援這些效果，Chrome 的目標是專注於新增平台原始碼，讓開發人員能直接實作這些效果。如要瞭解這項理念的一般說明，請參閱 Rational Web Platform。
Chrome 的新模型：Throttled Async Touchmove 模型
Chrome 推出新行為，旨在改善與其他瀏覽器在捲動時所寫程式碼的相容性，以及啟用在捲動時需要取得 touchmove 事件的其他情境。這項功能預設為啟用，您可以使用下列旗標 chrome://flags\#touch-scrolling-mode 將其關閉。
新的行為如下：
- 第一個 touchmove 會同步傳送，以便取消捲動
- 在捲動期間
- 觸控移動事件會以非同步方式傳送
- 每 200 毫秒限制為 1 個事件，或超過 CSS 15 像素斜率區域
- Event.cancelable 為 false
- 否則，當主動捲動終止或因達到捲動限制而無法捲動時，觸控移動事件會以正常方式同步觸發
- 使用者放開手指時，系統「一律」會觸發 touchend 事件
您可以在 Android 版 Chrome 中試用這個示範，並切換 chrome://flags\#touch-scrolling-mode 標記，看看差異。
請提供您寶貴的意見
非同步 Touchmove 模型可改善跨瀏覽器的相容性，並啟用新類型的觸控手勢效果。我們很想聽聽開發人員的想法，以及您能透過這項功能發揮創意。