移動(dòng)前端開發(fā)和 Web 前端開發(fā)的區(qū)別是什么？

時(shí)間：2022-07-31 01:18:01 | 來源：網(wǎng)站運(yùn)營

時(shí)間：2022-07-31 01:18:01 來源：網(wǎng)站運(yùn)營

我轉(zhuǎn)了快2個(gè)月了，準(zhǔn)備 談?wù)劯邢?。晚上回家吃完飯開更。

---------

看到這么多贊，不填坑對不起大家，但是本人水平有限，內(nèi)容又太多太雜，今天先更新一部分，這幾天較忙。之后慢慢補(bǔ)，謝謝大家支持和點(diǎn)贊。

有交流盡管留言，時(shí)間允許我會(huì)和你討論，并列入本回答。

0827，9：49

---------

1，普通pc端開發(fā)與移動(dòng)端開發(fā)區(qū)別。

先說背景，我大言不慚的說一下，我pc端的前端開發(fā)干了有快4年多，不算大牛，也算一個(gè)標(biāo)準(zhǔn)的前端開發(fā)工程師吧，可憐的是我2015年之前做過的移動(dòng)端項(xiàng)目不超過1個(gè)。。所以幾乎經(jīng)驗(yàn)為零。我對這個(gè)神秘又被炒的火熱的名字迷惑了很久，移動(dòng)前端開發(fā)工程師，h5前端開發(fā)工程師，native前端開發(fā)工程師，Hybrid前端開發(fā)工程師，臥槽感覺屌屌的有木有啊。。

所以我在15年決定棄坑了（pc的代碼實(shí)在寫膩歪了。。），投身到專屬的移動(dòng)開發(fā)中，業(yè)余時(shí)間也做過phonegap，也知道和了解過一些h5+native開發(fā)的方式，下面就慢慢給大家【科普】一下。。說錯(cuò)了別噴。

普通pc端開發(fā)，我理解就是你拿電腦打開的網(wǎng)頁都算【這不是廢話么】。
那么移動(dòng)端前端開發(fā)工程師，說白了就很好理解了，做手機(jī)網(wǎng)頁的前端開發(fā)工程師。

這么一比，是不是感覺，移動(dòng)端開發(fā)簡單多了？

沒錯(cuò)，我轉(zhuǎn)了之后發(fā)現(xiàn)還真是呢。。。【還有點(diǎn)小激動(dòng)】

pc，我們需要考慮什么呢？有點(diǎn)開發(fā)經(jīng)驗(yàn)的同學(xué)都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪個(gè)都?jí)蚰愠砸粔氐?，無論是css還是js。
mobile的網(wǎng)頁開發(fā)，我們需要考慮什么呢？
就目前來說，我們只需要考慮webkit內(nèi)核的瀏覽器和chrome，uc，qq，小米手機(jī)瀏覽器就好了。。?！竞竺嫣匾鈺?huì)說這幾只國產(chǎn)瀏覽器哪里屌了】

相比較而言，除了經(jīng)驗(yàn)是0以外，需要兼容的東西還是少了，少了，少了呢。

ok，單純說pc和移動(dòng)端開發(fā)的區(qū)別，其實(shí)也就是這個(gè)，可以簡單的概括來說，mobile端的網(wǎng)頁開發(fā)比pc端的網(wǎng)頁開發(fā)，更簡單一些。【頁面小了啊，裝的東西少了，css和html寫的少了吧】交互簡單一些【滑動(dòng)，觸屏，手勢，平時(shí)看看手機(jī)你還能有啥特殊操作？】

so，別被這玩意嚇壞了，根據(jù)我的經(jīng)驗(yàn)來看，pc端的前端開發(fā)程序員，轉(zhuǎn)mobile開發(fā)，一點(diǎn)問題沒有，而且上手會(huì)很快。

夠直白的解釋了。

2，移動(dòng)端web app開發(fā)與套殼開發(fā)區(qū)別。

移動(dòng)端web app，移動(dòng)端網(wǎng)頁，Hybrid開發(fā)【我喜歡叫套殼開發(fā)工程師……】，無所謂叫什么，移動(dòng)端開發(fā)無疑就是這3種了。下面一一解釋下我的理解。

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

<meta name="apple-mobile-web-app-capable" content="yes">這個(gè)meta的作用是讓普通移動(dòng)網(wǎng)頁被添加到主屏幕后，擁有一些類native的功能，很多同學(xué)應(yīng)該都很熟悉了。就是類似隱藏ios的上下狀態(tài)欄，實(shí)現(xiàn)全屏，禁止彈性拖拽，全屏，修改頂部顏色等。

我理解這種模式的網(wǎng)頁為web app，當(dāng)然還有一種類型就是大家平時(shí)都訪問的那些網(wǎng)站，比如手機(jī)taobao，手機(jī)美團(tuán)，手機(jī)微博的網(wǎng)頁版，大家打開的時(shí)候，不是全屏的，但是用起來，開發(fā)者把它們偽裝的很像這種web app的交互體驗(yàn)而已。

以上2種我覺得可以總結(jié)為web app。而不是普通的移動(dòng)端網(wǎng)頁，如果想看移動(dòng)端網(wǎng)頁，可以參考手機(jī)新浪網(wǎng)，手機(jī)網(wǎng)頁，手機(jī)騰訊新聞，手機(jī)鳳凰，是很好的對比。

之后我來說下套殼的吧。這部分如果沒有開發(fā)過phonegap或者類似和native連調(diào)過webview的同學(xué)，可能覺得很陌生，其實(shí)不是，這種套殼開發(fā)和開發(fā)普通的網(wǎng)頁沒什么區(qū)別，只不過資源大部分是file開頭的，本地資源，網(wǎng)絡(luò)資源分為使用js異步接口獲取和native獲取，再和js的接口交互，類似ios中，可以直接在oc或者swift可以直接在webview中執(zhí)行js，android同理，但是js想調(diào)用native功能怎么辦呢？

我們這邊的做法是有一個(gè)負(fù)責(zé)通訊的iframe，我們通過修改這個(gè)iframe的url，來讓native來監(jiān)控一系列特殊的url地址請求，再在native中調(diào)用對應(yīng)的功能，比如攝像頭，特殊交互，呼起，或者提供接口數(shù)據(jù)。數(shù)據(jù)的提供方式類似jsonp的原理，在執(zhí)行函數(shù)的參數(shù)中傳回來。

理解了這塊，其實(shí)做套殼的比做普通web app和網(wǎng)頁都簡單，因?yàn)樵趎ative的webview中是可以指定是什么版本的webview，用什么內(nèi)核，擁有什么等級(jí)的安全權(quán)限等等，ios和android做法不一樣，但是原理一致，對于前端開發(fā)工程師來說是無差的。

而且套殼開發(fā)還有個(gè)好處就是，因?yàn)橘Y源是本地化的，所以可以使用比較重的框架，如angular，react，一些三方框架，因?yàn)樽罱K都是通過和native代碼捆綁發(fā)布的。

套殼native的靜態(tài)前端部分的更新，我們可以使用遠(yuǎn)程下載靜態(tài)資源包的方法實(shí)現(xiàn)，不發(fā)布大版本而修改webview中邏輯的需求，這一點(diǎn)也是大部分公司選擇一半native一半h5來開發(fā)的原因。都知道ios審核發(fā)版很慢。

這些就是我知道的一些很通俗的區(qū)別了，技術(shù)細(xì)節(jié)就不說了，太多。大家有個(gè)概念就好啦。

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




這部分我提前預(yù)警，這是我自己的看法，不一定是正確的，大家互相討論。

我的想法是不使用目前那些主流的移動(dòng)端框架，選擇手寫。我會(huì)說為什么。
比如jq mobile，zepto，backbone，angular，還有類似工具集，underscore，一些動(dòng)畫框架，還有小型的游戲框架，統(tǒng)統(tǒng)其實(shí)是不太需要的。

我并不是說他們不好，而是這些對于新手來說，只能是陣痛藥，而不是萬能藥。為什么呢，移動(dòng)端的優(yōu)化很大的一個(gè)瓶頸就是網(wǎng)絡(luò)加載速度不一致，有wifi，有3g，有4g，還有2g。代碼量在移動(dòng)端開發(fā)是很大的一個(gè)考察點(diǎn)。

我們反觀這些框架：zepto最先說，你用它做什么？動(dòng)畫？選擇器？事件委派？基于zepto的插件？可能大部分人就是用個(gè)選擇器吧。但是移動(dòng)端的原生選擇器方法應(yīng)有盡用，原生的完全夠用，包括事件和委派，一共寫起來不超過10幾行的東西，引入一個(gè)框架不值得。再說mvc的框架，如果不使用離線存儲(chǔ)，我是反正不敢想沒wifi的情況下體驗(yàn)如何，外加移動(dòng)端真的是否需要分層這種處理不說，主要還是看業(yè)務(wù)場景。

套殼的那種上面說了，框架隨便用，因?yàn)樽銐驈?fù)雜，但是普通移動(dòng)端開發(fā)，我個(gè)人是不推薦使用的，可以直接上原生的來寫，最多來一個(gè)模塊化工具。我下面就說說自己是怎么做的吧。

手機(jī)端對ES5的特性已經(jīng)全部都支持的很好了，參考：
xiaojue/ES-shim · GitHub
這里的api特性，只實(shí)現(xiàn)了一部分，但是其實(shí)平時(shí)對數(shù)據(jù)的處理，對象的處理，已經(jīng)完全足夠。我不說優(yōu)缺點(diǎn)，我只說，移動(dòng)端這些都是純天然的而已。

然后是我們對手勢的處理，zepto中有幾個(gè)很有用的事件，swipe，swipeLeft，right，up，down，一類的，還有tap，我們可以看下zepto的源碼：
zepto/touch.js at master · madrobby/zepto · GitHub
我們真的所有場景都需要所有的功能么，tap，doubletap，有多少人用了。。用到的時(shí)候，也是非常好實(shí)現(xiàn)的功能。我推薦直接手寫，或者自己寫一個(gè)swipe的基類，也不會(huì)比zepto的touch.js多太多，而好處是我們可以讓它貫穿我們的項(xiàng)目，作為一個(gè)base類使用，當(dāng)然我不是噴zepto多余，它很多代碼做了兼容處理，但是就目前我們的業(yè)務(wù)來說，我們只需要考慮webkit，只需要考慮幾個(gè)特定國產(chǎn)瀏覽器，因?yàn)檫@是統(tǒng)計(jì)數(shù)據(jù)說了算。

沒了框架，我們就不能寫代碼了么？移動(dòng)端開發(fā)，我覺得更考驗(yàn)的是前端的基本功，只要基本功扎實(shí)，其實(shí)都是很簡單的需求，正因?yàn)槎际亲约阂恍幸恍袑懙?，遇到詭異問題就更好解決，而不再需要糾結(jié)于，到底是我做錯(cuò)了，還是框架錯(cuò)了這個(gè)問題。

我不止一次的修改過iscroll的源碼來適應(yīng)和“滿足”我們的測試。。。比如ios下用了iscroll，a標(biāo)簽無法點(diǎn)擊跳轉(zhuǎn)，很多人遇到過吧，不看文檔你還真是一時(shí)不知道怎么解決，iscroll由于禁止了頁面原生的滾動(dòng)，很多本來很簡單得東西復(fù)雜化了，而我們需要的是什么？一個(gè)下托刷新？一個(gè)慣性滾動(dòng)特效？開什么玩笑，原生的也沒幾行啊。。。對于一個(gè)寫了多年pc端的前端來說我相信徒手寫個(gè)下托刷新禁止頁面慣性反彈的代碼，應(yīng)該不復(fù)雜吧？這里給個(gè)思路，比如我們檢測touchmove的位置快到達(dá)頁面【或者容器】底部的時(shí)候，阻止touchmove，做容器或者頁面translate移動(dòng)，再在下部埋一個(gè)loading，touchend之后再做緩動(dòng)回復(fù)，應(yīng)該普通前端都能做到。

再說一個(gè)常用的移動(dòng)端框架，swipe.js 做幻燈用的，我相信幻燈片做pc端得前端應(yīng)該每個(gè)人都寫過不下5遍了吧。只是事件換了，當(dāng)然移動(dòng)端有移動(dòng)端自己需要處理的問題，但是我使用swipe框架的經(jīng)歷也是很痛苦的，比如無法很好的設(shè)置滾動(dòng)過的距離，自定義緩動(dòng)效果，還有無法它自己本身帶的一些問題，比如橫豎屏的時(shí)候復(fù)位問題，動(dòng)態(tài)插入子節(jié)點(diǎn)重排等，讓我第一次用的時(shí)候越開發(fā)越傷心，后來干脆也是自己實(shí)現(xiàn)。

所以其實(shí)，1，我們的需求，那些移動(dòng)端框架不一定滿足我們。2，太大，太復(fù)雜，太難調(diào)試。3，需求其實(shí)本身不復(fù)雜，只是我們想偷懶了。

有點(diǎn)跑題，這個(gè)標(biāo)題說是js和css的選擇，js的立場我足夠明確了，如果簡單功能，不需要js框架，原生足夠，已經(jīng)做得很好，下面說說css。

首先，做pc我們都需要一個(gè)reset或者common，我共享下我們的，

https://gist.github.com/xiaojue/8bac56fb488532e7857f

當(dāng)然里面有一些我們特殊的顏色字體，我css并不是特別好，我簡單的重復(fù)一下我們css同學(xué)的一些注意要點(diǎn)，可能不全：

這其中字體的選擇是根據(jù)平臺(tái)來做的，我們平時(shí)用控制臺(tái)模擬開發(fā)的時(shí)候是沒有ios或者android系統(tǒng)字體的，但是你不設(shè)置又很丑，所以基本是從電腦支持，到移動(dòng)端支持這個(gè)順序排列的。

下面截圖幾個(gè)wiki：







還有很多，我只找一些我認(rèn)為可能知道的人少一些的，我們的wiki還有很多，我css并不太好，這部截自同事的wiki貢獻(xiàn)。

css這個(gè)方面的東西，我不好多說，畢竟我承認(rèn)我css一般，但是有幾個(gè)原則可以提煉出來的就是：
1，很多坑的造成是對原生屬性的掌握程度不熟練或者不知道有這個(gè)特性。
2，很多屬性極限突破可以使用縮放，傾斜這種手段來hack，比如最小字體，比如各種自己畫的偽類圖標(biāo)。
3，能css畫的不要用圖。
4，大小需要自適應(yīng)的圖標(biāo)做成字體的不要畫。
5，能flex布局的不要用浮動(dòng)，不要用絕對定位（不利于頁面布局的擴(kuò)展）

本來還有幾個(gè)比較典型得css案例，這個(gè)找機(jī)會(huì)在其他答案里說吧，都是上周css比較屌的同事分享的，我也受益匪淺?？傉f就是移動(dòng)端的css的寫法和pc相差甚遠(yuǎn)，而且技術(shù)含量更高了，可喜的是兼容性問題少了，更多的是如何處理的更好擴(kuò)展和精簡。

4，模塊化移動(dòng)端的常見組件。

我只說我們非業(yè)務(wù)方面的，可以抽象出來的，可能和公司業(yè)務(wù)場景掛鉤。
1，touch對應(yīng)的swipe事件。
2，各種滑動(dòng)翻頁效果。
3，簡單的小游戲框架。
4，視頻和音頻的包裝。
5，各種lazyload。
6，各種keyframes效果收集。
7，拉拽刷新。

其實(shí)很多pc要有的mobile端也都有，比如浮層，tip，氣泡，分享，添加主屏一類，可能和業(yè)務(wù)關(guān)聯(lián)太多，就不一一列舉了。這部分的組件其實(shí)市面上也沒有太多開源的比較簡易的，大部分都是又支持pc，又支持mobile，導(dǎo)致了很多冗余，或者質(zhì)量和需求，api不過關(guān)，導(dǎo)致很難擴(kuò)展，各家都是自己寫。比如在微信的webview里分享和在qq的webview分享，和在普通頁面的分享，在微博的webview里分享，提示和實(shí)現(xiàn)的方法都不一樣，但是其實(shí)完全都是可以抽象成一個(gè)公共的東西的，我的團(tuán)隊(duì)也在做這方面積累。

這個(gè)再安利一下，我做的一個(gè)做劃屏活動(dòng)頁的組件：
xiaojue/EasySlide · GitHub
慢慢我也會(huì)開源我們內(nèi)部抽象好的移動(dòng)端組件出來的。

5，移動(dòng)端的性能優(yōu)化和統(tǒng)計(jì)。
性能優(yōu)化必須建立在統(tǒng)計(jì)的基礎(chǔ)上，否則都是耍流氓，所以先說統(tǒng)計(jì)。

目前我的做法和pc差不多，監(jiān)控一些前端關(guān)注的時(shí)間點(diǎn)，首屏，doc ready，window ready，css ready，實(shí)現(xiàn)統(tǒng)計(jì)方法和pc也都一樣，應(yīng)該各個(gè)公司都有，我簡單說下前端實(shí)現(xiàn)首屏統(tǒng)計(jì)如何做：

我的思路是，首屏的圖加載完，即首屏完成，首屏無圖，最接近首屏的dom節(jié)點(diǎn)ready的時(shí)間點(diǎn)為首屏?xí)r間，我們可以在load的時(shí)候和document ready的過程之間檢測這幾個(gè)臨界，來收集首屏的完成時(shí)間，當(dāng)然很不準(zhǔn)啦，但是也是有一些參考價(jià)值的。。。

有了數(shù)據(jù)，我說一下移動(dòng)端的統(tǒng)計(jì)極值問題，舉個(gè)例子，我們手機(jī)打開一個(gè)網(wǎng)頁，還沒有l(wèi)oad完成，切到了后臺(tái)，這個(gè)時(shí)候腳本是不會(huì)執(zhí)行的了，過了幾小時(shí)，幾天再回來的數(shù)據(jù)，我們都能收集到，這部分屬于垃圾數(shù)據(jù)，是需要算平均值的時(shí)候去除的。這點(diǎn)和pc不太一樣。

然后是性能優(yōu)化建立在均值性能指標(biāo)上的，我們盡快的提升首屏和win load的時(shí)間即可，原則和做法和pc一致，當(dāng)然，移動(dòng)端不是資源越合成一個(gè)越好，我們的實(shí)踐是分散成不同的幾個(gè)資源下載，總時(shí)間比較快，比如活動(dòng)頁面，h5小游戲頁都是這樣。可以統(tǒng)一把資源圖拆開加載，然后增加loading即可。

----我還在奮力思考和編寫中-----今天先到這里了。。。。【這里還有一個(gè)點(diǎn)，我想討論一下是mobile的cache的利用率問題，這個(gè)明天我詳細(xì)說，決定找些權(quán)威的數(shù)據(jù)或者自己做下測試再開始寫】

6，移動(dòng)端網(wǎng)頁布局方法與pc的差異。

主要是css方面，外加如何做到同一url，不同客戶端展現(xiàn)不一致的做法，俗稱pc和mobile都兼容。還有會(huì)說一下rem的相關(guān)用法和一段比較經(jīng)典的rem.js

今天有空來更新一下這個(gè)rem在移動(dòng)端布局的一個(gè)用法：）（20151013更新）

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

好了，概念有了，那么做布局的時(shí)候我們怎么用呢，大家應(yīng)該用過的都知道，移動(dòng)端的字體默認(rèn)為16px，那么1rem我想表示為10px的話，我們就需要 10 % 16 = 0.625 即為62.5%，這樣就可以比較方便的把設(shè)計(jì)稿里的px轉(zhuǎn)換成rem單位來做到自適應(yīng)了。這樣無論用戶如何設(shè)置電腦或者手機(jī)的默認(rèn)字體大小，設(shè)置為rem的單位的長度都會(huì)隨比例變化。

這是一種常規(guī)做法，其實(shí)換個(gè)角度我們還可以這樣用：

我們想象一個(gè)設(shè)計(jì)稿寬度為640，800，1200px等尺寸時(shí)，我們?nèi)绾蝸砜焖偻瓿身憫?yīng)式的布局呢？
百分比？flex？這些還是有些復(fù)雜的。

后來發(fā)現(xiàn)，柵格等比縮放整個(gè)設(shè)計(jì)稿看起來是個(gè)更簡單粗暴的方法。而且正好可以利用rem這個(gè)比例變化單位。

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

比較好理解，我們首先根據(jù)psd的設(shè)計(jì)稿寬度設(shè)置一個(gè)基值，然后我們js獲取到當(dāng)前窗口的寬度值，然后把這個(gè)設(shè)計(jì)稿寬度除以100柵格化一下，獲得一份的寬度數(shù)，之后再用真實(shí)窗口的寬度除以這個(gè)一份的寬度，拿到就是我們需要給html設(shè)置的fontsize的px值。

這樣我們只需要把對應(yīng)psd里的px單位除以100，就得到了任何寬度環(huán)境下的rem值。當(dāng)然實(shí)際發(fā)現(xiàn)有些瀏覽器這個(gè)rem單位是存在bug的，比如比例值不準(zhǔn)，那么我們就需要獲得這個(gè)不準(zhǔn)的比例再轉(zhuǎn)換成準(zhǔn)的再賦值html的fontsize，可見calcTestDom函數(shù)，之后再處理一下旋轉(zhuǎn)屏幕時(shí)候的情況，resize時(shí)候的情況就好了。

這樣我們在做一些活動(dòng)專題頁面時(shí)，只需要引入這段js，在頁頭設(shè)置一個(gè)設(shè)計(jì)稿寬，然后對著設(shè)計(jì)稿一頓瘋狂的px除100來定位就好了。。比設(shè)置成62.5%的方式要更好（1，修復(fù)了瀏覽器bug，2，轉(zhuǎn)換單位更方便直觀，px/100即可）

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

這部分還在想怎么說比較通俗易懂，哪些組件是非常典型得，需要我回去慢慢想想，找?guī)讉€(gè)實(shí)際的對比例子。

8，一些常見的坑。

分享一下內(nèi)部wiki的經(jīng)典移動(dòng)端坑和解決辦法。（不會(huì)太多，別抱太大期待了。。）

9，適配【機(jī)型，瀏覽器】的方法和選擇。
1，統(tǒng)計(jì)說話。
2，調(diào)試方法。

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

幾個(gè)比較經(jīng)典的調(diào)試方法和工具介紹。

慢慢壘，先補(bǔ)提綱，5678910都沒寫。。。