（转自：http://www.cnblogs.com/qiny-easyui/archive/2016/11/26/6104190.html）
这两天要把公司以前的触屏设备的客户端应用做成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大小```csshtml {font-size: calc(100vw/3.75);}
100vw是设备的宽度，除以3.75可以让1rem的大小在iPhone6下等于100px2. 替换页面中的单位，把所有的px单位替换成rem，除以100，比如前面的80px，就是0.8rem这样在iPhone6下，所有元素的尺寸还是和视觉稿的尺寸一样，而iphone5中，因为设备的宽度变小了，100vw/3.75得到的值，会相应的变小，即rem的单位值会变小，页面中所有的尺寸会等比例缩放。这样就可以做到针对任何分辨率的设备保持视觉一致了。最后，前面用到vw单位，但是低版本的设备可能不支持，那么就需要js来处理一下：javascriptdocument.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.14rem200=28px了。
**
