h5的rem代替px作移动端界面的自适应就是這么简单又强大，以及个人一些经历和认识

　　这两天要把公司之前的触屏设备的客户端应用作成h5的web应用，并且有针对不一样设备和同一设备下的不一样状态(有windows竖屏和横屏和android的平板)，并且都有设计师为其针对的不一样设计标准包括字体大小和不一样ui组件的大小，虽然当时通过讨论，公司老员工建议就按照這个标准去作，不用考虑自适应，由于设备就这几种，可是我是一直不甘心，总想把它作成能适配不一样设备分辨率的东西，因此来研究這个问题(在了解rem以前，我会作自适应，但只是在作了布局上的自适应，不包括字体)。

　　由于在以前的公司作过的项目中的某些模块参照过别的产品，发现过有用rem和em的，而后就来网上研究学习了解了下这几种相对单位。其中就找到了这篇文章：http://isux.tencent.com/web-app-rem.html，发现这篇文章对除了rem来设计界面的其余方法作了介绍和总结。文章总结了rem相对于其余几种设计方法的好处，其余几种方法的坏处，具体那些坏处朋友能够去看下这篇文章。

　　之因此以前没有去研究学习rem，包括以前没有去研究接受其余的新技术，好比es6,前端mvvm框架、模块化开发、项目构建,编译,打包发布工具等等。是由于在以前的所在公司，公司任务比较充实，天天都有任务要作，那时用的基本都是老技术，单纯的用html,css,js,jq,easyui,bootstrap开发，虽然有点厌倦，写的代码比较low，但还好业务逻辑这方面比较有趣，有些界面实现也比较有趣(一直很喜欢作界面)，加上我自己工做责任心强，因此那时天天还算过得充实。充实的结果致使我天天都在作任务，几乎天天晚上7，8点下班回家，而后吃饭，再洗涑，再搞会其余的，基本上就9点过，10点了，這样下来一天也比较疲倦，就常常致使我无意再学习其余新技术，只想休息放松下，那时我周6加班仍是比较频繁，而后就基本只有周日了，可是因为想睡懒觉和要洗衣服，打游戏，因此学习时间也变得比较少了,总得意思就是学习时间变少了（可是我不是彻底不学习，但那时主要学习js和css去了，那本es5我看了好多遍，每次都有新收获。），固然这其中很大缘由仍是我懒，其实我仍是写了好些博客草稿，只不过都由于這个懒的缘由没有去整理发布(10篇没有发布)。。。。。

　　可是那段时间仍是过得颇有价值的，锻炼了我编程的思惟逻辑(我是后台出身，仍是有点面向对象的概念，学习js也不是那么吃力。在学校学习了一年C#.NET,而后当初应聘的第一份工做是.net，可是公司框架已成熟，对前端需求大，我就去作了前端，而后爱上了前端，可是公司的几个简单经常使用的小接口仍是我写的，虽然借鉴了些百度。到了如今的公司，因为公司须要，我也会偶尔负责后端开发，好比公司如今的一个小型cms，我独立开发，彻底独立开发，从数据库到c#.net的数据层，业务层（业务层不多，业务主要在前端，除了通用的数据接口，后端的业务层主要是一些安全验证，好比对前端编码过的where条件解码，过滤sql，避免sql注入；全部的通常处理程序只是做为一个入口，具体的代码编译进dll，虽然做用可能小，可是总比没有好）等等（后台用三层架构，没用mvc），通用的数据接口和比较经常使用的接口是本身参照以前公司接口思想写的(包括树，grid分页等)，没有用第三方框架。固然个人C#.NET仍是只是皮毛，数据库设计也是会相对比较简单的的东西，表建立和视图本身写，存储过程用的别个现成的稍微改了一点点(主要是分页存储过程等通用的，只是加了个where条件参数。等我把前端想学的学完了，我可能会去学sql，学存储过程)，固然我主要喜欢前端，之后也会一直向前端发展，后台我只须要懂点皮毛就能够了，有后台那个概念就OK，主要就是了解B&S的先后端的交互,即浏览器http和服务器的交互，以及先后端的生命周期。)。由于业务逻辑复杂好玩，任务多，当业务逻辑多到我以为个人代码是垃圾，不堪入目，当时一直没有好的方法去解决这些痛点，如今才体会到原来这些新技术就是解决这些痛点的，而且这些技术会规范你的项目开发逻辑，深深的体会到mvvm设计模式很适合web前端（這里我很推崇vue，渐进式的前端框架，组件化的思想，相对其余框架来讲，它作模块化开发，开发大型应用会比较简单，环境搭建也很简单，有官方的脚手架工具vue-cli（安装cli以前，先安装webpack，最好是用淘宝镜像cnpm安装），地址：http://cn.vuejs.org/v2/guide/installation.html）。

　　到了如今的一家公司，因为公司的任务不是那么多，时间也比较足，因此我在空闲时间会去研究怎么让个人代码更简洁、更具可读性，更抽象、更高效的去实现功能业务需求，让项目模块具备可扩展，可复用，易于变动，高内聚低耦合等等。而后就去探索，发现不少惊喜，发现还有不少须要学习的新技术，实际上当你认真的去了解这些技术后，发现也没有想象种那么难，反而是让你的开发变得更简单。

 

　　回归正题，我之前作界面就是上面那篇文章里提到的流式布局(主要用bootstrap栅格布局)，宽度百分比，高度固定（最开始我高度也百分比，显然不行），这种方式的坏处就是兼容性不是很好,只适应特定的几种分辨率，也很差维护。下面我就来介绍下最终我以为很好的rem（若是设计师没用给出明确的组件大小，能够结合bootstrap栅格布局实现快速布局，而且后期能够改形成响应式布局，能够到bootstrap官网定制下载只包含栅格的css代码）。

　　

     下面是引用知乎的一位用户的回答：https://www.zhihu.com/question/21504656

 

 /***************START*************************************/

在移动端能够作到适配不一样的手机分辨率，若是保持总体缩放，没有设计上的差别能够不须要用到`media query`

假设设计师的视觉稿是按照iPhone6的宽度来设计的，即375px (若是是高清的视觉稿750/2=375)
那么，咱们能够彻底按照视觉稿上的尺寸来赋值给元素的样式，好比视觉稿上的尺寸是80px，那么在css中就能够直接定义width:80px; 页面中全部的尺寸都这样来设置。

当全部的网站全部的页面样式都设置好以后。

咱们须要作两件事情：
1. 设置页面的rem大小
```css

html { font-size: calc(100vw/3.75); }

```
100vw是设备的宽度，除以3.75可让1rem的大小在iPhone6下等于100px

2. 替换页面中的单位，把全部的px单位替换成rem，除以100，好比前面的80px，就是0.8rem
这样在iPhone6下，全部元素的尺寸仍是和视觉稿的尺寸同样，而iphone5中，由于设备的宽度变小了，100vw/3.75获得的值，会相应的变小，即rem的单位值会变小，页面中全部的尺寸会等比例缩放。

这样就能够作到针对任何分辨率的设备保持视觉一致了。
最后，前面用到vw单位，可是低版本的设备可能不支持，那么就须要js来处理一下：
```javascript

document.documentElement.style.fontSize = window.innerWidth/3.75 + 'px'

```

之因此前面让1rem等于100px，而不是1rem等于1px，是由于在chrome下针对中文的最小字体是12px。


固然，这种步骤是针对如今的情况改rem来作的，若是一开始就是使用rem，那么写css的时候，能够直接写rem单位，按视觉稿除以100，其实也没有什么计算过程。或者用预处理器的话，也能够写一个`px2rem`的函数，直接改这个函数就能够了。

 

 /*************END******************************/

 

个人最终总结：我认为比较好的方式就是让1rem在设计师给的标准尺寸下等于100px,而后咱们用的时候若是用到14px,直接用0.14rem替换就ok，而后经过js动态根据不一样设备宽带给html的font-size进行计算。假如设计师设计的页面宽度尺寸是1080，js就這样写：

document.documentElement.style.fontSize = window.innerWidth/10.80 + 'px'，這样在1080设备上的html的font-size=100px，0.14rem就等于14px；這样就能兼容不一样设备分辨率了，好比，若是在2160px设备分辨率下，html的font-size经计算就等于200px,那么0.14rem=0.14rem*200=28px了。