移動前端開發和 Web 前端開發的區別

pc，咱們須要考慮什麼呢？有點開發經驗的同窗都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪一個都夠你吃一壺的，不管是css仍是js。
mobile的網頁開發，咱們須要考慮什麼呢？
就目前來講，咱們只須要考慮webkit內核的瀏覽器和chrome，uc，qq，小米手機瀏覽器

ok，單純說pc和移動端開發的區別，其實也就是這個，能夠簡單的歸納來講，mobile端的網頁開發比pc端的網頁開發，更簡單一些。【頁面小了啊，裝的東西少了，css和html寫的少了吧】交互簡單一些【滑動，觸屏，手勢，平時看看手機你還能有啥特殊操做？】

做者：小爝
連接：https://www.zhihu.com/question/20269059/answer/60767669
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

移動端web app開發與套殼開發區別。

移動端web app，移動端網頁，Hybrid開發【我喜歡叫套殼開發工程師……】，無所謂叫什麼，移動端開發無疑就是這3種了。下面一一解釋下個人理解。

移動端web app是什麼呢？簡單理解就是頁面頭部加入了下面這一句話的東西：

<meta name="apple-mobile-web-app-capable" content="yes">

這個meta的做用是讓普通移動網頁被添加到主屏幕後，擁有一些類native的功能，不少同窗應該都很熟悉了。就是相似隱藏ios的上下狀態欄，實現全屏，禁止彈性拖拽，全屏，修改頂部顏色等。

我理解這種模式的網頁爲web app，固然還有一種類型就是你們平時都訪問的那些網站，好比手機taobao，手機美團，手機微博的網頁版，你們打開的時候，不是全屏的，可是用起來，開發者把它們假裝的很像這種web app的交互體驗而已。

以上2種我以爲能夠總結爲web app。而不是普通的移動端網頁，若是想看移動端網頁，能夠參考手機新浪網，手機網頁，手機騰訊新聞，手機鳳凰，是很好的對比。

以後我來講下套殼的吧。這部分若是沒有開發過phonegap或者相似和native連調過webview的同窗，可能以爲很陌生，其實不是，這種套殼開發和開發普通的網頁沒什麼區別，只不過資源大部分是file開頭的，本地資源，網絡資源分爲使用js異步接口獲取和native獲取，再和js的接口交互，相似ios中，能夠直接在oc或者swift能夠直接在webview中執行js，android同理，可是js想調用native功能怎麼辦呢？

咱們這邊的作法是有一個負責通信的iframe，咱們經過修改這個iframe的url，來讓native來監控一系列特殊的url地址請求，再在native中調用對應的功能，好比攝像頭，特殊交互，呼起，或者提供接口數據。數據的提供方式相似jsonp的原理，在執行函數的參數中傳回來。

理解了這塊，其實作套殼的比作普通web app和網頁都簡單，由於在native的webview中是能夠指定是什麼版本的webview，用什麼內核，擁有什麼等級的安全權限等等，ios和android作法不同，可是原理一致，對於前端開發工程師來講是無差的。

並且套殼開發還有個好處就是，由於資源是本地化的，因此可使用比較重的框架，如angular，react，一些三方框架，由於最終都是經過和native代碼捆綁發佈的。

套殼native的靜態前端部分的更新，咱們可使用遠程下載靜態資源包的方法實現，不發佈大版本而修改webview中邏輯的需求，這一點也是大部分公司選擇一半native一半h5來開發的緣由。都知道ios審覈發版很慢。

這些就是我知道的一些很通俗的區別了，技術細節就不說了，太多。你們有個概念就好啦。

3，對js和css的使用選擇。

這部分我提早預警，這是我本身的見解，不必定是正確的，你們互相討論。

個人想法是不使用目前那些主流的移動端框架，選擇手寫。我會說爲何。
好比jq mobile，zepto，backbone，angular，還有相似工具集，underscore，一些動畫框架，還有小型的遊戲框架，通通實際上是不太須要的。

我並非說他們很差，而是這些對於新手來講，只能是陣痛藥，而不是萬能藥。爲何呢，移動端的優化很大的一個瓶頸就是網絡加載速度不一致，有wifi，有3g，有4g，還有2g。代碼量在移動端開發是很大的一個考察點。

咱們反觀這些框架：zepto最早說，你用它作什麼？動畫？選擇器？事件委派？基於zepto的插件？可能大部分人就是用個選擇器吧。可是移動端的原生選擇器方法應有盡用，原生的徹底夠用，包括事件和委派，一共寫起來不超過10幾行的東西，引入一個框架不值得。再說mvc的框架，若是不使用離線存儲，我是反正不敢想沒wifi的狀況下體驗如何，外加移動端真的是否須要分層這種處理不說，主要仍是看業務場景。

套殼的那種上面說了，框架隨便用，由於足夠複雜，可是普通移動端開發，我我的是不推薦使用的，能夠直接上原生的來寫，最多來一個模塊化工具。我下面就說說本身是怎麼作的吧。

手機端對ES5的特性已經所有都支持的很好了，參考：
xiaojue/ES-shim · GitHub
這裏的api特性，只實現了一部分，可是其實平時對數據的處理，對象的處理，已經徹底足夠。我不說優缺點，我只說，移動端這些都是純自然的而已。

而後是咱們對手勢的處理，zepto中有幾個頗有用的事件，swipe，swipeLeft，right，up，down，一類的，還有tap，咱們能夠看下zepto的源碼：
zepto/touch.js at master · madrobby/zepto · GitHub
咱們真的全部場景都須要全部的功能麼，tap，doubletap，有多少人用了。。用到的時候，也是很是好實現的功能。我推薦直接手寫，或者本身寫一個swipe的基類，也不會比zepto的touch.js多太多，而好處是咱們可讓它貫穿咱們的項目，做爲一個base類使用，固然我不是噴zepto多餘，它不少代碼作了兼容處理，可是就目前咱們的業務來講，咱們只須要考慮webkit，只須要考慮幾個特定國產瀏覽器，由於這是統計數聽說了算。

沒了框架，咱們就不能寫代碼了麼？移動端開發，我以爲更考驗的是前端的基本功，只要基本功紮實，其實都是很簡單的需求，正由於都是本身一行一行寫的，遇到詭異問題就更好解決，而再也不須要糾結於，究竟是我作錯了，仍是框架錯了這個問題。

我不止一次的修改過iscroll的源碼來適應和「知足」咱們的測試。。。好比ios下用了iscroll，a標籤沒法點擊跳轉，不少人遇到過吧，不看文檔你還真是一時不知道怎麼解決，iscroll因爲禁止了頁面原生的滾動，不少原本很簡單得東西複雜化了，而咱們須要的是什麼？一個下託刷新？一個慣性滾動特效？開什麼玩笑，原生的也沒幾行啊。。。對於一個寫了多年pc端的前端來講我相信徒手寫個下託刷新禁止頁面慣性反彈的代碼，應該不復雜吧？這裏給個思路，好比咱們檢測touchmove的位置快到達頁面【或者容器】底部的時候，阻止touchmove，作容器或者頁面translate移動，再在下部埋一個loading，touchend以後再作緩動回覆，應該普通前端都能作到。

再說一個經常使用的移動端框架，swipe.js 作幻燈用的，我相信幻燈片作pc端得前端應該每一個人都寫過不下5遍了吧。只是事件換了，固然移動端有移動端本身須要處理的問題，可是我使用swipe框架的經歷也是很痛苦的，好比沒法很好的設置滾動過的距離，自定義緩動效果，還有沒法它本身自己帶的一些問題，好比橫豎屏的時候復位問題，動態插入子節點重排等，讓我第一次用的時候越開發越傷心，後來乾脆也是本身實現。

因此其實，1，咱們的需求，那些移動端框架不必定知足咱們。2，太大，太複雜，太難調試。3，需求其實自己不復雜，只是咱們想偷懶了。

有點跑題，這個標題說是js和css的選擇，js的立場我足夠明確了，若是簡單功能，不須要js框架，原生足夠，已經作得很好，下面說說css。

首先，作pc咱們都須要一個reset或者common，我共享下咱們的，
https://gist.github.com/xiaojue/8bac56fb488532e7857f
固然裏面有一些咱們特殊的顏色字體，我css並非特別好，我簡單的重複一下咱們css同窗的一些注意要點，可能不全：

這其中字體的選擇是根據平臺來作的，咱們平時用控制檯模擬開發的時候是沒有ios或者android系統字體的，可是你不設置又很醜，因此基本是從電腦支持，到移動端支持這個順序排列的。

下面截圖幾個wiki：

還有不少，我只找一些我認爲可能知道的人少一些的，咱們的wiki還有不少，我css並不太好，這部截自同事的wiki貢獻。

css這個方面的東西，我很差多說，畢竟我認可我css通常，可是有幾個原則能夠提煉出來的就是：
1，不少坑的形成是對原生屬性的掌握程度不熟練或者不知道有這個特性。
2，不少屬性極限突破可使用縮放，傾斜這種手段來hack，好比最小字體，好比各類本身畫的僞類圖標。
3，能css畫的不要用圖。
4，大小須要自適應的圖標作成字體的不要畫。
5，能flex佈局的不要用浮動，不要用絕對定位（不利於頁面佈局的擴展）

原本還有幾個比較典型得css案例，這個找機會在其餘答案裏說吧，都是上週css比較屌的同事分享的，我也受益不淺。總說就是移動端的css的寫法和pc相差甚遠，並且技術含量更高了，可喜的是兼容性問題少了，更多的是如何處理的更好擴展和精簡。

4，模塊化移動端的常見組件。

我只說咱們非業務方面的，能夠抽象出來的，可能和公司業務場景掛鉤。
1，touch對應的swipe事件。
2，各類滑動翻頁效果。
3，簡單的小遊戲框架。
4，視頻和音頻的包裝。
5，各類lazyload。
6，各類keyframes效果收集。
7，拉拽刷新。

其實不少pc要有的mobile端也都有，好比浮層，tip，氣泡，分享，添加主屏一類，可能和業務關聯太多，就不一一列舉了。這部分的組件其實市面上也沒有太多開源的比較簡易的，大部分都是又支持pc，又支持mobile，致使了不少冗餘，或者質量和需求，api不過關，致使很難擴展，各家都是本身寫。好比在微信的webview裏分享和在qq的webview分享，和在普通頁面的分享，在微博的webview裏分享，提示和實現的方法都不同，可是其實徹底都是能夠抽象成一個公共的東西的，個人團隊也在作這方面積累。

這個再安利一下，我作的一個作劃屏活動頁的組件：
xiaojue/EasySlide · GitHub
慢慢我也會開源咱們內部抽象好的移動端組件出來的。

5，移動端的性能優化和統計。
性能優化必須創建在統計的基礎上，不然都是耍流氓，因此先說統計。

目前個人作法和pc差很少，監控一些前端關注的時間點，首屏，doc ready，window ready，css ready，實現統計方法和pc也都同樣，應該各個公司都有，我簡單說下前端實現首屏統計如何作：

個人思路是，首屏的圖加載完，即首屏完成，首屏無圖，最接近首屏的dom節點ready的時間點爲首屏時間，咱們能夠在load的時候和document ready的過程之間檢測這幾個臨界，來收集首屏的完成時間，固然很不許啦，可是也是有一些參考價值的。。。

有了數據，我說一下移動端的統計極值問題，舉個例子，咱們手機打開一個網頁，尚未load完成，切到了後臺，這個時候腳本是不會執行的了，過了幾小時，幾天再回來的數據，咱們都能收集到，這部分屬於垃圾數據，是須要算平均值的時候去除的。這點和pc不太同樣。

而後是性能優化創建在均值性能指標上的，咱們儘快的提高首屏和win load的時間便可，原則和作法和pc一致，固然，移動端不是資源越合成一個越好，咱們的實踐是分散成不一樣的幾個資源下載，總時間比較快，好比活動頁面，h5小遊戲頁都是這樣。能夠統一把資源圖拆開加載，而後增長loading便可。

----我還在奮力思考和編寫中-----今天先到這裏了。。。。【這裏還有一個點，我想討論一下是mobile的cache的利用率問題，這個明天我詳細說，決定找些權威的數據或者本身作下測試再開始寫】

6，移動端網頁佈局方法與pc的差別。

主要是css方面，外加如何作到同一url，不一樣客戶端展示不一致的作法，俗稱pc和mobile都兼容。還有會說一下rem的相關用法和一段比較經典的rem.js

今天有空來更新一下這個rem在移動端佈局的一個用法：）（20151013更新）

首先，em和rem的概念我簡要說一下，em是父元素fontsize的倍數表示，rem則是root即爲html的fontsize的倍數表示。好比我html.style.fontSize = 12px;那麼1rem則爲12px，0.5rem爲6px；

好了，概念有了，那麼作佈局的時候咱們怎麼用呢，你們應該用過的都知道，移動端的字體默認爲16px，那麼1rem我想表示爲10px的話，咱們就須要 10 % 16 = 0.625 即爲62.5%，這樣就能夠比較方便的把設計稿裏的px轉換成rem單位來作到自適應了。這樣不管用戶如何設置電腦或者手機的默認字體大小，設置爲rem的單位的長度都會隨比例變化。

這是一種常規作法，其實換個角度咱們還能夠這樣用：

咱們想象一個設計稿寬度爲640，800，1200px等尺寸時，咱們如何來快速完成響應式的佈局呢？
百分比？flex？這些仍是有些複雜的。

後來發現，柵格等比縮放整個設計稿看起來是個更簡單粗暴的方法。並且正好能夠利用rem這個比例變化單位。

看下這段js：
https://gist.github.com/xiaojue/0615797dd6a7160177bd

比較好理解，咱們首先根據psd的設計稿寬度設置一個基值，而後咱們js獲取到當前窗口的寬度值，而後把這個設計稿寬度除以100柵格化一下，得到一份的寬度數，以後再用真實窗口的寬度除以這個一份的寬度，拿到就是咱們須要給html設置的fontsize的px值。

這樣咱們只須要把對應psd裏的px單位除以100，就獲得了任何寬度環境下的rem值。固然實際發現有些瀏覽器這個rem單位是存在bug的，好比比例值不許，那麼咱們就須要得到這個不許的比例再轉換成準的再賦值html的fontsize，可見calcTestDom函數，以後再處理一下旋轉屏幕時候的狀況，resize時候的狀況就行了。

這樣咱們在作一些活動專題頁面時，只須要引入這段js，在頁頭設置一個設計稿寬，而後對着設計稿一頓瘋狂的px除100來定位就行了。。比設置成62.5%的方式要更好（1，修復了瀏覽器bug，2，轉換單位更方便直觀，px/100便可）

7，常見js組件與pc端組件差別。

這部分還在想怎麼說比較通俗易懂，哪些組件是很是典型得，須要我回去慢慢想一想，找幾個實際的對比例子。

8，一些常見的坑。

分享一下內部wiki的經典移動端坑和解決辦法。（不會太多，別抱太大期待了。。）

9，適配【機型，瀏覽器】的方法和選擇。
1，統計說話。
2，調試方法。

10，測試技巧與pc的差異。

做者：小爝 連接：https://www.zhihu.com/question/20269059/answer/60767669 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。