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. 司令官與副官工做流。這種工做流程並不經常使用，只有當項目極爲龐雜，或者須要多級別管理時，纔會體現出優點。 利用這種方式，項目總負責人（即司令官）能夠把大量分散的集成工做委託給不一樣的小組負責人分別處理，而後在不一樣時刻將大塊的代碼子集統籌起來，用於以後的整合