摘要：并且除了常用的端，還要考慮微信端，或者是端。所以我們要有一套機(jī)制，在端上走的代碼，在端或者微信端上走端對(duì)應(yīng)的代碼。對(duì)于一個(gè)從零開(kāi)始的移動(dòng)端項(xiàng)目，我總結(jié)了以上這些移動(dòng)開(kāi)發(fā)難點(diǎn)，希望之后的人能少踩點(diǎn)坑，站在我的肩膀上提高項(xiàng)目開(kāi)發(fā)的效率和質(zhì)量。

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

輕松的熱更新，（無(wú)需等待用戶漫長(zhǎng)的更新時(shí)間）

code once，run anyway，（極大縮短產(chǎn)品的開(kāi)發(fā)時(shí)間）

豐富的社區(qū)、成熟的技術(shù)棧和人才儲(chǔ)備

性能問(wèn)題（在低端機(jī)型上不夠流暢，點(diǎn)擊延遲等）

兼容性問(wèn)題（不僅要適配各種各樣的屏幕，還要面對(duì)各類廠商對(duì)系統(tǒng)瀏覽器進(jìn)行篡改引發(fā)的兼容性問(wèn)題）

加載時(shí)間

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

H5適合做活動(dòng)頁(yè)，運(yùn)營(yíng)頁(yè)，簡(jiǎn)單的展示頁(yè)。（支持瀏覽器的地方就能展示，就能使用）

H5適合做產(chǎn)品最小原型，開(kāi)發(fā)效率快（一份代碼跑兩個(gè)平臺(tái)）

H5適合還不成熟需要頻繁迭代的產(chǎn)品

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

不同系統(tǒng)+不同品牌+不同版本的瀏覽器都會(huì)有各種各樣自己的默認(rèn)樣式，很多時(shí)候如果忽視瀏覽器的默認(rèn)樣式會(huì)導(dǎo)致顯示樣式上出現(xiàn)兼容性問(wè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)兼容性問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

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

固定寬度，viewport縮放

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

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

rem做寬度，viewport縮放

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

動(dòng)態(tài)的生成 viewport；

屏幕寬度設(shè)置 rem的大小，即給設(shè)置font-size；

根據(jù)設(shè)備像素比（window.devicePixelRatio）給設(shè)置data-dpr

rem 適配效果

通過(guò)fekey轉(zhuǎn)換來(lái)避免手寫(xiě)rem

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)和展望

移動(dòng)h5開(kāi)發(fā)有許多難點(diǎn)，這些難點(diǎn)如果傳統(tǒng)web開(kāi)發(fā)人員不去學(xué)習(xí)和了解就會(huì)踩坑。對(duì)于一個(gè)從零開(kāi)始的移動(dòng)端h5項(xiàng)目，我總結(jié)了以上這些移動(dòng)開(kāi)發(fā)難點(diǎn)，希望之后的人能少踩點(diǎn)坑，站在我的肩膀上提高項(xiàng)目開(kāi)發(fā)的效率和質(zhì)量。之后我們會(huì)結(jié)合fekey在項(xiàng)目初始化階段把這些問(wèn)題解決，產(chǎn)出一份移動(dòng)開(kāi)發(fā)的項(xiàng)目模板，替新人將這些坑踩平。