移動前端開發和 Web 前端開發的區別是什麼？

1，普通pc端開發與移動端開發區別。

普通pc端開發，我理解就是你拿電腦打開的網頁都算【這不是廢話麼】。
那麼移動端前端開發工程師，說白了就很好理解了，作手機網頁的前端開發工程師。

這麼一比，是否是感受，移動端開發簡單多了？

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

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

相比較而言，除了經驗是0之外，須要兼容的東西仍是少了，少了，少了呢。

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

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

so，別被這玩意嚇壞了，根據個人經驗來看，pc端的前端開發程序員，轉mobile開發，一點問題沒有，並且上手會很快。

夠直白的解釋了。

2，移動端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審覈發版很慢。

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

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

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

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


下面截圖幾個wiki：


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

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


下面截圖幾個wiki：


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

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

有了數據，我說一下移動端的統計極值問題，舉個例子，咱們手機打開一個網頁，尚未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的差異。幾個比較經典的調試方法和工具介紹。