美文网首页
阶段性总结

阶段性总结

作者: 一许青衫一 | 来源:发表于2019-07-08 16:33 被阅读0次

    前言

      最近两周完成了一个官网的项目,不算复杂,页面也不多。但是是那种前后端未分离的项目,同时需要考虑ipad适配和手机端页面。乍看,需要考虑的细节很多,会有点无从下手的感觉,但随着项目的书写,事情也慢慢梳理清楚了,一些缺漏的知识点也一点点冒了出来。

    设计图的阅读与rem的换算

      一开始是做小程序的,小程序的一大好处就是平台本身就帮前端开发者解决了机型适配问题,开发者对照指定机型的设计图(一般是iphone6),右上角的机型选择为iphone6,然后就可以愉快的书写界面了。


    微信开发者工具

    同时,小程序css样式的单位是动态的rpx,微信平台会自动根据不同手机的分辨率自动改变尺寸。这一点就很好的解决了px的固定问题,保持了页面布局的统一和稳定。解决了这两个繁琐的问题,开发者可以安心处理业务逻辑了,省心了不少。
      但是在传统的网站开发中,这些便利之处完全没有了,需要我们自己处理。在此之前,我们需要知道屏幕的分类。现如今,屏幕的尺寸越来越多了,这也意味着我们编写的前端代码需要运行在大大小小的屏幕上面。总体来说,屏幕按尺寸分为三种:小屏,中屏和大屏。这不是废话啊,是从最直观也是最重要的角度进行分类的。小屏主要就是手机屏幕了,大大小小跨度不一,但是一般来说不超过800px(大概这个数字)。中屏也就是ipad屏幕了,一般范围是800px-1280px。最后的大屏那当然就是电脑屏幕,那上限可以说是没有,但是下限起码高于1280px。根据这个粗糙的划分,我们可以基于不同的屏幕编写不同的css代码,这也就是媒体查询的步骤。
      那么问题就来了,当我们开发一个项目时,需要有一个面向的侧重点。例如是主要面对移动端,还是主要面对pc端。我做的这个项目是公司官网,主要面对的是pc端,所以我开发要以pc端为主,手机端为辅。确保主要的客户端能够得到更加完整,及时的信息。或许,你的项目同时面向手机端和pc端,这个时候往往大公司会pc端和手机端分别编写一套代码,例如淘宝手机端和pc端不同域名,不同代码。
      确定了pc端为主,那么接下来就需要阅读UI设计图了,pc端设计图上的尺寸单位是px。这个px是大小绝对的单位,不随屏幕分辨率也就是屏幕大小改变而改变。但是我们希望我们的页面在不同分辨率的屏幕上,都保持良好的布局。这样的话,固定大小的px就很不适合。比如大屏幕上面1000px的高度很适合,但是对于中屏幕就显得过长了。而这个情况,也提出了需要一种新的相对单位,可以随着分辨率的改变而改变,从而保持页面的整体布局舒适。
      解决这个问题的办法网上有好多,我最熟悉的是flexible.js方法,原理就是在每个页面引入一个flexible.js文件,这个js文件会监听窗口onresize事件,给body动态添加一个font-size属性。该属性的值,即为1rem。这样一来,我们可以使用rem代替px,做到不同屏幕,css尺寸动态变化,这也是做ipad样式适配的基础。
      但是这样新的问题又来了,px与rem的转换比例是多少,这也是曾经很困扰我的地方。这个问题的关键在于flexible.js文件中,flexible.js文件代码不多,一般都可以自己编写。但是也可以引入网上别人写的代码,在这个文件中就可以人为确定转换比例。例如1920px的屏幕,人为规定换算比例为192,那么1920px的屏幕就是10rem。基于这个比例,我们可以转化其他单位,例如800px-->800/192=4.16666rem。这样当屏幕尺寸不是1920px时,也会自动转为相应的大小。这里可以使用sublime Text的cssTorem插件快速转换单位。
      rem的使用是进行ipad适配和手机端css代码编写的基础。

    ipad适配和手机端样式

      既然已经以pc端为主要了,综合px和rem,写好了pc端页面,不同屏幕布局也没有改变,很nice。接下来就要进行ipad样式适配了,由于pc端样式宽度基本是写死的,例如1280px,这样更加宽的屏幕,增加的只是主体内容两侧的空白区,中间内容的尺寸是不变的。


    内容两侧空白区

    那么如果屏幕的尺寸小于内容区的宽度1280px,那么就需要进行样式适配了。样式适配是使用媒体查询技术的,如下图所示。

    @media screen and (maxwidth: 1280px) {
        // 样式代码
    }
    

      到了适配环节,我们需要考虑的是有的地方不需要适配,有的地方需要适配。这里需要好好思考一下,适配的目的是什么?是为了保持布局的舒适,让用户能够更舒服的浏览页面内容。对于不同分辨率上面的文字与图片,人阅读起来舒服的字号和大小是相同的,也就是说字体大小与图片大小并不完全适合于随分辨率变化而变化。例如ipad与ipad pro的屏幕大小不同,但是可以固定内容盒子的宽度与字体大小,这样反而人眼看上去更加舒服。这就引出了一个适配技巧,不是页面上所有东西都适合进行rem等适配,有的元素需要适配,例如banner的高度,有的元素不需要适配,固定尺寸反而更利于阅读。并且chrome浏览器字体的最小大小为12px,对于小于12px的字体,统统变为12px;这就解释了一个问题,在进行ipad适配的时候,把所有的固定长度替换为对应的rem,但是样式往往又是错乱。因为字体的大小,不会小于12px,通常就造成了文本内容溢出盒子。另外,我们想想,如果把font-size转换为rem,在小的屏幕中,字体反而很小不利于阅读。综上所述,一些纵向的距离和字体大小依旧使用px更为合适。
      关于高度设置,这里还有一个小技巧:如果适配不同屏幕,div高度有留白,可以试试不固定高度,让浏览器自己确定。如下图所示,文字处于下方,当使用rem替换外面盒模型的width与height时,有可能会出现小屏幕时,文字溢出。这个时候,不妨不固定高度,设置padding留白,让浏览器自己确定高度。


    image.png

      对于图片,大屏中图片尺寸单位使用px写死,媒体查询适配ipad,图片尺寸改为rem。
    手机端样式的书写,核心和ipad适配是一样的,由于DOM代码不同,所以处理起来比适配ipad要容易点,关键就是使用rem确定需要动态变化的样式尺寸。此外,主流的可以使用手淘的felxible.js,移动端样式适配更加方便和强大。

    其他学习感悟

    • 有的知识点,光想想,是很容易出错的,最糟糕的是,自己想当然的正确,这种虚假未加验证的正确欺骗了我们自己,所以需要思考与实践验证缺一不可,不要高估自己对于不了解事情的认知程度。


      image.png
    • 任何事情都有多面性,或者说我们习惯了从一个”标准“的角度看事情,一来普遍,而来没有风险。但是这样就造成了大多数人思维方式的标准化,也就变得平庸,受到了桎梏。平时多想着从不同角度看待,一个新兴事物有风险是必然的,但不能否定的是也存在的机会,不能一开始就盲目的自我夸大风险,然后理所当然的否定。这样的思考方式有意无意的避开了从机会的角度思考问题,只有正确客观认识到了机会与风险,才能更好的进行下一步决定,至于是避开还是勇往直前,那也没有什么关系。
      类比:事物就像一头大象,多从不同角度看,思考,最终目标是超脱当前局限,纵览全局,达到胸有成竹的境界。切记不可贪块,拖延,造成盲人摸象。


      大象
    • 有的东西就在眼前,却很容易被我们忽略,再次试着从两种角度思考,一种从最表面展现出来的东西,往下看,寻找被封装的细节。另一种就是就最基本的元组件开始,往上添加,封装。
    • 对于一些插件或者js库,如果一般在原生js的基础上使用,过程很简单,就是正常<script>标签引入,再按照官方文档使用流程使用。但是对于前端框架来说,使用方法就大大不同了。好比echarts,官方文档上特意给出如何在Vue中使用的介绍,点开后,里面需要下载vue-echarts包。这就引起了我很久之前的一个疑问,同样的功能库,为什么还要一些vue-等框架前缀呢?不应该都使用同一个echarts吗?现在我是明白了,这些不同的库,核心功能是相同的,不同的是面对不应用环境的对接改变。例如Vue中将DOM变化为虚拟DOM结点,这个虚拟DOM结点,原生的echarts库是不认识的,所以需要一些特殊的改变,让框架也认识这个库。这也就解答了另一个问题,那就是直接在Vue中,按照原生js使用方法使用echarts,是无效的,图表不会出现的。

    相关文章

      网友评论

          本文标题:阶段性总结

          本文链接:https://www.haomeiwen.com/subject/thaohctx.html