共计 1684 个字符，预计需要花费 5 分钟才能阅读完成。
目标
1. 明确统一 @x 图的标准，以 750×1334 切下来的图 为 @2x 的标准 2. 使用以屏幕宽度为基准的相对单位, 为了适配, 从设计稿到成品肯定存在换算过程 3. 为位图的容器设置宽高适配后效果图: 基本不会出现很不理想的状况
什么才是标准的 @2x 图？
其实已 750×1334 设计出来的图，切下来，刚刚好就是 2x 图，缩小 1 倍就是 1x，乘以 1.5 就是 3x 图
设计稿里量下的宽高就是你需要的宽高吗？
不是的！！比如 750px 的 iphone6 量出 75px 的物体，在 375px 的手机里肯定只有 35px。所以为了适配你必需转换成以屏幕宽度为标准的相对单位, 所以换算过程肯定是存在的, 因为设计稿只是一个 750 的基准。@x 图只针对于图片和图标, 这种需要用到位图的地方详细原理请点击查看. 其目标既是在等大的容器内装入像素更大的位图, 从而补足像素点的缺失。因为只有用到位图的地方才会出现像素缺失和像素丢失的状况, 其他的元素都是系统绘制的矢量图形不受是否是高清屏幕的影响。
@x 图过大过小会出现什么问题？
@x 图比实际需要小
如果 @x 图比实际需要小，那么图像就会模糊。
@x 图比实际需要大
如果 @x 图比实际需要大时会出现什么问题，其实这种情况也会出现问题只是问题不明显，会出现的问题就是图像失真，因为设备实际上没那么多像素点显示，就是丢失一些像素点。这种情况一般不易察觉, 但是问题肯定是存在的。这就是为什么有些同志拿到大图了，却觉得可以的原因，因为只要他限制了图片的大小，他自己也看不出问题。另外还有一点，就是 web 前端同志拿到的图片会过大, 这个影响就比较大了。所以不是用越大的图就越好。
解决方案
@x 图标准还是按照上方的标准。如果发现 ps 切下来的 @2x 比设计稿里的大了，既是出现错误。另外程序端还是建议按设计稿给用到图片的地方设置宽高, 这样防止换了大图后图片撑开的问题。
h5 端解决方案
使用 rem 相对单位而不是 px
rem 是指相对于根元素的字体大小的单位。那么根据该原理：我们只需能动态获取屏幕的 dpr 及宽度信息，并改变根元素的 font-size，其余的所有页面元素也将会进行改变。
<html data-dpr=”1″ style=”font-size: 41.4px;”>
</html>
详细原理请点击查看
存在问题
但是该方案有个问题，rem 单位很不直观。比如大小为 80px 的按钮, 按上面标准换算成 rem 为 1.946rem[这就蛋疼了，你无法直观看出这个按钮多大, 修改起来更是蛋疼。如果没有一套优雅的管理方案，后期修改基本靠感觉或者画点时间计算下 ==]，接下来和大家聊聊如何优雅的使用 rem 单位。
使用 sass 函数来辅助解决
假设对于一个 iphone6 的视觉稿，我们定义它的基准值就是 75 该基准值是根据你的定义变的关于基准值有问题可见这样我们就可以按照设计稿的大小写进程序, 从而便于维护和识别
// 辅助函数
// 例如: .px2rem(height, 80);
@mixin px2rem(@name, @px){
@{name}: @px / 75 * 1rem;
}
图片的话推荐直接使用 @2x 或者 使用矢量图形
图片这里因为 h5 端特殊, 既要考虑流量, 又要考虑清晰度, 这里推荐还是直接使用 @2x 图吧! 别折腾了！
小程序端解决方案
1. 小程序需要使用 rpx
rpx 为小程序自己的单位, 会对设备进行适配 rpx 与 [750*1330] 设计稿 px 的关系 1px==1rpx, 但是在 iphone6 上 0.5px==1rpx 详见
2. 使用 Taro 框架[安利一波]
Taro 方案的初心就是为了打造一个多端开发的解决方案。目前 Taro 代码可以支持转换到 微信 / 百度 / 支付宝 / 字节跳动小程序、H5 端 以及 移动端（React-Native）。Taro.js 是京东出品的小程序框架, 经使用除了不支持一些 react 语法外，基本无大槽点 [这里不经要吐槽下腾讯官方的 wepy，真是坑死人不偿命! 请慎用慎用!] 该框架直接服务到位, 代码直接书写 px 单位[又不用记多一个 rpx 单位了????], 程序框架自动帮你转换????，那么爽的吗？就是这么爽！因为别人 Taro 的目标是 write one, use everyWhere!!
