看到这个题目你可能不信，引出这个问题的缘由是几次项目中Chrome模拟器和iPhone6真机预览效果不一致。
为什么在Chrome Emulation模拟手机页面和真机预览效果不一致？
以前觉得不外乎两个原因：
1.某些机型或浏览器对一些CSS属性不支持。
2.某些设备不支持12px以下字体。
今天要补充的第3个原因是对于iPhone手机还会与手机系统设置的显示模式、设备硬件有关。
下面开始讨论iPhone6/iPhone6 Plus的设备屏宽，这里说的设备屏幕宽度专指设备物理显示尺寸（device-width），我们知道苹果从iPhone4开始引进了Retina屏幕，一个CSS像素可以表示多个物理像素（当然，在页面缩放到其他比例时候，也可以做到CSS 的1px表示多个device pixels，只不过导致的是清晰度的不同）。首先要明确，我们前端开发中的CSS
iPhone6设备屏幕宽度是375px，iPhone 6Plus设备屏幕宽度414px，这是我们前端开发人员一向坚信的“真理”。可今天我要质疑这个已成的定论。
首先查找CSS代码的问题，查了reset样式，也进行了CSS validate，没有收获。
既然CSS Media Query媒体查询代码并没生效，隐隐约约开始怀疑曾经自己亲自证实的结论，也就是我们一直认为的：iPhone6设备屏幕宽度是375px，iPhone 6 Plus设备屏幕宽度414px。
怀疑归怀疑，但是自己也不相信会推翻原有结论。而且，经常在国外的技术网站和Stack Overflow游荡，从未遇到过例外啊！只是不放心，为图个心安，于是带着核实情况的心里继续用JS代码来探测设备的宽度。
一个检测屏幕宽度，第二句检测设备像素比。
借来了许多同事的iPhone6和iPhone6 Plus，看到测试结果差点把我惊呆了。有的设备宽度是320，有的是375，有的414，乱了。。。
后来发现从iPhone6开始，系统设置提供了“显示模式”设置。
“显示模式”分为“标准”和“放大”两种选择：如果想让iPhone 6/6 Plus 桌面应用图标显示效果变得更小，可以设置为“标准”模式。想要大图标的显示效果，则可以设为“放大”模式。
通过切换两种显示模式，用JS获取到以下数据：
标准模式屏宽414，放大模式屏宽375.
标准模式屏宽414，放大模式屏宽375.
标准模式屏宽414，放大模式屏宽375.
iPhone6第一个设备（白）
标准模式和放大模式屏宽均为320.
iPhone6第二个设备（白）
标准模式屏宽375，放大模式屏宽320.
iPhone6第三个设备（银）
标准模式屏宽375，放大模式屏宽320.
iPhone6第四个设备（白）
标准模式屏宽375，放大模式屏宽320.
通过观察我们可以发现，iPhone6 Plus在放大模式的屏宽等于iPhone6标准模式屏宽，大部分iPhone6在放大模式的屏宽等于iPhone5/5s的屏宽，这意味着，iPhone6
Plus在放大模式下的显示内容是和iPhone6的标准模式一样的，iPhone6放大模式的内容和iPhone5s的显示内容是接近的。但也有例外，某些iPhone6无论何种显示模式屏宽都是320px。无论在初始设置的时候你选择了哪个显示模式，之后你都是可以进行改变并切换的。
是什么原因造成的，这里不得而知，推测大概与出厂硬件的屏幕材质有关系。或许这种某些iPhone6的特殊情况只在大陆存在吧~~鄙视下苹果区别对待大陆用户的做法！！！
这就引出一个问题，我们在对iPhone设备适配时候，又多出几种情况。iPhone系列设备媒体查询：
//针对大多数iPhone6的标准模式
结论是，做移动端Web兼容测试时候，不能将Chrome模拟效果同iPhone6/Plus真机完全划等号。一定要在确认了iPhone设备所处显示模式和真实屏宽后再针对性的进行调试。
退一步说，姑且认为标准模式和放大模式下设备宽度都是320px的情况属于个例。不过在没有确认iPhone6/iPhone 6 Plus是处于标准模式还是放大模式的前提下，来测试CSS媒体查询代码，来查看真机预览效果，都是不靠谱的做法。因此，在未确认设备显示模式的情况下，这个结论是完全成立的：iPhone6屏宽不一定是375px，iPhone6
注：本文摘自阿里内网的无线博客《无线前端的图片相关工作流程梳理》。其实是一个月前写的，鉴于团队在中国第二届 CSS Conf 上做了《手机淘宝 CSS
实践启示录》的分享，而图片工作流程梳理是其中的一个子话题，故在此一并分享出来，希望仍可以给大家一些经验和启发。另外，考虑到这是一篇公开分享，原版内容有部分删节和调整，里面有一些经验和产出是和我们的工作环境相关的，不完全具有普遍性，还请见谅。
今天很荣幸的跟大家分享一件事情，就是经过差不多半年多的努力，尤其是最近 2 周的 突击扫尾，无线前端团队又在工具流程方面有了一个不小的突破：我们暂且称其为“图片工作流”梳理。
要说最近 1 年里，无线前端开发的一线同学最“难搞”的几件事，图片处理绝对可以排在前三。
- 首先，我们首先要从视觉稿 (绝大部分出自 photoshop) 里把图片合理的分解、测量、切割、导出——俗称“切图”
- 然后，我们要把切好的图放入页面代码中，完成相关的本地调试
- 第三步，把本地图片通过一个内部网站 (名叫 TPS) 上传到我们的图片 CDN 上，并复制图片的 CDN 地址，把本地调试用的相对路径替换掉
- 第四步，不同的图片、不同的外部环境下 (比如 3g 还是 wifi)，我们需要给图片不一样的尺寸、画质展现，并有一系列的配置需要遵循
- 如果视觉稿有更改 (不要小看这件事，微观上还是很频繁的哦)，不好意思，从第一步开始再重新走一遍……
这里面 难搞 在哪些地方呢？我们逐一分析一下：
- 切图的效率并不高，而且每一步都很容易出现返工或再沟通
- 打开 TPS 网站上传图片放到前端开发流程中并不是一个连贯流畅的步骤，而且 GUI 相比于命令行工具的缺陷在于无法和其它工具更好的集成
- 替换 CDN 图片路径的工作机械而繁琐，并且代码中替换后的图片地址失去了原本的可读性，非常容易造成后期的维护困惑甚至混乱
- 适配工作异常繁杂和辛苦，也很容易漏掉其中的某个环节
- 视觉变更的成本高，web 的快速响应的特点在丧失
所以可能把这些东西画成一张图表的话：
在最近半年的一段时间里，无线前端团队先后发起了下面几项工作，从某个点上尝试解决这些问题：
最终这个初始化工程的示例页面的效果如下
这条链路是我们之前最不愿意面对的，今天，我们来看看这条链路变成了什么，假设有一张设计图要换：
- 同名图片文件放入
images 文件夹
额外的，如果尺寸有变化，就加一步：更改相应的 CSS 尺寸代码
在整个团队架构的过程中，大家都在不断尝试，如何以更贴近开发者真实场景的方式，还原真实的问题，找出切实有效的解决方案，而不仅仅是单个功能或特性。这样我们往往会找到问题的关键，用最精细有效的方式把工作的价值最大化。
其实 基于场景的思维方式 不只是流程设计的专利，我们业务上的产品设计、交互设计更需要这样的思维。我个人也正是受到了一些产品经理朋友们的思维方式的影响，把这种方式运用在了我自己的工作内容当中。希望我们产出的这套方案能够给大家创造一些价值，更是向大家传递我们的心得体会，希望这样的思维方式和做事方式可以有更多更广的用武之地。
以上是 的全部内容， 来源链接：
