為什麼模擬器永遠不夠#

行動裝置的瀏覽量持續上升，行動版網站幾乎已是標配。為避免 SEO 被瓜分或同時維護多套網站，多數團隊會以 RWD（Responsive Web Design）為主軸開發。

開發時最常用的就是 Chrome DevTools 內建的 Mobile Viewport Simulator，但即使在 DevTools 內 CSS 都調對了，把網頁打開到真機還是常見破版。除了 CSS，JavaScript 在不同行動瀏覽器的行為也有不少落差，所以實機測試仍不可省略。

本章從 debug 視角整理三件事：

  • Chrome DevTools 的 Device Mode 中值得熟練的功能
  • Android 與 iOS 的 Remote Debugging 流程
  • 額外有幫助的行動版測試工具

Device Mode 重點功能#

點擊 DevTools 左上角的手機圖示就會進入 Device Mode（Device Toolbar）。除了切換 Moto G4、iPhone 6/7/8 Plus 等預設裝置外，工具列中還有幾個關鍵設定。

Throttle#

把 Online 下拉，內建只有兩種較粗的快捷選項，能同時節流流量與 CPU：

  • Mid-tier mobile：Fast 3G 加上 CPU 4× slowdown
  • Low-end mobile：Slow 3G 加上 CPU 6× slowdown

更細的節流參數要到 Network 或 Performance 面板調整。要留意的是，Device Mode 的節流是「相對於當下開發機」的等比例放慢，如果開發機本身效能很好，看到的差距可能仍不夠真實，加上行動硬體架構與桌機差異很大，最終仍以實機量測為準。

Rotate#

旋轉圖示用來切換 Portrait（直式）與 Landscape（橫式）。橫式畫面常常需要額外的 UX 細節調整；JavaScript 端則可以監聽 orientationchange 事件，在方向改變時做出反應。

Device Pixel Ratio (DPR)#

CSS Pixel 並不等於螢幕的實體 Pixel，DPR 就是兩者的比例。例如 iPhone X 的 DPR 為 3，CSS 上的 375 × 812 對應實體的 1125 × 2436。

行動裝置螢幕雖然較小，DPI 卻較高（每英吋的 Pixel 更密）。瀏覽器會盡量塞下所有內容，把 CSS Pixel 等比例縮小到實體 Pixel，結果就是頁面被縮成原本的三分之一。因此 HTML 通常會加上：

<meta name="viewport" content="width=device-width, initial-scale=1" />

讓瀏覽器尊重 CSS Pixel 與 DPR 的關係，CSS 30px 的元素會佔到實體 90 個 Pixel，使用者才看得清楚。

Device Type#

模擬行動裝置時，預設會把點擊事件改成 touch，Scrollbar 樣式也會跟著切換。下拉選單可以在 Mobile/Desktop 與 touch/no touch 之間自由排列組合。

螢幕較窄時 Device Toolbar 的部分圖示會自動隱藏，曾經因此誤以為功能消失，可以先把視窗拉寬再操作。

Sensors 面板#

按 Esc 叫出 Drawer，切到 Sensors 面板，可以模擬行動裝置常見的感測訊號。

Geolocation#

可改變經緯度、語系、時區，或選擇預設地點，也能切到 Location unavailable 模擬無法取得位置的情境。

Orientation#

注意這裡的 Orientation 不同於前述的 Rotate——它指的是裝置與地心引力之間的相對旋轉角度。前端透過 deviceorientation 事件可以拿到當下的角度；再搭配 devicemotion 事件就能取得加速度，做出類似搖桿的互動。

Rendering 面板#

Drawer 內的 Rendering 面板提供畫面相關的模擬選項：

  • Emulate CSS media type：可直接以 print 模式檢視頁面，不必真的列印或預覽。
  • Emulate CSS media feature prefers-color-scheme：模擬瀏覽器的深色／淺色模式。CSS 可以據此切換樣式：
body {
  background-color: black;
  color: white;
}
@media screen and (prefers-color-scheme: light) {
  body {
    background-color: white;
    color: black;
  }
}
  • Emulate vision deficiencies：模擬視覺障礙，例如模糊、色盲，方便檢查可及性。

行動裝置的 Remote Debugging#

模擬器再準也只是模擬。真的要看實機行為，可以在電腦上開啟手機瀏覽器的 DevTools，這就是 Remote Debugging。

Android（Chrome）#

事前準備：手機與電腦的 Chrome 版本一致。

  • 在手機的「關於手機」裡連點版本號開啟開發者選項，再打開 USB Debugging（USB 偵錯）。透過 ADB (Android Debug Bridge) 機制，瀏覽器才能透過 USB 與電腦溝通。
  • 用線連接手機與電腦，在電腦 Chrome 網址列輸入 chrome://inspect，會看到這個頁面：
chrome://inspect/#devices
  • 手機跳出「允許 USB 偵錯嗎？」對話框，選擇允許。
  • 開啟手機 Chrome 之後，電腦 Chrome 會列出手機目前打開的分頁，點 inspect 就會打開 DevTools。

DevTools 左側顯示的是手機畫面的 Screencast，雖然 FPS 不高，但仍可以正常 Inspect 元素，背景透過 USB 進行 port forwarding 把流量轉發到手機，讓 DevTools 像在本地一樣操作。

iOS（Safari）#

事前準備：iPhone 加上 Mac。

  • iPhone 進入「設定」➡️「Safari」➡️「進階」，開啟 Web Inspector 與 JavaScript。
  • 在 Mac 上打開 Safari，選單列「Safari」➡️「偏好設定」➡️「進階」，勾選「在選單列中顯示開發選單」。
  • 用實體線連接 iPhone 與 Mac，手機端跳出「信任此電腦？」時選擇信任。
  • 打開 Mac Safari 的「開發」選單，就會看到 iOS Safari 目前打開的分頁，點選後即可開啟對應的 Safari DevTools。

介面與 Chrome DevTools 略有差異，但常用的 Elements、Console、Network、Sources 等面板大致都找得到。

額外的行動測試工具#

除了功能驗證，行動版網站還會關心效能與規範符合度，下面兩個工具可作為日常檢查的補充。

WebPageTest#

WebPageTest ↗ 提供與 Performance 面板類似的截圖、效能、事件時間軸，但更強的是可以選擇不同地理位置與真實裝置進行測試，呈現的是「在那台機器上實際載入」的結果，比 DevTools 模擬更貼近真實。它還支援比較歷史測試、批次跑多種設定、量測連續載入的快取行為，甚至串接 CI/CD。

Mobile Friendly Test#

Google 提供的 Mobile Friendly Test ↗ 會讓 Googlebot 實際爬一次頁面（會受 robots.txt 影響），並列出常見的行動端問題，例如內容超出螢幕、字體過小、可點擊元素彼此距離太近等。在改版上線前順手檢查，能避免不少 SEO 與可用性的小坑。

原文出處#

  • 原書/iThome：https://ithelp.ithome.com.tw/articles/10252037
Backward 為什麼要好好學 DevTools Chrome DevTools 全景介紹 Forward