前端試題綜合（二）

時間 2019-11-13

標籤前端試題綜合简体版

原文原文鏈接

談談你對Socket編程的理解及實現原理，Socket 之間是怎麼通信的

A、Socket定義javascript

Socket是進程通信的一種方式，即調用這個網絡庫的一些API函數實現分佈在不一樣主機的相關進程之間的數據交換。幾個定義：IP地址：即依照TCP/IP協議分配給本地主機的網絡地址，兩個進程要通信，任一進程首先要知道通信對方的位置，即對方的IP。端口號：用來辨別本地通信進程，一個本地的進程在通信時均會佔用一個端口號，不一樣的進程端口號不一樣，所以在通信前必需要分配一個沒有被訪問的端口號。鏈接：指兩個進程間的通信鏈路。php

B、實現原理css

在TCP/IP網絡應用中，通訊的兩個進程間相互做用的主要模式是客戶/服務器（Client/ Server, C/S)模式，即客戶向服務器發出服務請求，服務器接收到請求後，提供相應的服務。客戶/服務器模式的創建基於如下兩點：首先，創建網絡的原由是網絡中軟硬件資源、運算能力和信息不均等，須要共享，從而造就擁有衆多資源的主機提供服務，資源較少的客戶請求服務這一非對等做用。其次，網間進程通訊徹底是異步的，相互通訊的進程間既不存在父子關係，又不共享內存緩衝區，所以須要一種機制爲但願通訊的進程間創建聯繫，爲二者的數據交換提供同步，這就是基於客戶/服務器模式的TCP/IP。html

C、通信過程前端

服務器端：其過程是首先服務器方要先啓動，並根據請求提供相應服務：（1)打開一通訊通道並告知本地主機，它願意在某一公認地址上的某端□(如FTP的端口可能爲21)接收客戶請求；（2)等待客戶請求到達該端口；（3)接收到客戶端的服務請求時，處理該請求並發送應答信號。接收到併發服務請求，要激活一新進程來處理這個客戶請求（如UNIX系統中用fork、exec)。新進程處理此客戶請求，並不須要對其它請求做出應答。服務完成後，關閉此新進程與客戶的通訊鏈路，並終止。（4)返回第（2)步，等待另外一客戶請求。（5）關閉服務器客戶端：（1)打開一通訊通道，並鏈接到服務器所在主機的特定端口；(2)向服務器發服務請求報文，等待並接收應答；繼續提出請求......（3)請求結束後關閉通訊通道並終止。vue

從上面所描述過程可知：（1）客戶與服務器進程的做用是非對稱的，因此代碼不一樣。（2）服務器進程通常是先啓動的。只要系統運行，該服務進程一直存在，直到正常或強迫終止。java

詳細參見：node

https://www.zhihu.com/question/29637351react

http://blog.csdn.net/panker2008/article/details/46502783?ref=myreadjquery

WEB應用從服務器主動推送Data到客戶端有哪些方式？

大家原來公司如何發送的新消息推送?

通常的服務器Push技術包括：

1) 基於AJAX的長輪詢（long一polling)方式，服務器Hold—段時間後再返回信息；

2) HTTP Streaming,經過iframe和〈script〉#簽完成數據的傳輸；

3) TCP長鏈接

4) HTML5新引入的WebSocket，能夠實現服務器主動發送數據至網頁端，它和HTTP— 樣，是一個基於HTTP的應用層協議，跑的是TCP，因此本質上仍是個長鏈接，雙向通訊，意味着服務器端和客戶端能夠同時發送並響應請求，而再也不像HTTP的請求和響應。

5) nodejs的http://socket.io，它是websocket的一^^開源實現，對不支持websocket的瀏覽器降級成comet / ajax輪詢，http://socket.io的良好封裝使代碼編寫很是容易。

上述的 1 和2統稱爲comet技術。comet詳細參考：http://www.ibm.com/developerworks/cn/ web/wa一lo一comet/

上述的1和2統稱爲comet技術，Comet：基於 HTTP 長鏈接的「服務器推」技術前些日子給項目網站加了後臺通知的實時推送到前端顯示，用的是nodejs的http://socket.io，它是websocket的一個開源實現，對不支持websocket的瀏覽器降級成comet / ajax 輪詢，http://socket.io的良好封裝使代碼編寫很是容易。

組件設計

設計一個彈框組件，組件寬度爲屏幕高度的50%，寬度爲屏幕寬度的80%，水平垂直居中。彈窗組件有 header, body, footer三部分，header中有標題，可定製，body區域，footer區域有肯定和取消按鈕，可定製兩個按鈕的文字內容，組件外的內容有遮罩，點擊遮罩和取消按鈕時關閉彈框，參照下圖。（相似於layer的彈出層插件）

使用面向對象封裝插件較爲合適

構造函數的參數有header的標題及body內容和按鈕文字內容

封裝的方法應該有show, hide,在點擊遮罩和取消按鈕時調用hide方法

而且hide和show方法應該有返回值以供判斷。

實現一個手勢滑動輪播圖組件。效果參考：https://static.xiaohongchun.com/goods/4514 (請在手機裏打開）

詳細參考：http://www.jb51.net/article/65177.htm

設計基於觀察者模式的事件綁定機制

觀察者模式（發佈-訂閱模式）的定義：Observer的意圖是定義對象之間的一種一（被觀察者）對多（觀察者）的關係，當一個對象的狀態發生改變時，全部依賴它的對象獲得通知，而且會自動更新本身

在JavaScript中，通常使用事件模型來替代傳統的觀察者模式。

好處：

（1）可普遍應用於異步編程中，是一種替代傳遞迴調函數的方案。

（2）可取代對象之間硬編碼的通知機制，一個對象不用再顯示地調用另一個對象的某個接口。兩對象輕鬆解耦。

代碼參考：http://blog.csdn.net/phker/article/details/6880371

http://www.cnblogs.com/LuckyWi nty/p/5796190.html

jq本身擴展過什麼插件？

彈出層插件、pagination插件、瀑布流插件、模態框插件等

參考：Jquery插件庫 jquery之家

埋點

在須要埋點的組件上添加自定義屬性，裏面放上惟一的值。當用戶點擊時發送ajax。

或者
append(img)
img.src="blank.png?id=10010"

側滑菜單如何實現？

主要依靠兩個大的容器來模擬側滑菜單界面和主界面，把側滑菜單放到頁面右側看不到的地方，在操做的同時，使用css3過渡、動畫或者jq來使兩個容器相對運動，實現側滑菜單效果

參考：http://www.111cn.net/wy/js一ajax/99687.htm

權限管理如何實現？

（1）前端控制：

　　前端的控制比較簡單，從後臺獲取到用戶的權限以後，能夠存在session或者cookie中，而後在頁面加載的時候，經過session或者cookie中存的權限來選擇讓該功能展示或者禁用。

前端實現代碼詳細參見：http://blog.csdn.net/liuweidagege/article/details/42497731

（2）後臺控制：

　　僅僅依靠前端的控制是沒法完美解決權限控制的問題，由於前端頁面的加載過程是在瀏覽器中完成的，用戶能夠自行篡改頁面；或者用戶能夠直接經過URI請求來獲取非法權限功能。因此須要在後臺實現權限控制。

　　後臺的控制方法也不少，好比filter、spring的AOP等。在此選用springMVC的interceptor來控制。

（3）全局異常管理：

　　思路是在攔截器中權限校驗失敗時，拋出一個權限校驗失敗的異常，而後經過全局異常管理類來捕獲並返回前端特定的格式。具體以下。

—個大數組，可能存了 100萬個數字，要從其中取出來第二大的數的下標，有什麼快速的方法？

用兩個變量max，max2，其中max儲存最大值，max2儲存第二大值；初始化的時候，將數組中的第一個元素中較大的存進max中，較小的存進max2中，而後從第三個元素(下標爲2)的元素開始，若是遇到的數比max大，就讓max2=max;max等於遇到的數一直循環，直到數組尾部，最後輸出max2

請設計一套方案，用於確保頁面中js加載徹底，對於優化某網頁的加載速度，有什麼獨到看法js方法：

<script type="text/javascript">

window.onload=function(){ var userName="xiaoming"; alert(userName); } </script>

jquery方法：

View Code

如何肯定一個js是否加載徹底或者頁面中的全部js加載徹底，具體辦法以下：

View Code

如何讓腳本的執行順序按照你設定的順序執行，使用嵌套的方式：

loadScript("file1.js", function() {

    loadScript("file2.js", function() { loadScript("file3.js", function() { alert("All files are loaded"); }); }); });

網頁加載速度優化：

一、減小請求

最大的性能漏洞就是一個頁面須要發起幾十個網絡請求來獲取諸如樣式表、腳本或者圖片這樣的資源，這個在相對低帶寬和高延遲的移動設備鏈接上來講影響更嚴重。

CDNs（內容分發網絡）把資源放在離用戶地理位置更近的地方對解決這個問題能起到很大做用，可是比起獲取請求，大量的請求對頁面加載時間的影響更爲嚴重，並且最近的發現代表，CDNs對移動端用戶的性能影響愈來愈低。

二、整合資源

對開發者來講，將Javascript代碼和CSS樣式放到公共的文件中供多個頁面共享是一種標準的優化方法，這個方法能很簡單的維護代碼，而且提升客戶端緩存的使用效率。

在Javascript文件中，要確保在一個頁面中相同的腳本不會被加載屢次，當大團隊或者多個團隊合做開發的時候，這種冗餘的腳本就很容易出現，你可能會對它的發生頻率並不低感到很是吃驚。

Sprites是css中處理圖片的一項技術，Sprites就是將多張圖片整合到一個線性的網狀的大圖片中，頁面就能夠將這個大圖片一次性獲取回來而且作爲css的背景圖，而後使用css的背景定位屬性展現頁面須要的圖片部分，這種技術將多個請求整合成一個，能顯著地改善性能。

平穩地改進可是須要對資源有控制權限，根據開發者的網站不一樣權限，一些資源並不須要被整合起來（例如，一些由CMS生成的資源），還有，對於一些外部域引用的資源，強行整合可能會致使問題，馬海祥提醒你們須要注意的是，整合資源對手機瀏覽器來講是一把雙刃劍，整合資源確實會在首次訪問減小請求，可是大的資源文件可能會致使緩存失效，因此，須要當心地使用各類技術整合資源，以達到優化本地存儲的目的。

三、使用瀏覽器緩存和本地緩存

如今全部的瀏覽器都會使用本地資源去緩存住那些被Cache一Control或者Expires頭標記的資源，這些頭能標記資源須要緩存的時間，另外，ETag（實體標籤）和Last一Modified頭來標識當資源過時後是否須要從新請求，瀏覽器爲了減小沒必要要的服務器請求，儘量地從本地緩存中獲取資源，而且將那些已通過期的、或者當緩存空間減少的時候將那些好久不用的資源進行清理，瀏覽器緩存一般包括圖片，CSS，Javascript代碼，這些緩存能合理地提升網站的性能（好比爲了支持後退和前進的按鈕，使用一個單獨的緩存來保存整個渲染的頁面）。

移動瀏覽器緩存，一般是比桌面PC小的多，這就致使了緩存的數據會很常常被清理，HTML5的緩存基於瀏覽器緩存提供了一個很好的替換方案，Javascript的localStorage已經在全部主流的桌面和移動端瀏覽器上都實現了，使用腳本代碼能簡便地支持HTML5的localStorage操做，能夠讀寫鍵值數據，每一個域名大概有5MB的容量，雖然不一樣的移動瀏覽器上讀寫速度相差很大，可是localStorage大容量的緩存使得它很適合做爲客戶端的緩存，從localStorage獲取資源明顯快於從服務器上獲取資源，並且在大多數移動設備上也比依靠緩存頭或者瀏覽器的本地緩存更靈活可靠，這是移動瀏覽器比桌面PC更有優點的一個地方，在桌面PC上，本地緩存仍然優先使用標準的瀏覽器緩存，致使桌面PC本地緩存的性能落後於移動瀏覽器。

在此，馬海祥要提醒各位一下：雖然localStorage的機制易於實現，可是它的一些控制機制倒是很是複雜的，你須要考慮到緩存帶給你的全部問題，好比緩存失效（何時須要刪除緩存？），緩存丟失（當你但願數據在緩存中的時候它並不在怎麼辦？），還有當緩存滿的時候你怎麼辦？

四、首次使用的時候在HTML中嵌入資源

HTML的標準是使用連接來加載外部資源，這使得更容易在服務器上（或者在CDN上）操做更新這些資源，而不是在每一個頁面上修改更新這些資源，根據上文討論的，這種模式也使得瀏覽器能從本地緩存而不是服務器上獲取資源。

可是對尚未緩存到瀏覽器localStorage的資源來講，這種模式對網站的性能有負面的影響，通常來講，一個頁面須要幾十個單獨的請求來獲取資源從而渲染頁面。

因此說，從性能的角度來講，若是一個資源沒有很高的被緩存的概率的話，最好把它嵌入到頁面的HTML中（叫inlining），而不是使用連接外部，腳本和樣式是支持內嵌到HTML中的，可是圖片和其餘的二進制資源其實也是能夠經過內嵌包含base64編碼的文原本嵌入到HTML中的。

內嵌的缺點是頁面的大小會變得很是大，因此對於Web應用來講，關鍵的是可以跟蹤分析這個資源何時須要從服務端獲取，何時已經緩存到客戶端了。

另外，在第一次請求資源後必須可以使用代碼在客戶端緩存資源，所以，在移動設備上，使用HTML5 localStorage能很好地作到內嵌。

因爲不知道用戶是否已經訪問過這個頁面了，因此須要網站有機制能生成不一樣版本的頁面。

五、使用HTML5服務端發送事件

Web應用已經使用了各類從服務器上輪詢資源的方法來持續地更新頁面，HTML5的EventSource對象和Server一Sent事件能經過瀏覽器端的JavaScript代碼打開一個服務端鏈接客戶端的單向通道，服務端能夠使用這個寫通道來發送數據，這樣能節省了HTTP建立多個輪詢請求的消耗。

這種方式比HTML的WebSocket更高效，WebSocket的使用場景是，當有許多客戶端和服務端的交互的時候（好比消息或者遊戲），在全雙工鏈接上創建一個雙向通道。

這個技術是基於具體的技術實現的，若是你的網站當前是使用其餘的Ajax或者Comet技術來輪詢的，轉變成Server一Sent事件須要重構網站的Javascript代碼。

六、消除重定向

當用戶在一個移動設備上訪問桌面PC網站的時候，Web網站應用一般讀取HTTP的user一agent頭來判斷這個用戶是不是來自移動設備的，而後應用會發送帶有空HTTP body和重定向HTTP地址頭的HTTP 301（或者302）請求，把用戶重定向到網站的移動版本上去，可是這個額外的客戶端和服務端的交互一般在移動網絡上會消耗幾百毫秒，所以，在原先的請求上傳遞移動的web頁會比傳遞一個重定向的信息並讓客戶端再請求移動頁面更快。

對於那些想要在移動設備上看桌面PC網站的用戶來講，你能夠在移動web頁面上提供一個連接入口，這樣也能同時表示你的網站是並不提倡這種行爲的。

雖然這個技術在理論上是簡單的，可是實際上並不易於實施，因爲有些m.sites是宿主在其餘地方的，因此許多網站會選擇重定向到一個不一樣的服務器上，有的網站則是會在重定向請求的時候種植上Cookie告訴Web應用這個用戶是在使用移動設備，這種方法可能對web應用來講更容易控制。

七、減小資源負載

關於移動端頁面的大小問題，渲染小頁面更快，獲取小資源也更快，減少每一個請求的大小一般不如減小頁面請求個數那麼顯著地提升性能。

可是有些技術在性能方面，特別是在須要對帶寬和處理器性能精打細算的移動設備環境下，仍然是能帶來很大利益的。

八、壓縮文本和圖像

諸如gzip這樣的壓縮技術，依靠增長服務端壓縮和瀏覽器解壓的步驟，來減小資源的負載，可是，通常來講，這些操做都是被高度優化過了，並且測試代表，壓縮對網站仍是起到優化性能的做用的，那些基於文本的響應，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS能夠減小大約70%的大小。

瀏覽器在Accept一Encoding請求頭中申明它的解壓縮技術，而且當它們接收到服務端返回的Content一Encoding響應頭標示的時候，就會按照這個響應頭自動作解壓操做。

馬海祥以爲這種方法的優勢就是易於實現，若是設置正確的話，如今全部的Web服務器都支持壓縮響應，可是，也有一些桌面PC的安全工具會將請求頭中的Accept一Encoding頭去掉，這樣即便瀏覽器支持解壓縮，用戶也沒法獲取到壓縮後的響應。

gzip：後端服務器對返回的文本內容進行壓縮，瀏覽器接收後會自動解壓編譯，通常來講，gzip消耗服務器cpu，但能夠減小流量

九、代碼簡化

簡化一般是使用在腳本和樣式文件中，刪除一些沒必要要的字符，好比空格，換行符，或者註釋等，不須要暴露給外部的命名就能夠被縮短爲一個或者兩個字符，好比變量名，合適的簡化資源一般在客戶端不須要作任何其餘的處理，而且平均減小20%的資源大小，內嵌在HTML中的腳本和樣式文件也是能夠精簡的，有不少很好的庫來作精簡化的操做，這些庫通常也同時會提供合併多個文件這樣減小請求數的服務（具體可查看馬海祥博客《手機網站製做的經常使用方法及優化技巧》的相關介紹）。

簡化帶來的好處並不侷限於減小帶寬和延遲，對於那些移動設備上緩存沒法保存的過大資源來講，也是頗有改善的，Gzip在這個方面並無任何幫助，由於資源是在被解壓後才被緩存起來的。

Google的Closure Compiler已經難以置信地完成了理解和簡化Javascript的工做，可是CSS的簡化則沒有那麼容易，由於對不一樣瀏覽器來講有不一樣的CSS技術能迷惑CSS簡化工具，而後讓CSS簡化後沒法正常工做，馬海祥提醒你們必需要注意的是，已經有這樣的案例了，即便只是刪除了沒必要要的字符，簡化工做也有可能破壞頁面，因此當你應用簡化技術以後，請作一下完整的功能測試工做。

十、調整圖片大小

圖片一般是佔用了Web頁面加載的大部分網絡資源，也佔用了頁面緩存的主要空間，小屏幕的移動設備提供了經過調整圖片大小來加速傳輸和渲染圖片資源的機會，若是用戶只是在小的移動瀏覽器窗口中看圖片的話，高分辨率的圖片就會浪費帶寬、處理時間和緩存空間。

爲了加速頁面渲染速度和減小帶寬及內存消耗，能夠動態地調整圖片大小或者將圖片替換爲移動設備專用的更小的版本，不要依靠瀏覽器來將高分辨率的圖片轉換成小尺寸的圖片，這樣會浪費帶寬。

另一個方法是先儘快加載一個低分辨率的圖片來渲染頁面，在onload或者用戶已經開始和頁面交互之後將這些低分辨率的圖片替換成爲高分辨率的圖片。

特別應用在高度動態化的網站是有優點的。

十一、使用HTML5和CSS 3.0來簡化頁面

HTML5包括了一些新的結構元素，例如header，nav，article和footer，使用這些語義化的元素比傳統的使用div和span標籤能使得頁面更簡單和更容易解析，一個簡單的頁面更小加載更快，而且簡單的DOM（Document Object Model）表明着更快的JavaScript執行效率，新的標籤能很快地應用在包括移動端的新瀏覽器版本上，而且HTML5設計讓那些不支持它的瀏覽器能平穩過渡使用新標籤。

HTML5的一些表單元素提供了許多新屬性來完成本來須要javascript來完成的功能，例如，新的placeholder屬性用於顯示在用戶輸入進入輸入框以前顯示的介紹性文字，autofocus屬性用於標示哪一個輸入框應當被自動定位。

也有一些新的輸入框元素能不用依靠Javascript就能夠完成一些通用的需求，這些新的輸入框類型包括像e一mail，URL，數字，範圍，日期和時間這樣須要複雜的用戶交互和輸入驗證的元素，在移動瀏覽器上，當須要輸入文本的時候，彈出的鍵盤一般是由特定的輸入框類型來作選擇的，不支持指定的輸入類型的瀏覽器就會只顯示一個文本框。

另外，只要瀏覽器支持內建的層次，圓角，陰影，動畫，過渡和其餘的圖片效果，CSS 3.0就能幫助你建立輕便簡易的頁面了，而這些圖片效果原先是須要加載圖片才能完成的，這樣，這些新特性就能加速頁面渲染了。

人工地作這些改動是很是複雜和耗時的，若是你使用CMS，它能夠幫你生成許多你不須要控制的HTML和CSS（具體可查看馬海祥博客《製做移動端手機網站過程當中的SEO優化方法技巧》的相關介紹）。

十二、延遲渲染」BELOW一THE一FOLD」內容

能夠肯定的是若是咱們將不可見區域的內容延遲加載，那麼頁面就會更快地展示在用戶面前，這個區域叫作「below the fold」，爲了減小頁面加載後須要從新訪問的內容，能夠將圖片替換爲正確的高寬所標記的<img>標籤。

一些好的Javascript庫能夠用來處理這些below一the一fold 延遲加載的圖像。

1三、延遲讀取和執行的腳本

在一些移動設備上，解析Javascript代碼的速度能達到100毫秒每千字節，許多腳本的庫直到頁面被渲染之後都是不須要的加載的，下載和解析這些腳本能夠很安全地被推遲到onload事件以後來作。

例如，一些須要用戶交互的行爲，好比託和拽，都不大可能在用戶看到頁面以前被調用，相同的邏輯也能夠應用在腳本執行上面，儘可能將腳本的執行延遲到onload事件以後，而不是在初始化頁面中重要的可被用戶看到的內容的時候執行。

這些延遲的腳本多是你本身寫的，更重要的是，也有多是第三方的，對廣告、社交媒體部件、或者分析的差勁的腳本優化會致使阻塞頁面的渲染，會增長珍貴的加載時間，固然，你須要當心地評估諸如jquery這樣爲移動網站設計的大型腳本框架，特別當你僅僅只是使用這些框架中的一些對象的時候更要當心評估。

許多第三方的框架如今提供延遲加載的異步版本的API，開發者只須要將原先的邏輯轉化到這個異步版本，一些JavaScript要作延遲加載會有些複雜，由於在onload以後執行這些腳本須要注意不少注意事項（例如，你有個腳本須要綁定到onload事件上，你須要作什麼？若是你將腳本延遲到onload事件以後，就必定就會失去不少執行的時機）。

1四、使用Ajax來加強進程

Ajax（Asynchronous JavaScript and XML）是一項使用XHR（XMLHttpRequest）對象來從Web服務器上獲取數據的技術，它並不須要更新正在運行的頁面，Ajax能更新頁面上的某個部分而不須要從新構建整個頁面，它一般用來提交用戶的交互相應，可是也能夠用來先加載頁面的框架部分，而後當用戶準備好瀏覽網頁的時候再填充詳細的內容。

儘管是這個名字，可是XMLHttpRequest並不強制要求你只能使用XML，你能夠經過調用overrideMineType方法來制定「application/json」類型來使用json替換XML，使用JSON.parse會比使用原生的eval()函數快了幾乎兩倍，而且更爲安全。

同時，切記Ajax的返回響應也會得益於那些應用在普通的返回響應的優化技術上面，確保對你的Ajax返回響應使用了緩存頭，簡化，gzip壓縮，資源合併等技術。

因爲這個技術是根據具體應用不一樣而不一樣的，因此很難量化，或許因爲跨域問題，你須要使用XHR2，這個技術能使用外部域的資源，從而能進行跨域的XHR請求。

1五、根據網絡情況進行適配處理

因爲使用更多帶寬會使用更多移動網絡的費用，因此只有能檢測網絡的類型才能使用針對特定網絡的優化技術。

例如，預加載將來使用到的請求是很是聰明的作法，可是若是用戶的帶寬很稀有，而且加載的有些資源是永遠不會用到的話，這個技術就是不合理的了。

在Android 2.2+，navigator.connection.type屬性的返回值能讓你區分Wifi和2G/3G/4G網絡，在Blackberry上，blackberry.network也能提供類似的信息，另外，服務端經過檢測請求中的User一Agent頭或者其餘的嵌入到請求中的信息能讓你的應用檢測到網絡情況。

檢測網絡信息的API最近已經有所變化了，接口如今不是直接定義Wi一Fi，3G等網絡情況，而是給出了帶寬信息和諸如「很是慢，慢，快和很是快」這樣的建議，有個屬性能給出估計的MB/s值和一個「meterd」的Boolean值來表示它的可信度，可是對瀏覽器來講，很難根據這個來判斷環境，判斷當前網絡環境而後適配仍然是一種最好的方法（具體可查看馬海祥博客《百度移動搜索開放適配服務的3種方法》的相關介紹），可是這種方法正在被考慮被替換。

1六、對多線程來講儘可能使用HTML5的WEB WORKER特性

HTML5中的Web Worker是使用多個線程併發執行Javascript程序，另外，這種特別的多線程實現能減小困惑開發者多年的，在其餘平臺上遇到的問題，例如，當一個線程須要改變一個正在被其餘線程使用的資源該如何處理，在Web Worker中，子線程不能修改主用戶界面（UI）線程使用的資源。

對提升移動站點的性能來講，Web Worker中的代碼很適合用來預處理用戶完成進一步操做所須要的資源的，特別是在用戶的帶寬資源不緊缺的狀況下，在低處理器性能的移動設備上，過多的預加載可能會干擾當前頁面的UI響應，使用多線程代碼，讓Web Worker對象（而且儘量使用localStorage來緩存數據）在另一個線程中操做預加載資源，這樣就能不影響當前的UI表現了。

要特別說明的是，Web Worker只在Android 2.0以上的版本實現，並且iphone上的ios5以前的版本也不支持，在桌面PC上，老是落後的IE只在IE 10才支持Web Worker。

雖然這項技術並非很是難實現，可是對Web Workers來講，有一些限制須要強制遵照，Web Workers不能進入到頁面的DOM，也不能改變頁面上的任何東西，Web Worker很適合那種須要後臺計算和處理的工做。

1七、將CLICK事件替換成TOUCH事件

在觸摸屏設備上，當一個用戶觸碰屏幕的時候，onclick事件並無當即觸發，設備會使用大約半秒（大多數設備差很少都是300毫秒）來讓用戶肯定是手勢操做仍是點擊操做，這個延遲會很明顯地影響用戶指望的響應性能，要使用touchend事件來替換才能解決，當用戶觸碰屏幕的時候，這個事件會當即觸發。

爲了要確保不會產生用戶不指望的行爲，你應該也要使用touchstart和touchmove事件，例如，除非同時有個touchstart事件在button上，不然不要判斷touchend事件在button上就意味着點擊行爲，由於用戶有可能從其餘地方觸碰開始，而後拖拽到button上觸碰結束的，你也能夠在touchstart事件以後使用touchmove事件來避免將touchend事件誤判爲點擊，固然前提是須要假設拖拽的手勢並非預期產生點擊行爲。

另外，你也須要去處理onclick事件來讓瀏覽器改變button的外觀從而標識爲已點擊的狀態，同時你也須要處理那些不支持touch事件的瀏覽器，爲了不代碼在touchend和onclick代碼中重複執行，你須要在確保用戶觸碰事件已經在touchend執行了以後，在click事件中調用preventDefault和stopPropagation方法。

這種技術須要更多工做才能在一個頁面中增長和維護連接，touch事件的代碼必須考慮其餘手勢，由於替換click的還有多是縮放或者敲擊動做。

1八、支持SPDY協議

應用層HTTP和HTTPS協議致使的一些性能瓶頸，使得不管是桌面仍是移動端的網站都很是難受，在2009年，谷歌開始研發一種叫作SPDY（諧意是「speedy」）的協議來替換已有的協議，這種協議宣稱能突破這些限制，這個協議的目標是讓多種瀏覽器和多種Web服務都能支持，因此這個協議是開源的，可是初步地，只有Google的Chrome瀏覽器（在版本10及以後的）和google的站點支持，一旦一個Web服務支持SPDY，那麼它上面的全部站點均可以和支持這個協議的瀏覽器使用SPDY進行交互，將SPDY應用在25個top100的Internet網站上，Google收集到的數據是網站的速度會改善27%到60%不等。

SPDY自動使用gzip壓縮全部內容，和HTTP不一樣的是，它連header的數據也使用gzip壓縮，SPDY使用多線程技術讓多個請求流或者響應流能共用一個TCP鏈接，另外SPDY容許請求設置優先級，好比，頁面中心的視頻會比邊框的廣告擁有更高的優先級。

或許SPDY中最變革性的發明就是流是雙向的，而且能夠由客戶端或者服務端發起，這樣能使得信息能推送到客戶端，而不用由客戶端發起第一次請求，例如，當一個用戶第一次瀏覽一個站點，尚未任何站點的緩存，這個時候服務端就能夠在響應中推送全部的請求資源，而不用等候每一個資源被再次獨立請求了，做爲替換協議，服務端能夠發送暗示給客戶端，提示頁面須要哪些資源，同時也容許由客戶端來初始化請求。即便是使用後一種這樣的方式也比讓客戶端解析頁面而後本身發現有哪些資源須要被請求來得快。

雖然SPDY並無對移動端有什麼特別的設置，可是移動端有限的帶寬就使得若是支持SPDY的話，SPDY在減小移動網站的延遲是很是有用的。

依據網站和服務的環境來進行平穩操做或進一步考慮，Google有一個SPDY模塊支持Apache2.2 – mod_spdy – 這個模塊是免費的；可是mod_spy有線程上的問題，而且和mod_php協做並非很好，因此要求你使用這個技術的時候要確保你的網站的正常運行。

瀏覽器輸入url到整個頁面顯示出來經歷的過程

在用戶輸入一段url後，瀏覽器會首先查看瀏覽器緩存中是否有對應的地址，若沒有則到本地dns（hosts）中尋找，再找不着則將地址發送至dns解析器上，查找到對應的ip後進行數據請求。

三次握手，服務端接收到數據後判斷請求地址，類型，判斷是否跨域等一些問題，若沒有問題，則進行數據處理，以java mvc爲例，請求經過攔截器，進入到controler，controler調用service（業務處理），service調用dao（mapper）層進行數據庫查詢，將結果返回給請求的客戶端。

客戶端得到數據，四次揮手，判斷返回數據的類型（MIME類型），如：text/html，瀏覽器進行解析，渲染引擎獲得html字符串做爲輸入，而後對html進行轉換（js引擎，渲染引擎），轉化成可以被DOM處理的形式，接着轉換成一個dom樹，在解析html的過程，解析到<link>,<script>,<img>等一些請求標籤時，會發送請求把對應的內容獲取到。這時又會同步進行css的解析，構建出css樣式規則應用到dom樹上，而後進行必定的佈局處理，好比標記節點塊在瀏覽器中的座標等造成最終的渲染樹，最後根據這棵渲染樹在瀏覽器窗口中進行繪製。

詳見：https://www.cnblogs.com/lichenghan/p/4019370.html

常見的api形式

restful API形式
http://xxxx.com/user/regist/abc/123
傳統的傳參形式
http://xxxx.com/regist?user_name=abc&psw=123

防止加密算法中加密後的串重複？

加密後與數據庫中的數據對比，如有重複則加上隨機數在進行加密

單元測試

單個組件怎麼測試性能

React組件測試框架用mocha,測試庫用官方的測試工具庫，也可以使用第三方庫Enzyme,建議使用第三方的。

詳細參見：http://www.ruanyifeng.com/blog/2016/02/react一testing一tutorial.html

Vue使用Unit和e2e測試工具：

詳細參見：http://www.tuicool.com/articles/6vulNvR

綜合問題

請列舉你知道的前端框架？經常使用的前端開發工具？開發過哪些應用和組件？

(1) 前端框架

bootstrap/jQuery/zepto/backbone/AngularJS/vue.js/React/

React Native/小程序

(2) 前端開發工具 gulp/webpack/git/svn/npm/linux

架構工具：bower、npm、yeoman、gulp、webpack

(3) 應用和組件

根據本身作的項目對答

支付功能

從後端獲取必要的數據而後調用js接口就OK了。如下是微信支付（jssdk）所需的參數

timestamp: 0, // 支付簽名時間戳，注意微信jssdk中的全部使用timestamp字段均爲小寫。但最新版的支付後臺生成簽名使用的timeStamp字段名需大寫其中的S字符
nonceStr: '', // 支付簽名隨機串，不長於 32 位
package: '', // 統一支付接口返回的prepay_id參數值，提交格式如：prepay_id=***）
signType: '', // 簽名方式，默認爲'SHA1'，使用新版支付需傳入'MD5'
paySign: '', // 支付簽名