從零搭建移動H5開發項目實戰

時間 2019-11-07

標籤搭建移動 h5 開發項目實戰欄目無線简体版

原文原文鏈接

從零搭建移動H5開發項目實戰

前端H5的前世今身

在Pc的時代，前端技術無疑統治了大多數用戶的交互界面！而在移動爲王的今天，NA開發在早期佔領了大多數用戶的交互界面，後來逐漸的前端H5開發找到了本身的技術優點，慢慢的後來居上。css

前端H5的優點有：

輕鬆的熱更新，（無需等待用戶漫長的更新時間）html
code once，run anyway，（極大縮短產品的開發時間）前端
豐富的社區、成熟的技術棧和人才儲備web

與此同時也面臨了許多難題，好比：

性能問題（在低端機型上不夠流暢，點擊延遲等）chrome
兼容性問題（不只要適配各類各樣的屏幕，還要面對各種廠商對系統瀏覽器進行篡改引起的兼容性問題）bootstrap
加載時間瀏覽器

平起平坐

至此前端H5和NA開發造成了一種互補的關係，各有本身的適用場景和本身的優劣之處：微信

H5適合作活動頁，運營頁，簡單的展現頁。（支持瀏覽器的地方就能展現，就能使用）架構
H5適合作產品最小原型，開發效率快（一份代碼跑兩個平臺）iphone
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都行。騰訊、亞馬遜、搜狐的首頁都是使用的這種方法。
這種方法使用了完美視口：

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

固定寬度，viewport縮放

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

原理是根據屏幕寬度來動態生成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縮放

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

動態的生成 viewport；
屏幕寬度設置 rem的大小，即給<html>設置font-size；
根據設備像素比（window.devicePixelRatio）給<html>設置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來處理各類各樣的觸碰需求。好比滑動、旋轉、多點觸碰。

難題四：mock與調試

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在項目初始化階段把這些問題解決，產出一份移動開發的項目模板，替新人將這些坑踩平。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。