响应式方案调研及前端开发管理思考
?網(wǎng)易首頁響應(yīng)式風(fēng)格實(shí)現(xiàn)技術(shù)調(diào)研
網(wǎng)易首頁實(shí)現(xiàn)頁面（字體）響應(yīng)式風(fēng)格的方式是在不同尺寸的視口中使用不同的容器類，如圖 1所示。當(dāng)視口大于等于1420px時(shí)，使用大尺寸容器類 （index2017_1200_wrap，width: 1200px），當(dāng)視口小于 1420px時(shí)，使用小尺寸容器類（index2017_960_wrap，width: 960px）。容器類的切換依賴于JavaScript 監(jiān)聽，如圖 2所示，并未使用CSS3的媒介查詢。
網(wǎng)易首頁在發(fā)生視口改變時(shí)，如果引起了字體和布局的響應(yīng)式變化，則頁面會(huì)有所卡頓。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 1 網(wǎng)易首頁所使用的容器類
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??圖 2 網(wǎng)易首頁用于監(jiān)聽視口變化的代碼
?CSS3之rem兼容性調(diào)研
使用rem作為單位時(shí)的瀏覽器兼容如圖 3所示。需要注意的是，IE9 / IE10 不支持font屬性簡寫時(shí)使用rem指定字體大小，IE9 / IE1 / IE11不支持偽元素的line-height屬性使用rem作為單位。
測試代碼如下：
<!DOCTYPE html> <html lang="en"> <head><meta charset="UTF-8"><title>Document</title><style type="text/css">html{font-size: 20px;}.bigger{font-size: 2rem;}.biggest{font-size: 4rem;}.font-shorthand{font: italic bold 5rem/1.2 Arial, sans-serif;}.padding-shorthand{border: 1px red solid;margin: 3rem;padding: 5rem;}.pseudo-class{line-height: 6rem;}.pseudo-class:hover{cursor: pointer;font-size: 5rem;}.pseudo-element:after{content: '這是偽元素元素';line-height: 20rem;font-size: 5rem;}</style> </head> <body><div>原生字體</div><div class="bigger">較大字體</div><div class="biggest">最大字體</div><div class="font-shorthand">font簡寫</div><div class="padding-shorthand">margin 和 padding 簡寫</div><div class="pseudo-class">偽類</div><div class="pseudo-element">偽元素</div> </body> </html>網(wǎng)站技術(shù)方案改造
改造已有項(xiàng)目 VS 搬遷到新項(xiàng)目
? 改造已有項(xiàng)目的優(yōu)勢：?
? ?1.開發(fā)內(nèi)容歸屬明確。?? ?2.部署結(jié)構(gòu)無需變化。
?改造已有項(xiàng)目的不足：
? ? ? 1.歷史負(fù)擔(dān)較大。? ? ? 2.需要新增一套前端公共資源，引起代碼冗余，增加維護(hù)成本。?
?采用新項(xiàng)目開發(fā)的優(yōu)勢：?
? ? ? 1.歷史負(fù)擔(dān)小。?? ? ? 2.可是使用新框架進(jìn)行開發(fā)、發(fā)布，流程更加可控。?
? ? ? 3.可以避免setting.js的選擇加載，提高加載效率。
?采用新項(xiàng)目開發(fā)的不足：?
? ? ?1.新項(xiàng)目的歸屬問題有待商榷。?? ? ?2.項(xiàng)目過多可能增加管理工作量。
? ? ?3.系統(tǒng)部署更加復(fù)雜。
響應(yīng)式風(fēng)格的實(shí)現(xiàn)
方案一：rem 媒體查詢 方案 （推薦）
方案描述：使用媒體查詢設(shè)置特定視口尺寸下根元素的字體大小，使用rem為單位設(shè)置具有響應(yīng)式風(fēng)格的元素的屬性，使用less的混入功能實(shí)現(xiàn)低級(jí)瀏覽器降級(jí)的需求。
優(yōu)勢：響應(yīng)速度快，代碼量小，應(yīng)對未知變化（比如視口大小的劃分從兩檔變?yōu)槿龣n）的能強(qiáng)，增加pc端使用rem的團(tuán)隊(duì)經(jīng)驗(yàn)。
不足：必須采用IE8對應(yīng)的降級(jí)策略，可能有未知的坑。
方案二：固定class 媒體查詢 方案
方案描述：使用媒體查詢，在特定的視口寬度下為特定的公共樣式適用特定的字體大小、行高等屬性，使用css3-mediaqueries-js等方案處理IE8的兼容問題。
優(yōu)勢：響應(yīng)速度較快，基本兼容IE8，雖然需要兩套樣式可公共樣式代碼量小，應(yīng)對未知變化（比如視口大小的劃分從兩檔變?yōu)槿龣n）的能較強(qiáng)。
不足：需要做響應(yīng)式風(fēng)格的元素需要包含特定的公共樣式名（類名），增加了代碼量和維護(hù)工作量。
方案三：可變?nèi)萜鞣桨?網(wǎng)易目前使用
方案描述：在不同的容器下定義兩套樣式，使用JavaScript監(jiān)聽視口尺寸變化，當(dāng)視口尺寸的變化達(dá)到臨界值時(shí)，變換頂級(jí)容器。
優(yōu)勢：完全兼容IE8
不足：需要兩套樣式，維護(hù)工作量較大，視口大小判斷不夠準(zhǔn)確，對于視口變化的響應(yīng)不及時(shí)，頁面在響應(yīng)縮放時(shí)會(huì)略有卡頓，應(yīng)對未知變化（比如視口大小的劃分從兩檔變?yōu)槿龣n）的能力差。
分屏加載
對于內(nèi)容較多，特別是圖片較多的頁面，使用分屏加載技術(shù)，避免出現(xiàn)首頁初始化時(shí)大量加載靜態(tài)資源，導(dǎo)致響應(yīng)緩慢的問題。
關(guān)于前端開發(fā)管理的思考
在開發(fā)工作進(jìn)行前和進(jìn)行中是否考慮加入技術(shù)評審環(huán)節(jié)應(yīng)當(dāng)加強(qiáng)文檔管理，包括項(xiàng)目的版本記錄，項(xiàng)目所使用到的資源（靜態(tài)資源、模塊、公共類等）記錄等。 ?
更多專業(yè)前端知識(shí)，請上 【猿2048】www.mk2048.com
總結(jié)
以上是生活随笔為你收集整理的响应式方案调研及前端开发管理思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 记HTML5 a 标签的一个小坑
- 下一篇： 2017年html5行业报告,云适配发布