这两天要把公司以前的触屏设备的客户端应用做成h5的web应用，而且有针对不同设备和同一设备下的不同状态(有windows竖屏和横屏和android的平板)，而且都有设计师为其针对的不同设计标准包括字体大小和不同ui组件的大小，虽然当时经过讨论，公司老员工建议就按照這个标准去做，不用考虑自适应，因为设备就这几种，但是我是一直不甘心，总想把它做成能适配不同设备分辨率，所以来研究這个问题。
因为在之前的公司做过的项目中的某些模块参照过别的产品，发现过有用rem和em的，然后就来网上研究学习了解了下这几种相对单位。其中就找到了这篇文章：http://isux.tencent.com/web-app-rem.html，发现这篇文章对除了rem来设计界面的其他方法做了介绍和总结。文章总结了rem相对于其他几种设计方法的好处，其他几种方法的坏处，具体那些坏处请自行去好好看下这篇文章。
之所以之前没有去研究学习rem，包括之前没有去研究接受其他的新技术，比如es6,前端mvvm框架、模块化开发、项目自动构建,编译,打包工具等等。是因为在之前的所在公司，公司任务比较充实，每天都有任务要做，那时用的基本都是老技术，单纯的用html，css，jq，js,easyui开发，虽然有点厌倦，写的代码比较low，但还好业务逻辑这方面比较有趣，加上我本身工作责任心强，所以那时每天还算过得充实。充实的结果导致我每天都在做任务，几乎每天晚上7，8点下班回家，然后吃饭，再洗涑，再搞会其他的，基本上就9点过，10点了，這样下来一天也比较疲倦，就经常导致我无心再学习其他新技术，只想休息放松下，那时我周6加班还是比较频繁，然后就基本只有周日了，但是周6由于想睡懒觉和要洗衣服，打游戏，所以学习时间也变得比较少了,总得意思就是学习时间变少了（但是我不是完全不学习，但那时主要学习js和css去了，js方面主要是es5，那本javascript高级程序设计我看了好多遍，每次都有新收获，逐渐发现js的设计如此之美），当然这其中很大原因还是我懒，其实我还是写了好些博客草稿，只不过都因为這个懒的原因没有去整理逻辑发布。。。。。
但是那段时间还是过得很有价值的，锻炼了我的编程逻辑思维(我是后台出身，所以还是有点编程思维，面向对象的概念，学习js也不是那么吃力。在学校学习了一年C#.NET,然后当初应聘的第一份工作是.net，但是公司框架已成熟，对前端需求大，我就去做了前端，然后爱上了前端，但是公司的几个简单常用的小接口还是我写的，虽然借鉴了些百度，但是还是有自己的东西，比如自己在只上传文件的接口中扩展了对图片base64的解析保存，当时绝对不是抄的别个的。到了现在的公司，由于公司需要，我也会偶尔负责后端开发，比如公司现在的一个小型cms，我独立开发，完全独立开发，从数据库到c#.net的数据层，中间层，业务层等等（后台用三层架构，没用mvc），通用的数据接口和比较常用的接口都是自己写的，没有用第三方框架。当然我的C#.NET还是只是皮毛，数据库设计也是会相对比较简单的的东西，表创建和视图自己写，存储过程用的别个现成的稍微改了一点点，当然我主要喜欢前端，以后也会一直向前端发展，后台我只需要懂点皮毛就可以了，有后台那个概念就OK，主要就是了解B&S的前后端的交互,即浏览器http和服务器的交互，以及前后端的生命周期。)。因为业务逻辑复杂好玩，任务多，当业务逻辑多到我觉得我的代码是垃圾，不堪入目，当时一直没有好的方法去解决这些痛点。现在深深的体会到解决这些痛点的这些新技术带来的快感，爽，并且这些技术会规范你的项目开发逻辑，深深的体会到mvvm设计模式很适合web前端（這里我很推崇vue，相对其他框架来说，它做模块化开发，开发大型应用会比较简单，环境搭建也很简单，有官方的脚手架工具vue-cli，接下里這个项目做完了，更深入的去研究学习vue后，我来给大家分享vue的从0到有，到它的模块化开发是怎样的）。
到了现在的一家公司，由于公司的任务不是那么多，时间也比较足，所以我在空闲时间会去研究怎么让我的代码更简洁、更具可读性，更抽象、更高效的去实现功能业务需求，让项目模块具有可扩展，可复用，可变更，高内聚低耦合等等。然后就是嘿嘿嘿~，不断的一层一层的深入了解，发现惊喜越来越多，实际上发现这些技术也没有想象种那么难，很简单。
回归正题，我以前做界面就是上面那篇文章里提到的流式布局(主要用bootstrap栅格布局)，宽度高分比，高度固定（最开始我高度也百分比，显然不行），这种方式的坏处就是兼容性不是很好，不好维护。下面我就来介绍下最终我觉得很好的rem。
下面是引用知乎的一位用户的回答：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；這样就能兼容不同设备分辨率了，比如，如果在540px设备分辨率下，html的font-size经计算就等于50px,那么0.14rem=0.14rem*50=7px了。