h5的rem代替px做界面的自适应就是這么简单又强大,以及我的一些经历和认识_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > h5的rem代替px做界面的自适应就是這么简单又强大,以及我的一些经历和认识

h5的rem代替px做界面的自适应就是這么简单又强大,以及我的一些经历和认识

 2016/11/27 5:31:52  css_this  程序员俱乐部  我要评论(0)
  • 摘要:这两天要把公司以前的触屏设备的客户端应用做成h5的web应用,而且有针对不同设备和同一设备下的不同状态(有windows竖屏和横屏和android的平板),而且都有设计师为其针对的不同设计标准包括字体大小和不同ui组件的大小,虽然当时经过讨论,公司老员工建议就按照這个标准去做,不用考虑自适应,因为设备就这几种,但是我是一直不甘心,总想把它做成能适配不同设备分辨率,所以来研究這个问题。因为在之前的公司做过的项目中的某些模块参照过别的产品,发现过有用rem和em的
  • 标签:经历 认识

  这两天要把公司以前的触屏设备的客户端应用做成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
class="language-text">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了。

 

发表评论
用户名: 匿名