遠端 Mac 桌面色彩與 HiDPI 驗收基線

遠端連線至雲端 Mac 後，設計稿中的灰色可能看起來偏藍，模擬器文字邊緣也可能比本機更模糊。此時先不要修改色彩值或替換圖片。遠端桌面呈現的是「應用程式完成算繪、畫面經過傳輸，再由本機螢幕顯示」的最終結果，任何一個環節都可能引入縮放、壓縮或色彩轉換。正確做法是先保存雲端原始檔案，再逐層定位差異來源。

先拆分三層變因

一次遠端視覺驗收至少包含三個層面：

1. 雲端 Mac 實際產生的像素，包括應用程式視窗、模擬器截圖與匯出檔案。
2. 遠端連線對畫面套用的縮放、色彩深度轉換與壓縮。
3. 本機裝置的顯示縮放、色彩描述檔與用戶端視窗尺寸。

如果只擷取遠端畫面的截圖，第二層與第三層會同時進入證據，之後便無法判斷問題出在哪一層。建議為每次驗收建立獨立目錄，分別保存系統資訊、雲端原始截圖與本機觀察記錄。

mkdir -p "$HOME/visual-baseline"/{system,source,notes}
system_profiler SPDisplaysDataType \
  > "$HOME/visual-baseline/system/displays.txt"
system_profiler SPColorSyncDataType \
  > "$HOME/visual-baseline/system/colorsync.txt"
sw_vers > "$HOME/visual-baseline/system/macos.txt"

這些檔案不是用來比較效能，而是用於回答三個基本問題：當時使用哪個系統版本、桌面的實際輸出尺寸為何，以及系統辨識到哪些色彩描述檔。

遠端桌面適合操作與快速複查，但肉眼看到的遠端畫面不能取代雲端產生的原始檔案。

固定解析度與縮放關係

畫面模糊最常見的原因通常不是素材解析度不足，而是邏輯尺寸、實體像素與用戶端視窗未依整數比例縮放。先在顯示器設定中選擇固定級別，記錄「看起來像」的邏輯尺寸，再透過系統報告確認實際輸出像素。驗收期間不要頻繁切換解析度。

用戶端應優先使用一比一顯示。若視窗無法容納完整畫面，可暫時縮放以便操作，但在擷取驗收證據前應恢復原始比例。若用戶端提供「配合視窗大小」與「拉伸填滿」選項，應注意兩者的差異：前者通常會保留長寬比，後者則可能使圓形、字型與像素網格變形。

建立可重複使用的測試畫面

基準畫面應同時包含小字級文字、單像素線條、圓角、半透明陰影、灰階與連續漸層。不要只使用色彩鮮豔的首頁，因為高對比的大面積色塊很難暴露縮放誤差。測試畫面應固定內容與視窗尺寸，並記錄產生該畫面的提交版本。

如果驗收目標是 iOS 介面，應優先從已啟動的模擬器直接匯出原始截圖：

mkdir -p "$HOME/visual-baseline/source"
xcrun simctl io booted screenshot \
  "$HOME/visual-baseline/source/simulator.png"
sips -g pixelWidth -g pixelHeight -g profile \
  "$HOME/visual-baseline/source/simulator.png"
shasum -a 256 "$HOME/visual-baseline/source/simulator.png"

雜湊值可用來確認團隊成員拿到的是同一個檔案，但不代表兩張視覺效果相同的圖片必須具有相同雜湊值；重新儲存圖片可能會改變中繼資料或編碼方式。

使用原始截圖判斷問題所在層級

先將雲端產生的 simulator.png 下載至本機，不要經過通訊軟體預覽或二次轉碼。使用可按一比一像素顯示圖片的方式，檢查文字邊緣、細線與漸層。

若原始檔案清晰，但遠端桌面畫面模糊，就不需要修改應用程式；問題位於傳輸或用戶端縮放層。若原始檔案同樣模糊，再檢查圖片素材倍率、版面配置是否落在非整數像素、文字點陣化方式，以及截圖所使用的目標裝置。若只有本機某一台顯示器看起來偏色，應比對檔案的色彩描述與本機顯示設定，而不是直接修改設計稿的色彩值。

可依照下列順序保存記錄：

01-source.png        由雲端工具直接產生的原始圖片
02-remote-view.png   遠端用戶端顯示的畫面
03-local-view.txt    本機螢幕、縮放與用戶端設定
04-system.txt        雲端顯示與色彩環境

比對時一次只變更一項變因。例如，先保持雲端解析度不變，只切換用戶端縮放設定；確認結果後，再測試其他色彩深度或壓縮級別。同時變更多項設定，會使結論失去可重現性。

處理偏色而不破壞系統基準

處理色彩問題時，應先確認檔案是否包含描述資訊。sips -g profile 可以快速查看圖片關聯的描述檔，但無法證明整條傳輸鏈都完全正確。如果匯出工具允許指定輸出色彩空間，應在專案規範中固定選項，並讓自動化工作與人工匯出採用相同規則。

不要為了讓遠端預覽「看起來接近本機」，便任意替換雲端系統的預設顯示描述檔。這可能讓某個用戶端看起來正常，卻影響截圖、影片匯出或其他成員的工作階段。較穩妥的做法是維持雲端基準穩定，在本機用戶端記錄顯示模式，並始終以原始產出作為最終判斷依據。

對於半透明陰影與深色漸層，也要留意遠端壓縮造成的色帶。可放大原始圖片進行檢查：如果原圖平滑，但遠端畫面出現斷層，代表不需要調整應用程式中的漸層；只有在原圖本身已出現明顯斷層時，才需要進一步檢查素材位元深度、匯出參數或算繪流程。

將驗收流程納入交接清單

團隊應將視覺基準與程式碼版本綁定，而不是依賴某位成員記住用戶端設定。每次更換系統版本、遠端用戶端、顯示解析度或截圖目標裝置後，都應重新產生一組基準檔案。

交接前至少確認：

• 雲端系統版本與顯示報告均已保存。
• 遠端桌面使用固定解析度，且用戶端未採用非等比例拉伸。
• 模擬器或應用程式已直接產生原始截圖。
• 原始圖片的像素尺寸、色彩描述與雜湊值均已記錄。
• 在判定模糊或偏色之前，已分別檢查原始算繪、傳輸畫面與本機顯示。
• 缺陷記錄包含提交版本、目標裝置、用戶端設定與最小重現步驟。
• 所有暫存測試檔案均已移出專案產出目錄，避免進入正式歸檔。

在 VMOak 的遠端 Mac 上執行這套流程時，也應將連線體驗與產出驗收分開：前者著重操作是否流暢，後者則確認雲端產生的檔案是否符合規範。只要始終從原始產出開始蒐集證據，遠端壓縮、HiDPI 縮放與真正的算繪缺陷就不會混為同一個問題。

常見問題