h5面试题

一.匿名函数实现阶乘
第一种写法：

43 > F = fun(Func, 1) -> 1;
43 > (Func, N) -> N * Func(Func, N - 1) end.
#Fun < erl_eval.12.99386804 >
44 > F(F, 1).
1
45 > F(F, 2).
2
46 > F(F, 5).
120

第二种写法：

52 > F = fun
52 > Fac(1) -> 1;
52 > Fac(N) -> N * Fac(N - 1) end.
#Fun < erl_eval.30.99386804 >
53 > F(5).
120
//--------------------------
function n(x) {
if (x < 2) {
return 1;
} else {
return x * n(x - 1);
}
}
//调用函数
alert(n(10))

二.js类与初始化
var Animate = function (dom) {
this.dom = dom;
this.startTime = 0;
this.startPos = 0;
this.endPos = 0;
this.propertyName = null;
this.easing = null;
this.duration = null;
}
三. let和const的区别
let与const都是只在声明所在的块级做用域内有效。
let声明的变量能够改变,值和类型均可以改变,没有限制.
const声明的变量不得改变值,这意味着,const一旦声明,就必须当即初始化,不能留到之后赋值.

四.优化图片加载的方法
1.懒加载
2.在页面载入的时候将页面上的img标签的src指向一个小图片,把真实地址存放在一个自定义属性中,能够data-src
若是为幻灯片、相册等，可使用图片预加载技术，将当前展现图片的前一张和后一张优先下载。
预加载，见下一章节
3.　若是图片为css图片，可使用CSSsprite，SVGsprite，Iconfont、Base64等技术。

4.　若是图片过大，可使用特殊编码的图片，加载时会先加载一张压缩的特别厉害的缩略图，以提升用户体验。

5.　若是图片展现区域小于图片的真实大小，则因在服务器端根据业务须要先行进行图片压缩，图片压缩后大小与展现一致。

五.html5新特性
1.标签语义化 如:hrader,footer nav section article aside detailes summary dialog
2.加强型表单 如:color date datetime datetime-local email month number range search tel time url week
3.视频和音屏 如:audio video
4.Canvas绘图 如:Canvas - 图形 Canvas - 路径 Canvas - 文本 Canvas - 渐变 Canvas - 图像 SVG 与 Canvas二者间的区别:
SVG 是一种使用 XML 描述 2D 图形的语言。Canvas 经过 JavaScript 来绘制 2D 图形。SVG 基于 XML，这意味着 SVG DOM 中的每一个元素都是可用的。您能够为某个元素附加 JavaScript 事件处理器。
在 SVG 中，每一个被绘制的图形均被视为对象。若是 SVG 对象的属性发生变化，那么浏览器可以自动重现图形。Canvas 是逐像素进行渲染的。在 canvas 中，一旦图形被绘制完成，它就不会继续获得浏览器的关注。
若是其位置发生变化，那么整个场景也须要从新绘制，包括任何或许已被图形覆盖的对象.

六.浏览器缓存

1、http缓存
1.http缓存是基于HTTP协议的浏览器文件级缓存机制。
即针对文件的重复请求状况下，浏览器能够根据协议头判断从服务器端请求文件仍是从本地读取文件，
chrome控制台下的Frames即展现的是浏览器的http文件级缓存
2.websql
websql这种方式只有较新的chrome浏览器支持，并以一个独立规范形式出现，主要有如下特色
Web Sql 数据库API 实际上不是HTML5规范的组成部分；
在HTML5以前就已经存在了，是单独的规范；
它是将数据以数据库的形式存储在客户端，根据需求去读取；
跟Storage的区别是： Storage和Cookie都是以键值对的形式存在的；
3.openDatabase方法能够打开已经存在的数据库，不存在则建立
var db = openDatabase('mydatabase', '2.0', my db', 2 * 1024);
openDatabasek中五个参数分别为：数据库名、版本号、描述、数据库大小
建立回调。建立回调没有也能够建立数据库。
4.indexDB
IndexedDB 是一个为了可以在客户端存储可观数量的结构化数据，
而且在这些数据上使用索引进行高性能检索的 API。
虽然 DOM 存储 对于存储少许数据是很是有用的，
可是它对大量结构化数据的存储就显得力不从心了。
IndexedDB 则提供了这样的一个解决方案。
IndexedDB 分别为同步和异步访问提供了单独的 API 。
同步 API 原本是要用于仅供 Web Workers 内部使用，
可是尚未被任何浏览器所实现。异步 API 在 Web Workers 内部和外部均可以使用，
另外浏览器可能对indexDB有50M大小的限制，
通常用户保存大量用户数据并要求数据之间有搜索须要的场景。
5.cookie
Cookie（或者Cookies），指通常网站为了辨别用户身份、
进行session跟踪而储存在用户本地终端上的数据（一般通过加密）。
cookie通常经过http请求中在头部一块儿发送到服务器端。
一条cookie记录主要由键、值、域、过时时间、大小组成，通常用户保存用户的认证信息。
支持域名个数:
IE7以上
50个
4095B

Firefox
50个
4097B

Opera
30个
4096B

Safari/WebKit
无限制
4097B

6.localstorage
localStorage是html5的一种新的本地缓存方案，
目前用的比较多，通常用来存储ajax返回的数据，加快下次页面打开时的渲染速度。

7.sessionstorage
sessionStorage和localstorage相似，
可是浏览器关闭则会所有删除，api和localstorage相同，实际项目中使用较少。

8.application cache
application cahce是将大部分图片资源、js、css等静态资源放在manifest文件配置中。
当页面打开时经过manifest文件来读取本地文件或是请求服务器文件。
离线访问对基于网络的应用而言愈来愈重要。
虽然全部浏览器都有缓存机制，但它们并不可靠，
也不必定总能起到预期的做用。HTML5 使用ApplicationCache
接口能够解决由离线带来的部分难题。前提是你须要访问的web页面至少被在线访问过一次。
使用缓存接口可为您的应用带来如下三个优点：
离线浏览 – 用户可在离线时浏览您的完整网站
速度 – 缓存资源为本地资源，所以加载速度较快。
服务器负载更少 – 浏览器只会从发生了更改的服务器下载资源。

9. flash缓存
这种方式基本不用，
这一方法主要基于flash有读写浏览器端本地目录的功能，
同时也能够向js提供调用的api，
则页面能够经过js调用flash去读写特定的磁盘目录，达到本地数据缓存的目的。

七.服务器主动推送信息到客户端方式
1.Ajax轮询所谓的Ajax轮询，其实就是定时的经过Ajax查询服务端，
客户端按规定时间定时像服务端发送ajax请求，
服务器接到请求后立刻返回响应信息并关闭链接。
这种技术方式实现起来很是简单，
可是这种方式会有很是严重的问题，
就是须要不断的向服务器发送消息询问，
这种方式会对服务器形成极大的性能浪费。

2.Comet Comet，基于 HTTP 长链接的 "服务器推" 技术，
能使服务器端主动以异步的方式向客户端程序推送数据，
而不须要客户端显式的发出请求，目前有两种实现方式：

1. 基于 AJAX 的长轮询（long-polling）方式
2.基于 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一种 HTML 标记， 经过在 HTML 页面里嵌入一个隐蔵帧，
而后将这个隐蔵帧的 SRC 属性设为对一个长链接的请求，
服务器端就能源源不断地往客户端输入数据。
Comet实现框架:
CometD 目前实现 Comet 比较成熟， DWR 弱一些。
ICEfaces 更商业化，实现得很成熟。
Grizzly 是基于GlassFish ，也很成熟。CometD, DWR 开源性好。

3.websocket方式
WebSocket是HTML5开始提供的一种在单个 TCP 链接上进行全双工通信的协议。
WebSocket通信协议于2011年被IETF定为标准RFC 6455，WebSocketAPI被W3C定为标准。
在WebSocket API中，浏览器和服务器只须要作一个握手的动做，
而后，浏览器和服务器之间就造成了一条快速通道。二者之间就直接能够数据互相传送。

八.git工做流程

1.分布式工做流程
同传统的集中式版本控制系统（CVCS）不一样，
Git 的分布式特性使得开发者间的协做变得更加灵活多样。
在集中式系统中，每一个开发者就像是链接在集线器上的节点，
彼此的工做方式大致相像。
而在 Git 中，每一个开发者同时扮演着节点和集线器的角色——也就是说，
每一个开发者既能够将本身的代码贡献到其余的仓库中，同时也能维护本身的公开仓库，
让其余人能够在其基础上工做并贡献代码。
由此，Git 的分布式协做能够为你的项目和团队衍生出种种不一样的工做流程，
接下来的章节会介绍几种利用了 Git 的这种灵活性的常见应用方式。
咱们将讨论每种方式的优势以及可能的缺点；你能够选择使用其中的某一种，
或者将它们的特性混合搭配使用。

2.集中式工做流
集中式系统中一般使用的是单点协做模型——集中式工做流。
一个中心集线器，或者说仓库，能够接受代码，
全部人将本身的工做与之同步。 若干个开发者则做为节点——也就是中心仓库的消费者——而且与其进行同步。
集成管理者工做流:
(1).项目维护者推送到主仓库。

(2).贡献者克隆此仓库，作出修改。

(3).贡献者将数据推送到本身的公开仓库。

(4).贡献者给维护者发送邮件，请求拉取本身的更新。

(5).维护者在本身本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。

(6).维护者将合并后的修改推送到主仓库。

3.司令官与副官工做流
这实际上是多仓库工做流程的变种。
通常拥有数百位协做开发者的超大型项目才会用到这样的工做方式，例如著名的 Linux 内核项目。
被称为副官（lieutenant）的各个集成管理者分别负责集成项目中的特定部分。
全部这些副官头上还有一位称为司令官（dictator）的总集成管理者负责统筹。 司令官维护的仓库做为参考仓库，
为全部协做者提供他们须要拉取的项目代码。 整个流程看起来是这样的(见 司令官与副官工做流。):
(1).普通开发者在本身的特性分支上工做，并根据 master 分支进行变基。 这里是司令官的`master`分支。

(2).副官将普通开发者的特性分支合并到本身的 master 分支中。

(3).司令官将全部副官的 master 分支并入本身的 master 分支中。

(4).司令官将集成后的 master 分支推送到参考仓库中，以便全部其余开发者以此为基础进行变基。Figure 56. 司令官与副官工做流。这种工做流程并不经常使用，只有当项目极为庞杂，或者须要多级别管理时，才会体现出优点。 利用这种方式，项目总负责人（即司令官）能够把大量分散的集成工做委托给不一样的小组负责人分别处理，而后在不一样时刻将大块的代码子集统筹起来，用于以后的整合