移動前端和web前端的區別是什么?

移動客戶端的開發類型(因為我是個前端所以我是站在前端立場上來說的哈),主要是三種:Native App(原生APP),也就是完全使用移動設備系統語言寫的客戶端,iphone iPad就是純Object-C,安卓就是純JAVA, 就是用戶看到的界面啦體驗到的交互啦都是原生的。這是性能最棒的開發方式,但靈活性就沒下面的好。

web App, 這個就是在移動瀏覽器里打開的,純html+CSS+JS,說白了就是個網頁,只不過非常的富應用,比如手機瀏覽器訪問的GMAIL啥啥的。但說白了就是在瀏覽器里打開的頁面。。ios支持可以在桌面創建訪問的快捷方式,但是說到底還是打開Safari跑。。而且對設備硬件的接口什么的挺薄弱。

Hybrid App.[HTML5 in Mobile devices] 我覺得這個更為合適一些。實際上是使用原生寫了一個容器,然后使用HTML+CSS+js來實現用戶界面和交互。Web App的短處便可以克服(因為自己寫的容器可以輔助暴露偏底層的接口,比如本地存儲或者麥克風控制之類),同時比起純原生的java或者object-c開發靈活性要高(更新可以更快更迅速,也不依賴于市場,因為說白了,就是自己下載更新網頁資源。。)實際上這種方式已經不限于移動端。。豌豆莢其實是個pc端的hybrid app 哇~~~ 而且說實在的,桌面開發的性能就現在來說要比移動好很多。。

以上三種開發方式的比較和分析谷歌里面一搜一大堆我就不廢話啦哈。我記得2011年的Google io上就有一場talk是Android native和web app等開發方式的大PK。??戳┕こ淌Τ郴故嗆苡幸饉嫉?。我順手找著了 [ youtube.com/watch? ]

作者:程慕
鏈接:https://www.zhihu.com/question/20269059/answer/21502610
來源:知乎

1,普通pc端開發與移動端開發區別。先說背景,我大言不慚的說一下,我pc端的前端開發干了有快4年多,不算大牛,也算一個標準的前端開發工程師吧,可憐的是我2015年之前做過的移動端項目不超過1個。。所以幾乎經驗為零。我對這個神秘又被炒的火熱的名字迷惑了很久,移動前端開發工程師,h5前端開發工程師,native前端開發工程師,Hybrid前端開發工程師,臥槽感覺屌屌的有木有啊。。


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

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

這么一比,是不是感覺,移動端開發簡單多了?

沒錯,我轉了之后發現還真是呢。。?!凈褂械閾〖ざ?/p>

pc,我們需要考慮什么呢?有點開發經驗的同學都知道,ie6-11,firefox,chrome,safari都得兼容的吧。哪個都夠你吃一壺的,無論是css還是js。
mobile的網頁開發,我們需要考慮什么呢?
就目前來說,我們只需要考慮webkit內核的瀏覽器和chrome,uc,qq,小米手機瀏覽器就好了。。?!競竺嫣匾饣崴嫡餳鋼還榔髂睦飳帕恕?/p>

相比較而言,除了經驗是0以外,需要兼容的東西還是少了,少了,少了呢。

ok,單純說pc和移動端開發的區別,其實也就是這個,可以簡單的概括來說,mobile端的網頁開發比pc端的網頁開發,更簡單一些?!疽趁嫘×稅?,裝的東西少了,css和html寫的少了吧】交互簡單一些【滑動,觸屏,手勢,平時看看手機你還能有啥特殊操作?】

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審核發版很慢。

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

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,我共享下我們的,
gist.github.com/xiaojue
當然里面有一些我們特殊的顏色字體,我css并不是特別好,我簡單的重復一下我們css同學的一些注意要點,可能不全:
6d0fe78ed5e4b85452ec332a0b284cf3_b這其中字體的選擇是根據平臺來做的,我們平時用控制臺模擬開發的時候是沒有ios或者android系統字體的,但是你不設置又很丑,所以基本是從電腦支持,到移動端支持這個順序排列的。

下面截圖幾個wiki:
485529afa9338f24bdb0e6af3af5aeba_b
2377c617322354461979274b8bf26cae_b
992499c563a3a461778077450e204743_b6c55898274e9641cb678a3a8f998f410_bebbc3d81f6d395ca788c17161a339bda_b還有很多,我只找一些我認為可能知道的人少一些的,我們的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都兼容?;褂謝崴狄幌?span class="wp_keywordlink" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; font-size: inherit; line-height: inherit; font-family: inherit; vertical-align: baseline;">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:
gist.github.com/xiaojue

比較好理解,我們首先根據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的差別。

幾個比較經典的調試方法和工具介紹。

慢慢壘,先補提綱,5678910都沒寫。。。

作者:小爝
來源:知乎


上一篇: 怎么學JavaScript?

下一篇: 前端開發者進階之路

分享到: 更多
二人麻将规则讲解 北京pk拾赛车软件下载 塞子比大小怎么玩 单双大小规律 重庆时时彩国家不管吗 销售单打印软件 麻将单机版 山东时时官方开奖 二人三足游戏规则 重庆彩开奖号码官方 pc蛋蛋在线计划软件下载 ag假的不能再假 十分快3稳赚公式 捕鱼达人2内购破解版安卓版 欢乐生肖开奖官网走势图 双色球投注技巧18种