原文作者：Eric
譯者：UC 國際研發 Jothy
寫在最前：歡迎你來到“UC國際技術”公眾號，我們將為大家提供與客戶端、服務端、演算法、測試、資料、前端等相關的高質量技術文章，不限於原創與翻譯。
目前 Apple Watch 也有瀏覽器了。 Apple 創造了一類在 web 中通用的極小檢視視窗。 iPhone WebKit 給我們帶來了<
meta name =“viewport” content =“width = device-width”>
;
?而 Watch WebKit 創造了 <
meta name =“disabled-adaptations” content =“watch”>
。
meta name =“viewport” content =“width = device-width”>
;
?而 Watch WebKit 創造了 <
meta name =“disabled-adaptations” content =“watch”>
。
2018 年的 <
meta>
-magic 與 2007 年的功能相同。 除非你在提前聲音你考慮的是一英寸寬的螢幕，否則 Apple 會假設你是一個更大更常見的檢視視窗，並縮小檢視。
meta>
-magic 與 2007 年的功能相同。 除非你在提前聲音你考慮的是一英寸寬的螢幕，否則 Apple 會假設你是一個更大更常見的檢視視窗，並縮小檢視。
我比較好奇它的實現細節及其對響應式影像的處理方式，所以我進行了一個測試。 最近，我終於說服某人（我的老闆，hi Colin）在他的 WatchOS 5 上進行測試，結果很有意思，我們一起來看看。
我的期望是，即使沒有新的 meta 宣告，Apple Watch 也能響應式地準確判斷 DPR。 我的預期 DPR 是這樣的：
但現實卻是這樣的：
Apple Watch 會模擬 320 畫素 x 2 = 640 實際畫素寬的檢視視窗（還是精確的物理畫素！），對螢幕上的其它的東西進行縮放以適應該視窗。
那麼響應式影像的實際意義是什麼？ 拿這個 <
img>
來說：
img>
來說：
預設情況下，即使使用者需要的只是 tiny.jpg 的解析度，Apple Watches 還是會選擇 small.jpg。 好燒流量啊?！
要避免這種情況，你得在 <
head>
中加上這段神奇的文字：
head>
中加上這段神奇的文字：
加上之後，DPR 是這樣的：
這將使響應式影像更高效地做選擇，並且強制確保佈局基於 136 畫素寬的檢視視窗。
藝術感
我猜大多數響應式佈局在 136 畫素時表現不佳。 你知道還有什麼可能經不起這種縮放嗎？ 沒錯，就是圖片！ 在極小的物理尺寸下，許多東西都將變得非常小，非常不清晰：
因此，在設計小螢幕時，請考慮一下藝術感。
…像這樣 ?。 對了！ 你可以使用 Cloudinary 等工具自動進行影像識別和放大。
小貼士 ?
我認為（？）Apple Watch WebKit 的 uasge 資料目前僅僅只是一個舍入錯誤，但如果推動響應式設計的極限真的很重要，Apple Watch 會給出一個這麼做的理由。
總結：
-
試著把你的佈局調整為 136 畫素寬
-
在你的 <
img>
的 src 集合中使用 300w-ish 的資源 -
考慮藝術感以保持影像清晰可辨
-
使用神奇的 <
meta>
⌚️??
英文原文：
https://ericportis.com/posts/2018/respimg-apple-watch/
好文推薦：
“UC國際技術”致力於與你共享高質量的技術文章
歡迎關注我們的公眾號、將文章分享給你的好友