【答阿里寒冬面试题】呵呵，大神的面试题就是好！

前言

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

http://weibo.com/1196343093/Bhj510t50

谈谈你对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先展示

  
      
 主体 
 
 导航 
  

这里从理论上说，便是触发了siderbar元素的定位特性，其BFC与文档流不相关了

当然，这里siderbar可以使用float实现，但是float本身应该用于处理文字与图片包裹的需求，我们本着职责分离的想法就别那样干了

而且使用float还会引起元素坍塌，这里还要费劲去处理清除浮动

行内元素

行内元素的处理比较复杂，首先行内元素的高度由其line-height决定，所以不要妄想其设置一个行内元素的高度，这会引起意想不到的问题

举一个例子来说，很多大型网站都会具有统计代码，而此类统计代码一般是以img做请求发出，这个时候可能会导致10px左右的白屏问题

这个就是妄想设置行内元素高度的结果，独立的inline元素出现时，会为其创建一个line boxes作为容器（文字框）

一行文字一个line Boxes，一行高度由其中最高的行内元素确定，上例中有一个height为0的img，却为其生成了一个高度为10的行高

下面的代码中，div会被行内元素撑开，其高度会由span中line-height高者决定

  主体 导航 

移动端的建议

① 移动端的文档流渲染效率最高，应该避免大范围使用定位元素，在小米，三星等低端下定位元素可能渲染不出来（解决方案是引起回流）

② 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

  
     
 主体 导航  
   

我们看到事实上62ms后页面整体dom结构就加载好了，这个时候我们是可以使用js操作dom结构的，但这里一个重点是：

CSS外链加载会阻塞js的执行，并且重置CSS会引起浏览器的回流或者重绘，也就是：

css外链会阻塞整个页面的渲染（显示），但是其DOM结构是可操作的，中间如果有阻塞性的操作，比如alert的话会强制浏览器绘制页面

上面的特性与css外链的顺序无关，并且有几个样式相关的操作，便会执行几次，最终采用最近或者优先级最高的样式

  
     
 主体 导航  
     

一个需要注意的地方是， 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

  

      <%=title%>
  
  

    

      <%=content%>
    

      <% for(var i = 0, len = btns.length; i < len; i++ ) {%> 
 <%=btns[i].name%>
 <% } %> 
 
 

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

这里我们依旧需要强调一个前提：“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开发也只是需要一点熟悉度罢了，没有什么可说的，就此打住吧

结语

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

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