前言

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

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先展示

<!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开发也只是需要一点熟悉度罢了，没有什么可说的，就此打住吧

结语

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

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

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

python实习生面试题_大数据分析实习生面试题库
原标题:大数据分析实习生面试题库大数据分析是一个有吸引力的领域,因为它不仅有利可图,而且您有机会从事有趣的项目,而且您总是在学习新事物.如果您想从头开始,请查看大数据分析实习生面试题库以准备面试要点 ...
Android面试题整理（源自鸿洋大神公众号【201803】的一篇BAT面试题推送）
三月,想必各位程序员GG 此刻想要的,莫过于一篇面试宝典.鄙人不才,也从未系统的刷过面试题,以鸿洋大哥一篇面试题为引,略加整理,希望能帮到各位不知道看什么小伙伴.(大部分知识都是有答案的). 原文链接 ...
阿里P8架构大神分享纯手写“kafka文档”看完直呼太牛！
什么是 Kafka Kafka 是由 Linkedin 公司开发的,它是一个分布式的,支持多分区.多副本,基于 Zookeeper 的分布式消息流平台,它同时也是一款开源的基于发布订阅模式的消息引擎系 ...
赠票 | 面见AI大神贾扬清！阿里云峰会船票抢先送～（上海站）
7月24日,阿里云峰会 · 上海开发者大会将在上海世博中心盛大启程,与未来世界的开发者们分享开源大数据.IT 基础设施云化.数据库.云原生.物联网等领域的技术干货. 本次开源大数据专场重磅邀请 AI ...
阿里大神的刷题笔记.pdf
今天在浏览 Github 的时候,发现了一个让人眼前一亮的项目,一本厚厚的算法刷题笔记,来自一位阿里的资深技术大神. 作者在大学期间参加过三年的 ACM 比赛,对算法有着较为透彻的了解,在找工作之前, ...
阿里技术大神：你没做错啥，你错在啥都没做
难受,那是因为你正在爬坡,正在成长你有没有想过,如果你现在做的工作,能看到你10年后的样子,你愿意吗? 领着固定薪水,做着熟练到形成肌肉记忆的事情. 有一天,在舒适区里呆得太久,想跳出来,发现已经没 ...
通往大神之路，百度Java面试题前200页。
转载自通往大神之路,百度Java面试题前200页. 基本概念操作系统中 heap 和 stack 的区别什么是基于注解的切面实现什么是对象/关系映射集成模块什么是 Java 的反射机制 ...
关于SDN的未来，Linux基金会专访阿里云网络大神
摘要: 近日,大家熟知的国际开源组织Linux基金会与阿里云进行了一次访谈.专访了阿里云网络团队掌门人江鹤.江鹤执掌阿里云网络产品线,并负责阿里集团网络虚拟化产品的研发管理工作.在软件定义网络(SDN ...
java 2017腾讯面试题_腾讯2017刁难面试题，是不是大神就看你会做几题
原标题:腾讯2017刁难面试题,是不是大神就看你会做几题一.今日头条2017笔试题(决策问题) 现在有两堆石子,小今与小条玩游戏,2个人都足够聪明,两个人规定:每次每人只能从其中一堆中取走1个或2个 ...

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

前言