前言

今天微博看到了寒冬大神的面试题,觉得挺有意思的,这里就做一点解答

谈谈你对CSS布局的理解

讲讲输入完网址按下回车,到看到网页这个过程中发生了什么。

谈谈你对Web前端组件化的理解,Web Component会带来怎样的影响

谈谈你对前端资源下载性能优化的经验和思考

现在有很多的MV*框架,你对它们有什么看法

iOS体验好在哪里,Web能赶上么?

网页游戏怎么做?

Hybrid技术应当如何应用?

你最爱的前端框架是什么,为什么?

首先老师的题目都很大,不好答,我这里技术有缺陷,答得不好大家不要喷我,可以好好教育我嘛

浅谈CSS布局

概述

从网页表现来看,HTML是实体本身,要实现各种优雅的布局的需要依赖CSS
HTML元素两大类型为块级元素与行内元素,网页的布局一般由块级元素组织,元素不同便有不一样的表现
要实现布局就要用到与布局有关的CSS属性为position,常用属性为static、absoulute、fixed、relative
position的作用是改变元素的状态,由文档流转为相对文档流或者脱离文档流元素(定位元素)
当然float也能引发块级元素脱离文档流,但是其表现与原理与上面不一致,而且要慎用float布局
于是这里便已经有三种“流”了,不同的布局元素会处于不同的“执行环境”,在“执行环境”中才能方便的对其进行管理
这个管理的依据便是BFC(块级作用域上下文),根据我粗浅的理解是,BFC也就是浏览器提供的一块渲染区
文档流的元素处于一个渲染区,而定位元素处于另一层渲染区,float元素又会与之不同
各个渲染区中的元素具有其定位规则,最简单的便是文档流中的元素,遵循其块级元素独占一行+盒模型的规则:
① 块级元素独占一行,并且具有框(经典盒模型)
② 块级元素间由margin属性分割,并且垂直方向的margin会取其大者
③ 块级元素必定左靠这父级块级元素左边框(包含块,布局上下文)
④ float元素不能影响块级元素的BFC区域,但是其高度会参与计算
 
创建BFC的方式有:
① float
② overflow
③ display(使行内元素具有BFC)
④ position
 
基于此,我们便可以实现我们的布局了,这里以最简单的两列布局为例(左边导航,右边内容主体)
由于先出现的DOM先展示,所以内容优先原则,我们会将主体dom先展示
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title></title>
  <style>
    * { margin: 0; padding: 0; }
    div { border: 1px solid black; }
    #sidebar { position: absolute; left: 0; top: 0; width: 95px; }
    #content { margin-left: 100px; }
  </style>
  <script src="../jquery-1.7.1.js" type="text/javascript"></script>
</head>
<body>
  <div id="content">
    主体
  </div>
  <div id="sidebar">
    导航
  </div>
</body>
</html>
这里从理论上说,便是触发了siderbar元素的定位特性,其BFC与文档流不相关了
当然,这里siderbar可以使用float实现,但是float本身应该用于处理文字与图片包裹的需求,我们本着职责分离的想法就别那样干了
而且使用float还会引起元素坍塌,这里还要费劲去处理清除浮动

行内元素

行内元素的处理比较复杂,首先行内元素的高度由其line-height决定,所以不要妄想其设置一个行内元素的高度,这会引起意想不到的问题
举一个例子来说,很多大型网站都会具有统计代码,而此类统计代码一般是以img做请求发出,这个时候可能会导致10px左右的白屏问题
这个就是妄想设置行内元素高度的结果,独立的inline元素出现时,会为其创建一个line boxes作为容器(文字框)
一行文字一个line Boxes,一行高度由其中最高的行内元素确定,上例中有一个height为0的img,却为其生成了一个高度为10的行高
下面的代码中,div会被行内元素撑开,其高度会由span中line-height高者决定
<div>
  <span id="span1">主体 </span><span id="span2">导航 </span>
</div>

移动端的建议

① 移动端的文档流渲染效率最高,应该避免大范围使用定位元素,在小米,三星等低端下定位元素可能渲染不出来(解决方案是引起回流)
② img元素加载失败时候会有边框,需要搞掉
③ 慎用fixed属性,fixed对于移动端来说有点头疼,首先会有文本聚焦fixed定位错乱问题,其次在ios4的屏幕中,如果加上浏览器上下工具条,再用fixed可视区域会变得很小
④ ios是按块渲染的,布局时候可以分块,不会渲染可视区域外的内容
⑤ 动画或者border-radius、box-shadow等属性皆会使手机耗电加剧(但是这个好像与我们没关系)
⑥ fixed元素为其设置html可能不响应或者说渲染看不见,常见于ipod或者低端android
⑦ 当然能在布局上用上一些语义化标签自然是好事,这样对SEO或者特殊人事有一定帮助,比如strong、article之类的

总结

因为我本身专注点在js对css了解较少只能做此解析,请尽量拍砖指正

一次请求的完整流程

我们一次网址输入会发起一连串连锁效应,但是因为我这边对HTTP一块不是十分熟悉,只能解释自己了解的
一次URl输入后,其流程如下,首先是请求响应的流程:
1 解析URL,解析域名生成唯一IP地址,开始搜索服务器
2 找到服务器后,服务器接收请求被服务器进程拦截;一般而言,.net的程序会被IIS处理,java会被jBoss或者tomcat处理
3 服务器处理请求,如果静态文件的话直接返回,若是.net或者java等动态脚本会经过服务器编译,执行其中的服务器端代码
4 若是服务器端具有数据库操作的话,这里还需要与DB建立连接,操作数据库
5 服务器处理结束后,生成最终的静态HTML字符串返回,开始向请求者(客户端)返回请求字符串,一次返回量过大就会分批次,这是一个优化点
6 服务器响应到达浏览器,浏览器开始处理请求,进入浏览器解析流程

请求返回后,便进入了我们关注的前端模块

简单来说,浏览器会解析HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,而javascript又可以根据DOM API操作DOM
上面的文字描述的很简单,事实上发生的事情,却很复杂,这里与代码实现也很有关联,但是有几个关键点:
页面一定会等所有的HTML结构与CSS加载下来才渲染(webkit内核
比如我们这里使用fiddler限制其外链加载,我们为其限速为10s
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title></title>
  <style>
    div { border: 1px solid black; }
    a { color: Red; }
  </style>
</head>
<body>
  <div>
    <a id="span1" href="http://www.baidu.com">主体 </a><span id="span2">导航 </span>
  </div>
  <link href=" http://kb.cnblogs.com/style/common.css" rel="stylesheet" />
</body>
</html>

我们看到事实上62ms后页面整体dom结构就加载好了,这个时候我们是可以使用js操作dom结构的,但这里一个重点是:
CSS外链加载会阻塞js的执行,并且重置CSS会引起浏览器的回流或者重绘,也就是:
css外链会阻塞整个页面的渲染(显示),但是其DOM结构是可操作的,中间如果有阻塞性的操作,比如alert的话会强制浏览器绘制页面
上面的特性与css外链的顺序无关,并且有几个样式相关的操作,便会执行几次,最终采用最近或者优先级最高的样式
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title></title>
  <style>
    div { border: 1px solid black; }
    a { color: Red; }
  </style>
</head>
<body>
  <div>
    <a id="span1" href="http://www.baidu.com">主体 </a><span id="span2">导航 </span>
  </div>
  <script>
    document.getElementById(\'span2\').innerHTML = \'测试\';
    alert(1) 
  </script>
  <script>
    alert(2) 
  </script>
  <link href=" http://kb.cnblogs.com/style/common.css" rel="stylesheet" />
</body>
</html>

一个需要注意的地方是,chrome与firefox或者IE表现不一致,firefox与IE都是先渲染页面最后等段CSS下来后再次渲染
所以我们很多同学面试时说将css外链放到header中,而不是body中的理解都是一知半解,这里真实的处理办法是异步插入css外链才行
至少对于chrome需要做这个处理,否则页面就是出不来,因为多数手机是webkit内核,保不齐这里出多少事情
根据以上流程后,页面也基本出来了,这里简述其流程
① 生成DOM树
② 计算CSS样式
③ 构建render Tree
④ reflow,定位元素位置与大小
⑤ 绘制页面
上面过程如果js操作dom或者终结有一段style都会引起reflow,由于img会在文档加载结束后加载,可能会撑开页面,导致回流,所以一般需要对img设置尺寸
对于这块的优化各位自己来吧,我这里便只能理解到这个程度了
PS:事实上chrome获得请求时本身也有几个事件点,这里可以用其开发性能插件,但对前端基本透明,我们这里不关注了

MVC与组件化

这里我将2块题目合到一起了,我觉得这里可以连到一起做说明

View分离

很多程序的变革集中积累在VIEW一块的处理,原因是这里的需求是最复杂的,就View分离来说,最成功的我觉得是ASP到ASP.net的变革
最初的ASP程序,会将C#代码写在asp代码中,这样的结果便是页面里面既有html又有C#代码,甚至一个js循环中会嵌套出C#的循环
PS:你一定要相信,那个时候不会有js分成的概念,因为需求达不到
所谓的View分离便是,程序员确实受不了维护显示与逻辑同时处于一个页面的程序了,于是他选择了改变,改变的结果便是拆分
View分离一大核心思维便是,分得开,合得拢,他们这里引入一个codebehind方案将一个页面文件分成两个(事实上是三个)

① index.apsx

② index.aspx.cs

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="index.aspx.cs" Inherits="_00综合_11mvc_index" %>
public partial class _00综合_10doc_write_index : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }
}

最终这两个文件会和到一起,两个文件之间也可通信,而通信的桥梁是.net一个个被人诟病的组件,比如:

① button组件

② datalist

③ label组件

④ 伟大的gridview

各个组件在C#层面上会拥有一个ID进行约束,.cs文件便可以根据该ID为其注册各个事件,这个与javascript的模型便非常类似了

View分离的第一个优点便是,用户的界面变得干净了,不会有代码混杂的现象,第二个优点便是业务端的代码可以再分离,从而多了数据层、业务层等各个概念

而组件的出现让.net变成了世界上开发最快的语言,这点谁也不可否认,而这些都是前端MVC出现或者组件出现的意义

前端View分离

与asp当初的情况一致,js进行dom操作或者字符串拼接的目的事实上就是想形成一个可供展示的View,前端jser已经再也不能忍受这种代码了:

很多时候,我们想将对应的模板单独的放到一个地方,每次样式若是有更改,只需要更改那个文件即可,只要与之呼应的“ID”不丢失即可,比如这样的结构和代码:

View Code
<div class="cui-pop-box">
  <div class="cui-hd">
      <%=title%>
  </div>
  <div class="cui-bd">
    <div class="cui-error-tips">
      <%=content%></div>
    <div class="cui-roller-btns">
      <% for(var i = 0, len = btns.length; i < len; i++ ) {%>
      <div class="cui-flexbd <%=btns[i].className%>">
        <%=btns[i].name%></div>
      <% } %>
    </div>
  </div>
</div>

这样做的道理是,这个样子做到了表现与行为分离,我们分得开,然后回根据基类的一个机制,让他们最终合到一块,以完成功能

这里我们依旧需要强调一个前提:“ID”关联不可丢失,否则“行为”将不可表现,只要两者间关联不丢,这里便可轻松满足以下逻辑:

① CSS名修改(非标识性CSS名)

② 标签改变

③ 描述性文字改变

……

MVC在前端

重构一书有说,重复性或者类似重复性的代码应该抽象为一个方法,程序员也不傻,在重复使用需要提示框需求后便会学会形成alert组件

组件的出现是代码抽象,代码重用的标识,这个样子既可以减少工作量也可以减少代码容量,而组件的实现与MVC思维的很好诠释

比如以下代码:

View Code

事实上,MVC的任意一块都可以作为单独的模块实现,比如会有这样的需求:一个model实例的变化会影响两个View的显示,但是仅仅对UI一块来说我们做了如下处理:

核心点变成了几个属性:

① template,根据他生成UI

② datamodel,根据他生成viewModel提供给template使用

③ eventArr,业务事件注册点

这个代码是Blade框架的UI基类,他是一个迷你MVC框架

 1     propertys: function () {
 2       //模板状态
 3       this.template = \'\';
 4       this.datamodel = {};
 5       this.events = {};
 6       this.wrapper = $(\'body\');
 7       this.id = _.uniqueId(\'ui-view-\');
 8 
 9       //自定义事件
10       //此处需要注意mask 绑定事件前后问题,考虑scroll.radio插件类型的mask应用,考虑组件通信
11       this.eventArr = {};
12 
13       //初始状态为实例化
14       this.status = \'init\';
15 
16       //      this.availableFn = function () { }
17 
18     },

template作为View的实现,datamodel作为model实现,我们会根据datamodel与template生成基本的view实体

这里datamodel与template之间会有一个viewModel的映射关系,是为了防止服务器端突然将title变成Title而导致模板解析错误

而整个文件便是一个控制器,view有的事件行为采用javascript委托技术全部注册在根元素上,如此整个UI就活了,他的好处是:

① 具有继承关系,可以拥有统一的资源释放,或者View通信机制

② 代码量也会减少

MVC与组件化的意义

MVC对前端的意义甚大,因为jser对MVC或者分模块的思维的深入理解,我们才会将前端代码做分离,这样会有效的避免多人更改一个文件的难题

这对前端的推动作用不可谓不大!

组件化是对重复工作,重复代码的降低,当然是好东西……

资源加载

前端优化的瓶颈始终在资源加载,只要加载快,无论你代码写的多慢(不要纠结死循环),都一定快,所以前端优化事实上一直都是一个主题:瘦身

压缩

css sprite

延迟加载(主要针对图片)

按需加载(主要针对首屏未用到的UI)

缓存

CDN

预加载

等词语不断的在前端出现,但是一个不可避免的事实是,需求越发复杂,体验要求越高,所以一个前端可能的事实是:

前端资源体积越来越大,避免此事发生不是前端说了算的,需要产品与交互一起努力,清晰、体验好、轻量级的设计谁不喜欢,但是广告营销也不能不考虑,总之此事路还长!

webapp的资源加载

对于webapp来说,首次加载的体积会更加大,因为其要求的库更多,并且网速更慢,这个时候可以采取fake页的方案

我们应该避免页面长时间白页,这个时候便提出了fake页的概念。页面渲染只需要完整的HTML以及CSS,这个便是第一个优化点。

从数据请求数以及请求量来说,webapp首页的响应应该比较慢,若是任由js加载完成再渲染页面,用户很有可能失去耐心。

但是从DOMContentLoaded来看,首页事实上页面响应比较迅速,所以这个加载结束后页面第一屏便渲染结束,然后再异步加载js,当js改变后再动态改变dom结构中的一些关键点

这个时候一个静态HTML页面,装载首屏的基本内容,让首页快速显示

然后js加载结束后会马上重新渲染整个页面,这个样子,用户就可以很快的看到页面响应,给用户一个快的错觉,给人感觉快得多。

是否按需加载

按需加载的话确实会对首屏加载有好处,但是是否按需加载却不一定了,以下面两个体验为例:

资源完全加载

http://yexiaochai.github.io/blade/demo/dest.html

按需加载

http://yexiaochai.github.io/blade/demo/debug.html

PS:我这里debug版本点击时候未做mask处理,大家不要疯狂点击了

这里各位直观的感受是什么呢?是不是,首次加载后后续操作十分流畅,而按需加载的话,每次皆会感觉有点“卡”

按需加载需要加载js和模板,这个过程自然卡,所以真正是不是要按需加载,或者多少资源按需加载有个临界值,需要不断的测试才行

最后,要减少资源的话,代码的质量神马的也需要考虑的,但对容量来说效用可能不是太大

IOS的体验

IOS的体验好,主要好在两点:

① 清晰、简洁、傻瓜化设计,连我妈都可以轻巧的操作苹果手机其简易型可想而知

② 用户行为模拟,IOS体验第二点便是其无敌的动画效果

若是说web应用想赶上(寒冬老师这里赶上一词用得十分贴切,他要说超过估计没人理他了)native开发的话还是有可能

但是如果说web应用要赶上IOS的设计的话,那么还有无数荆棘需要踩过!并且有两大前提:

① 网速快,用户不必关心资源大

② 手机性能好,不说超越PC,至少能“赶上”PC吧

以上两点成立的话,web应用赶上IOS体验才变得可能,简单来说就动画而言,前端有哪些问题呢?

webapp中的动画

webapp的一大优势便是在view切换时候可以拥有媲美与native的动画效果,但是很多时候那只是一种想法,真正的情况却不是这样
产生此问题的原因有:
① 手机CPU烂!
② 手机显卡烂!就算四核其渲染也很有问题
③ 高端手机浏览器会有BUG
④ 低端手机支持不好(国内山寨机笑而不语)
因为以上原因,事实上做webapp的都会不同程度的弱化动画,或者在局部区域使用动画

难在何处?

dom树过多
view的移动与简单的图片slider组件相差甚剧!原因便是其dom结构可能很复杂,大dom树的移动在移动端效果很差
就简单列表页来说,当项目超过100个时,使用IScroll类插件都应该很慎重,这类移动可能非常卡!
而且dom树复杂度与业务直接相关,我们没有任何办法去控制dom树,因为业务代码可能不会经过我们的手,就算经过,你又肯定自己做出来的dom树有多小?不见得吧
长短页问题
所谓长短页便是一个view很长一个view很短,这里问题处理十分讨厌
首先我们每次做切换需要将view位置切换至头部(window.scroll(0, 0))如此的话ios中会引起
页面viewport的变化(系统自动发生),或者会触发低端工具栏的出现,这个时候页面抖动无可避免
若是每次不执行window.scroll(0, 0),切换时候又会导致短的view不可见
我现阶段想到的解决方案是,移动时候将scroll设得比较大,移动时候将bview的top值与scrollTop相同
最后仍然需要执行window.scroll(0, 0)的操作,所以,这个问题只能缓解,无法解决
手机渲染问题
只要是做移动端的朋友,一定会对三星机或者一些低端机的渲染嗤之以鼻!
具体表现为多次操作style后,后面的操作浏览器不会搭理你
解决方案是:
① 引起浏览器强烈重绘
② 临时增删一个dom结构
但是涉及view切换动画的话,很有可能会出现一些莫名其妙的问题!

所以单单由简单的webapp的切换都如此困难,web应用想赶上IOS的话还要等几年……

Hybrid对前端的意义

应该说Ajax带动了前端的首次革命,而移动端带来了二次革命,而Hybrid将前端推上了风口浪尖!

原来我厂app是使用native开发的,会出现此等问题:一个应用需要养3个团队(ios、android、winphone),而且一旦业务改变会让开发抓狂!

而Hybrid的出现解决了此问题,一套前端代码可以用于四个地方:浏览器、ios、android、winphone,而这个却是互联网公司最需要的

最近两年,移动大潮袭来,各个公司皆在抢占移动端的份额,谁赢了这场战斗谁就是下一代王者,所以出现了一个事实:

市场的占领、业务的扩展是第一位!

所以Hybrid的市场与需求比native大,但是这不是说native没用了,因为更好的体验我们的追求,所以在Hybrid占领市场结束后,可能需要改版为native

除非那时前端的体验能缩小与native的距离

Hybrid开发的问题

Hybrid提高了前端开发的门槛,因为Hybrid的调试难,但是业内也出现了一些调试的方案,我这里有一套Hybrid调试的技巧,有兴趣可以交流

Hybrid 兼容BUG多,总所周知,H5站点上看着好好的程序,一旦到了webview上就出问题了,这个调试也很痛苦

哎,其实Hybrid开发也只是需要一点熟悉度罢了,没有什么可说的,就此打住吧

结语

寒冬老师喜欢出题,我喜欢答题,其中几道题我这里没有什么概念就交白卷了,不知道我的回答是否可以及格

若是寒冬老师或者各位觉得我的回答能勉强及格,左边微博求粉!!!尼玛我粉丝太少了!!!

版权声明:本文为yexiaochai原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/yexiaochai/p/3899974.html