移動前端開發和 Web 前端開發的區別
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
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
移動前端開發和 Web 前端開發的區別