前言
今天微博看到了寒冬大神的面試題，覺得挺有意思的，這里就做一點解答
談談你對CSS布局的理解
講講輸入完網址按下回車，到看到網頁這個過程中發生了什么。
談談你對Web前端組件化的理解，Web Component會帶來怎樣的影響
談談你對前端資源下載性能優化的經驗和思考
現在有很多的MV*框架，你對它們有什么看法
iOS體驗好在哪里，Web能趕上么？
網頁游戲怎么做？
Hybrid技術應當如何應用？
你最愛的前端框架是什么，為什么？
首先老師的題目都很大，不好答，我這里技術有缺陷，答得不好大家不要噴我，可以好好教育我嘛
淺談CSS布局
概述
<!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>
行內元素
<div> <span id="span1">主體 </span><span id="span2">導航 </span> </div>
移動端的建議
總結
一次請求的完整流程
請求返回后，便進入了我們關注的前端模塊
<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>
<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>
MVC與組件化
View分離
① 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的切換都如此困難，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開發也只是需要一點熟悉度罷了，沒有什么可說的，就此打住吧
結語
寒冬老師喜歡出題，我喜歡答題，其中幾道題我這里沒有什么概念就交白卷了，不知道我的回答是否可以及格
若是寒冬老師或者各位覺得我的回答能勉強及格，左邊微博求粉！！！尼瑪我粉絲太少了！！！