原文作者：Eric
写在最前：欢迎你来到“UC国际技术”公众号，我们将为大家提供与客户端、服务端、算法、测试、数据、前端等相关的高质量技术文章，不限于原创与翻译。
目前 Apple Watch 也有浏览器了。 Apple 创造了一类在 web 中通用的极小视图窗口。 iPhone WebKit 给我们带来了<meta name =“viewport” content =“width = device-width”>; ?而 Watch WebKit 创造了 <meta name =“disabled-adaptations” content =“watch”>。
2018 年的 <meta>-magic 与 2007 年的功能相同。 除非你在提前声音你考虑的是一英寸宽的屏幕，否则 Apple 会假设你是一个更大更常见的视图窗口，并缩小视图。
我比较好奇它的实现细节及其对响应式图像的处理方式，所以我进行了一个测试。 最近，我终于说服某人（我的老板，hi Colin）在他的 WatchOS 5 上进行测试，结果很有意思，我们一起来看看。
我的期望是，即使没有新的 meta 声明，Apple Watch 也能响应式地准确判断 DPR。 我的预期 DPR 是这样的：
但现实却是这样的：
Apple Watch 会模拟 320 像素 x 2 = 640 实际像素宽的视图窗口（还是精确的物理像素！），对屏幕上的其它的东西进行缩放以适应该窗口。
那么响应式图像的实际意义是什么？ 拿这个 <img> 来说：
默认情况下，即使用户需要的只是 tiny.jpg 的分辨率，Apple Watches 还是会选择 small.jpg。 好烧流量啊?！
要避免这种情况，你得在 <head> 中加上这段神奇的文字：
加上之后，DPR 是这样的：
这将使响应式图像更高效地做选择，并且强制确保布局基于 136 像素宽的视图窗口。
艺术感
我猜大多数响应式布局在 136 像素时表现不佳。 你知道还有什么可能经不起这种缩放吗？ 没错，就是图片！ 在极小的物理尺寸下，许多东西都将变得非常小，非常不清晰：
因此，在设计小屏幕时，请考虑一下艺术感。
…像这样 ?。 对了！ 你可以使用 Cloudinary 等工具自动进行图像识别和放大。
小贴士 ?
我认为（？）Apple Watch WebKit 的 uasge 数据目前仅仅只是一个舍入错误，但如果推动响应式设计的极限真的很重要，Apple Watch 会给出一个这么做的理由。
总结：
试着把你的布局调整为 136 像素宽
在你的 <img> 的 src 集合中使用 300w-ish 的资源
考虑艺术感以保持图像清晰可辨
使用神奇的 <meta>
