搭建移動(dòng)H5開發(fā)項(xiàng)目實(shí)戰(zhàn)

時(shí)間：2019-09-04 23:14:42 | 來源：

前端H5開發(fā)的前世今身

在Pc的時(shí)代，前端技術(shù)無疑統(tǒng)治了大多數(shù)用戶的交互界面！而在移動(dòng)為王的今天，NA開發(fā)在早期占領(lǐng)了大多數(shù)用戶的交互界面，后來逐漸的前端H5開發(fā)找到了自己的技術(shù)優(yōu)勢，慢慢的后來居上。

前端H5的優(yōu)勢有：

輕松的熱更新，（無需等待用戶漫長的更新時(shí)間）
code once，run anyway，（極大縮短產(chǎn)品的開發(fā)時(shí)間）
豐富的社區(qū)、成熟的技術(shù)棧和人才儲(chǔ)備

與此同時(shí)也面臨了許多難題，比如：

性能問題（在低端機(jī)型上不夠流暢，點(diǎn)擊延遲等）
兼容性問題（不僅要適配各種各樣的屏幕，還要面對各類廠商對系統(tǒng)瀏覽器進(jìn)行篡改引發(fā)的兼容性問題）
加載時(shí)間

分庭抗禮

至此前端H5和NA開發(fā)形成了一種互補(bǔ)的關(guān)系，各有自己的適用場景和自己的優(yōu)劣之處：

H5適合做活動(dòng)頁，運(yùn)營頁，簡單的展示頁。（支持瀏覽器的地方就能展示，就能使用）
H5適合做產(chǎn)品最小原型，開發(fā)效率快（一份代碼跑兩個(gè)平臺(tái)）
H5適合還不成熟需要頻繁迭代的產(chǎn)品

移動(dòng)開發(fā)之蕩

移動(dòng)h5開發(fā)和桌面web開發(fā)有許多不同的地方，一個(gè)傳統(tǒng)的桌面web開發(fā)工程師，如果沒有經(jīng)過一定的學(xué)習(xí)和嘗試無法開發(fā)出適應(yīng)移動(dòng)web的應(yīng)用。
那移動(dòng)開發(fā)相較于傳統(tǒng)web開發(fā)有哪些避無可避的難點(diǎn)呢?接下來我將結(jié)合在BANFF項(xiàng)目中的實(shí)踐來分別介紹這些移動(dòng)h5開發(fā)中的難點(diǎn)以及如何解決這些難點(diǎn)。

難題一：瀏覽器默認(rèn)樣式

不同系統(tǒng)+不同品牌+不同版本的瀏覽器都會(huì)有各種各樣自己的默認(rèn)樣式，很多時(shí)候如果忽視瀏覽器的默認(rèn)樣式會(huì)導(dǎo)致顯示樣式上出現(xiàn)兼容性問題，有的時(shí)候可能在某些機(jī)型上看上去很好，但是換了一個(gè)機(jī)型卻顯示又不正常。

在桌面web時(shí)代

前端要適配的瀏覽器有限（有IE，火狐，chrome，360等）。這個(gè)時(shí)候我們可以不考慮這些默認(rèn)的樣式，畢竟不一致的地方較少。這個(gè)時(shí)候可以采用常規(guī)的css normall，將各個(gè)瀏覽器的css顯示差異控制在一定范圍內(nèi)，這樣既能保留平臺(tái)的特色UI展示，又能避免出現(xiàn)兼容性問題。

移動(dòng)h5時(shí)代

在移動(dòng)h5上情況就不一樣了，手機(jī)系統(tǒng)多種多樣，瀏覽器平臺(tái)數(shù)不勝數(shù)。如果不嚴(yán)格控制住瀏覽器的默認(rèn)樣式，顯示的兼容性問題就比較嚴(yán)重了。

在BANFF項(xiàng)目中我們對比了 css normal 和 css reset 兩種方案，最終采用了css reset 技術(shù)，因?yàn)樵跍y試過程中我們發(fā)現(xiàn)，采用css normal方案去開發(fā)移動(dòng)h5，總會(huì)遇到有一些機(jī)型的樣式無法貼合UE圖的效果，所以我們采用css reset將各個(gè)平臺(tái)的css顯示差異都抹平，這樣就無需考慮瀏覽器的默認(rèn)樣式了。雖然方法簡單粗暴，但是對移動(dòng)h5開發(fā)來說卻非常管用。

css reset方案的核心代碼
IE下不同版本的默認(rèn)樣式摘要

難題二：屏幕適配

如何適配數(shù)不清的屏幕尺寸，曾經(jīng)是困擾前端開發(fā)人員的一大難題。

瀏覽器占比：
主流的屏幕類型：

看了以上的瀏覽器占比和主流的屏幕類型就知道屏幕適配對前端開發(fā)來說是一個(gè)多大的問題了。

在屏幕適配這個(gè)問題上，曾今出現(xiàn)了許多優(yōu)秀的解決方案：

最開始的基于media技術(shù)的響應(yīng)式布局

bootstrap樣式庫采用了這套適配方案，這套方案的核心思想是將屏幕分為三種類型，搭配上柵格系統(tǒng)，我們能夠?qū)懗鐾瑫r(shí)兼容移動(dòng)端小屏幕和pc大屏幕的頁面。

移動(dòng)端適配方案分為幾個(gè)派別：

固定高度，寬度自適應(yīng)

這是目前使用較多的方法，垂直方向用定值，水平方向用百分比、定值、flex都行。騰訊、亞馬遜、搜狐的首頁都是使用的這種方法。
這種方法使用了完美視口：

<meta name="viewport" content="width=device-width,initial-scale=1">

固定寬度，viewport縮放

這種方案：設(shè)計(jì)圖、頁面寬度、viewport width使用一個(gè)寬度，瀏覽器幫我們完成縮放。單位使用px即可。

原理是根據(jù)屏幕寬度來動(dòng)態(tài)生成viewport，生成的 viewport 基本是這樣：

<meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5,minimum-scale=0.5,user-scalable=no">

rem做寬度，viewport縮放

這種方案是目前業(yè)界比較認(rèn)可的一種方案，也是吸取了其他方案的長處再進(jìn)行改良的一種方案
原理有以下三點(diǎn)：

動(dòng)態(tài)的生成 viewport；
屏幕寬度設(shè)置 rem的大小，即給<html>設(shè)置font-size；
根據(jù)設(shè)備像素比（window.devicePixelRatio）給<html>設(shè)置data-dpr

rem 適配效果

通過fekey轉(zhuǎn)換來避免手寫rem

在BANFF項(xiàng)目中我們比較了以上的幾種適配方案

首先響應(yīng)式布局的解決方案無法實(shí)現(xiàn)真正的移動(dòng)適配，它的適配只能解決pc大屏幕到手機(jī)小屏幕的問題，但是手機(jī)屏幕任然有很多種，這個(gè)時(shí)候基于響應(yīng)式布局的來寫頁面會(huì)發(fā)現(xiàn)在Iphone6下看上去和UE效果圖一致，但到了iphone5s下按鈕之間的間距和UE效果圖就差很多，更不用說Iphone4s和其他一眾Android機(jī)型了

而rem方案能夠解決小屏幕的適配問題，因?yàn)樗娘@示單位rem是隨著屏幕大小，rem方案比（固定寬度，viewport縮放）來說有優(yōu)勢的地方是可以使用兩種不同的單位，想讓元素適配的時(shí)候就用rem，想讓文字不縮放的時(shí)候就用px。比如1px的線rem就能輕松搞定，而其他方案不行。比如一些文字我們并不希望它適配，因?yàn)椴糠肿煮w適配后會(huì)顯示出毛邊，這個(gè)時(shí)候用px能實(shí)現(xiàn)不適配的效果。rem的不足之處是我們在書寫樣式的時(shí)候要手動(dòng)將UE的標(biāo)注轉(zhuǎn)化成rem。

最終我們采用了wmflex 基于（rem做寬度，viewport縮放）的解決方案，很好的實(shí)現(xiàn)了適配各類屏幕。同時(shí)采用了fekey（px To rem）來解決書寫rem不方便的問題，這樣我們在寫樣式的時(shí)候只要和按照UE標(biāo)準(zhǔn)的
750px來就行了，fekey會(huì)自動(dòng)幫助我們轉(zhuǎn)為rem。經(jīng)過測試在低端的Android機(jī)上或者是dpr等于2的IPhone6s和dpr等于3的IPhone6s plus都能很好的按照交互圖來展示。

可以說基于rem適配原理的這一套解決方案，我們已經(jīng)能夠輕松適配各種類型、各種大小的屏幕。

難題三：點(diǎn)擊延遲

web開發(fā)對鼠標(biāo)有一套完整的事件支持，但是對移動(dòng)系統(tǒng)上的點(diǎn)擊，觸控，滑動(dòng)的事件支持并不完善。就拿最常見的點(diǎn)擊來說，h5就有過很長一段時(shí)間的不好體驗(yàn)。

點(diǎn)擊延遲，對于早期的h5開發(fā)可以說是致命的，相較于native的流暢來說，h5的300毫秒的點(diǎn)擊延遲幾乎是不可接受的。

業(yè)界常用的方法是采用將touch事件來進(jìn)行一系列封裝，進(jìn)而得出一套觸控Api來。

fastclick就是經(jīng)過大量優(yōu)化的去除點(diǎn)擊延遲解決方案。原理是hook了瀏覽器的touch事件來模擬click事件，讓前端開發(fā)人員以熟悉的click來書寫代碼

除了點(diǎn)擊事件，滾動(dòng)、滑動(dòng)、多點(diǎn)觸控，這些瀏覽器不原生提供的能力都需要我們用代碼去模擬出來。

在BANFF項(xiàng)目中采用較常規(guī)的解決方案fastclick來去除點(diǎn)擊延遲，在以后的項(xiàng)目中如果遇到更復(fù)雜的交互需求，會(huì)采用更具擴(kuò)展性的hammerjs來處理各種各樣的觸碰需求。比如滑動(dòng)、旋轉(zhuǎn)、多點(diǎn)觸碰。

難題四：mock與調(diào)試

H5頁面運(yùn)行環(huán)境多樣，如果僅僅是通過報(bào)錯(cuò)后彈出alert框這種形式去調(diào)試的話，開發(fā)效率會(huì)降低很多。

首先H5頁面肯定是能運(yùn)行在Pc Chrome上的，借用Chrome的成熟調(diào)試體系效率會(huì)提高很多；但是我們要考慮到NA內(nèi)嵌的webview，其中js代碼的運(yùn)行時(shí)機(jī)要依賴websdk的加載。無法簡單的將h5應(yīng)用拿到chrome上調(diào)試。并且除了常用的waimaiApp端，還要考慮微信端，或者是Banff端。所以我們要有一套mock機(jī)制，在Pc端上走M(jìn)ock的代碼，在NA端或者微信端上走端對應(yīng)的代碼。

一種較好的代碼架構(gòu)思路是我們提供一個(gè)Adapter層，Adapter層對業(yè)務(wù)代碼提供一致的接口，然后Adapter根據(jù)不同的使用場景對接不同的端代碼

有了Adapter層后我們根據(jù)什么來判斷當(dāng)前代碼運(yùn)行在什么端呢？比較常見的方法是通過瀏覽器的ua來進(jìn)行判端。如果擔(dān)心代碼的體積問題，我們也能通過fekey或其他打包工具，在打包階段，打包出不同端對應(yīng)的代碼。這樣能減少代碼的加載時(shí)間和體積。

關(guān)于我們：

藍(lán)暢信息技術(shù)有限公司成功為多家世界財(cái)富500強(qiáng)企業(yè)以及其他著名品牌提供優(yōu)質(zhì)服務(wù)，是您靠譜的互聯(lián)網(wǎng)開發(fā)供應(yīng)商。

服務(wù)客戶遍及北京、上海、杭州、深圳、廣州、天津、青島、南京、寧波、蘇州、無錫、廈門、重慶、西安等大中型城市及地區(qū) 為您提供：H5開發(fā)，H5設(shè)計(jì)，H5外包，微信開發(fā)外包，H5商城開發(fā)，小程序商城開發(fā)，網(wǎng)站開發(fā)外包，H5游戲開發(fā)，小程序開發(fā)外包，小程序設(shè)計(jì)、APP開發(fā)外包，UI設(shè)計(jì)，SEO優(yōu)化，視頻后期制作等優(yōu)質(zhì)服務(wù)

H5開發(fā),小程序開發(fā)供應(yīng)商