首先讲讲传统web端和webApp的区别，
1.传统的web端通过手机浏览器进行访问，webApp则嵌了个原生那个的壳，而实际还是通过手机自带的浏览器访问的，这点相信大家都知道。
2.从用户打开连接到看到界面的过程中 均是依照文档顺序进行解析，当遇到连接则读取连接内容，webAp在进行资源加载时会优先加载js,css,而将图片等较大的资源放最后下载，这是为了防止阻塞
其次，对DOM的渲染也会放在最后，为了防止JS对DOM进行再次的修改
关于渲染，手机对DOM渲染的代价通常是比较昂贵的，个人理解为了减少内存的消耗，app通常会在JS运行完后再进行DOM的渲染
这也是我在项目中遇到的问题，疑惑与为什么我的alert先运行了而DOM没有渲染出来的思考
关于图片分辨率的问题，
手机的页面宽度比如 iphone6的屏幕宽度为 375
但是它的实际物理像素是 750
因此它的比率是 2
6p的比率则是3
因此6p的分辨率给用户的直观感受会比6高的多
而我们的一张 750px宽度的图片在6下，实际就是 350px
在6p下则是 750/3
当我们这张图片的宽度设为350px时在6中会正好，而到了6P中，它的像素已经被压缩小于350px,自然会呈现不清晰
所以答案是被压缩了
不好意思不会什么专业的术语，只能这么通俗的举例了
那么问题就来了，如何解决不同分辨率下图片清晰度的问题呢
一般的小公司其实并不是很关心这种小问题，因为毕竟不会影响业务，而他们其实并不是特别关心前端这一块，但是作为前端的我们总会希望自己的作品能够尽善尽美
原生的处理方式是，会准备2套图片
一套高分辨率，为了满足高分辨率设备的体验
一套低分辨率，适应低分辨率的设备
实现的方法 大概是使用 @2X之类的代码
让系统自动处理
可是H5该怎么办
曾经看过一遍帖子，说优秀的公司应该有一个自己的图片服务器，根据开发员传的参数来获取对应分辨率的图片
想法非常好，但是可行性却很低
因为前面说过大部分公司特别是小公司，其实并不很注重前端，更不会为了与业务无关的事而浪费宝贵的服务器资源
因为掌握服务器大权的是后台开发的同学而不是前端
而在前端还只是一个小前端的情况下，你更难说服你的领导，至少我的公司要再开一个测试环境领导都推脱
在软硬件不足以我们实现的情况下，只能寻求一些笨方法了
其实也算不上方法，我的处理方式就是简单粗暴的直接上二倍图片
现在虽然还有一倍分辨率的设备，但是已经很少
3倍的其实也不多
主要还是在2倍
关于图片的内存大小，实在不影响体验的前提的能小则小，减少用户流量消耗加快加载速度
而关于如何在不同分辨率设备上设置图片的大小，这里的这个就可以侧面的来解决图片在不同分辨率设备上模糊的问题了，也是一种取巧的方式
关于rem,做手机端web的都不陌生，目前我的解决方案是使用rem
下面大概的讲一下自己的思路
首先我们的UI设计图是基于iphone6, 设计稿大小是 750*1334
获取用户设备宽度和倍率，计算出用户设备基于原稿宽度的缩放比
把这个比率作为DOM根节点的字体大小
因为代码没找到只好大概的解说一下
图片原稿的高宽（px）单位，乘以比率，在换算成rem/em的单位
大概的思路就是这样
因为手机端对rem/em有比较好的缩放机制（和px相比）
所以就干脆的利用rem
字体rem是相对于根元素的字体大小计算的么
其实就是 root em的缩写
我今天的分享就到这里啦，这么久就说了个图片，不好意思
关于图片缩放的代码稍后整理下文档再贴上来
