摘要：并且除了常用的端，還要考慮微信端，或者是端。所以我們要有一套機制，在端上走的代碼，在端或者微信端上走端對應的代碼。對于一個從零開始的移動端項目，我總結了以上這些移動開發難點，希望之后的人能少踩點坑，站在我的肩膀上提高項目開發的效率和質量。

在Pc的時代，前端技術無疑統治了大多數用戶的交互界面！而在移動為王的今天，NA開發在早期占領了大多數用戶的交互界面，后來逐漸的前端H5開發找到了自己的技術優勢，慢慢的后來居上。

輕松的熱更新，（無需等待用戶漫長的更新時間）

code once，run anyway，（極大縮短產品的開發時間）

豐富的社區、成熟的技術棧和人才儲備

性能問題（在低端機型上不夠流暢，點擊延遲等）

兼容性問題（不僅要適配各種各樣的屏幕，還要面對各類廠商對系統瀏覽器進行篡改引發的兼容性問題）

加載時間

至此前端H5和NA開發形成了一種互補的關系，各有自己的適用場景和自己的優劣之處：

H5適合做活動頁，運營頁，簡單的展示頁。（支持瀏覽器的地方就能展示，就能使用）

H5適合做產品最小原型，開發效率快（一份代碼跑兩個平臺）

H5適合還不成熟需要頻繁迭代的產品

移動h5開發和桌面web開發有許多不同的地方，一個傳統的桌面web開發工程師，如果沒有經過一定的學習和嘗試無法開發出適應移動web的應用。
那移動開發相較于傳統web開發有哪些避無可避的難點呢?接下來我將結合在BANFF項目中的實踐來分別介紹這些移動h5開發中的難點以及如何解決這些難點。

不同系統+不同品牌+不同版本的瀏覽器都會有各種各樣自己的默認樣式，很多時候如果忽視瀏覽器的默認樣式會導致顯示樣式上出現兼容性問題，有的時候可能在某些機型上看上去很好，但是換了一個機型卻顯示又不正常。

在桌面web時代

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

移動h5時代

在移動h5上情況就不一樣了，手機系統多種多樣，瀏覽器平臺數不勝數。如果不嚴格控制住瀏覽器的默認樣式，顯示的兼容性問題就比較嚴重了。

在BANFF項目中我們對比了 css normal 和 css reset 兩種方案，最終采用了css reset 技術，因為在測試過程中我們發現，采用css normal方案去開發移動h5，總會遇到有一些機型的樣式無法貼合UE圖的效果，所以我們采用css reset將各個平臺的css顯示差異都抹平，這樣就無需考慮瀏覽器的默認樣式了。雖然方法簡單粗暴，但是對移動h5開發來說卻非常管用。

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

如何適配數不清的屏幕尺寸，曾經是困擾前端開發人員的一大難題。

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

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

在屏幕適配這個問題上，曾今出現了許多優秀的解決方案：

最開始的基于media技術的響應式布局

bootstrap樣式庫采用了這套適配方案，這套方案的核心思想是將屏幕分為三種類型，搭配上柵格系統，我們能夠寫出同時兼容移動端小屏幕和pc大屏幕的頁面。

移動端適配方案分為幾個派別：

固定高度，寬度自適應

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

固定寬度，viewport縮放

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

原理是根據屏幕寬度來動態生成viewport，生成的 viewport 基本是這樣：

rem做寬度，viewport縮放

這種方案是目前業界比較認可的一種方案，也是吸取了其他方案的長處再進行改良的一種方案
原理有以下三點：

動態的生成 viewport；

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

根據設備像素比（window.devicePixelRatio）給設置data-dpr

rem 適配效果

通過fekey轉換來避免手寫rem

在BANFF項目中我們比較了以上的幾種適配方案

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

而rem方案能夠解決小屏幕的適配問題，因為它的顯示單位rem是隨著屏幕大小，rem方案比（固定寬度，viewport縮放）來說有優勢的地方是可以使用兩種不同的單位，想讓元素適配的時候就用rem，想讓文字不縮放的時候就用px。比如1px的線rem就能輕松搞定，而其他方案不行。比如一些文字我們并不希望它適配，因為部分字體適配后會顯示出毛邊，這個時候用px能實現不適配的效果。rem的不足之處是我們在書寫樣式的時候要手動將UE的標注轉化成rem。

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

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

web開發對鼠標有一套完整的事件支持，但是對移動系統上的點擊，觸控，滑動的事件支持并不完善。就拿最常見的點擊來說，h5就有過很長一段時間的不好體驗。

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

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

fastclick就是經過大量優化的去除點擊延遲解決方案。原理是hook了瀏覽器的touch事件來模擬click事件，讓前端開發人員以熟悉的click來書寫代碼

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

在BANFF項目中采用較常規的解決方案fastclick來去除點擊延遲，在以后的項目中如果遇到更復雜的交互需求，會采用更具擴展性的hammerjs來處理各種各樣的觸碰需求。比如滑動、旋轉、多點觸碰。

H5頁面運行環境多樣，如果僅僅是通過報錯后彈出alert框這種形式去調試的話，開發效率會降低很多。

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

一種較好的代碼架構思路是我們提供一個Adapter層，Adapter層對業務代碼提供一致的接口，然后Adapter根據不同的使用場景對接不同的端代碼

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

總結和展望

移動h5開發有許多難點，這些難點如果傳統web開發人員不去學習和了解就會踩坑。對于一個從零開始的移動端h5項目，我總結了以上這些移動開發難點，希望之后的人能少踩點坑，站在我的肩膀上提高項目開發的效率和質量。之后我們會結合fekey在項目初始化階段把這些問題解決，產出一份移動開發的項目模板，替新人將這些坑踩平。