web移動(dòng)端開發(fā)？
時(shí)間：2023-12-05 06:00:02 | 來源：網(wǎng)站運(yùn)營(yíng)
時(shí)間：2023-12-05 06:00:02 來源：網(wǎng)站運(yùn)營(yíng)
web移動(dòng)端開發(fā)？：感謝邀請(qǐng)
關(guān)于Web移動(dòng)端的開發(fā)，給你一個(gè)詳細(xì)的介紹
移動(dòng)端開發(fā)分類
1 Native App 原生App開發(fā)
優(yōu)點(diǎn)：（1）用戶體驗(yàn)好
（2）性能穩(wěn)定
（3）操作速度快
（4）能夠訪問本地資源（通訊錄，相冊(cè)）
（5）能夠設(shè)計(jì)出色的動(dòng)效，轉(zhuǎn)場(chǎng)
（6）擁有系統(tǒng)級(jí)別的貼心通知或提醒
（7）用戶留存率高
缺點(diǎn)：（1）開發(fā)成本高
（2）維護(hù)成本高
（3）更新緩慢，根據(jù)不同平臺(tái)，提交–審核–上線流程較復(fù)雜。
總的來說，native app開發(fā)從android、ios智能手機(jī)出現(xiàn)就有了開發(fā)技術(shù)，性能體驗(yàn)最優(yōu)，API比較完善，但是學(xué)習(xí)起來難度比較高，開發(fā)成本比較高（跟開發(fā)周期相對(duì)來說比較長(zhǎng)也是有關(guān)系的）。
2 Web App 網(wǎng)頁App開發(fā)
優(yōu)點(diǎn)：（1）發(fā)版完全自控，隨時(shí)更新
（2）跨平臺(tái)，因?yàn)楸旧韥碚f用的是Web的東西，所以可以在任意平臺(tái)上運(yùn)行
（3）成本小，Web頁面嵌入Webview開發(fā)起來速度非?？?，一個(gè)人就可以輕松搞定
缺點(diǎn)：（1）性能差
（2）弱網(wǎng)絡(luò)或無網(wǎng)絡(luò)條件下體驗(yàn)差
（3）適用有展示類需求的項(xiàng)目，但是如果要實(shí)現(xiàn)的功能比較復(fù)雜的話就顯得力不從心
總的來說，相比Native App，Web App體驗(yàn)中受限于網(wǎng)絡(luò)環(huán)境和渲染性能。Web APP對(duì)網(wǎng)絡(luò)環(huán)境的依賴性較大，因?yàn)閃eb APP中的H5頁面，當(dāng)用戶使用時(shí)，去服務(wù)器請(qǐng)求顯示頁面。如果此時(shí)用戶恰巧遇到網(wǎng)速慢，網(wǎng)絡(luò)不穩(wěn)定等其他環(huán)境時(shí)，用戶請(qǐng)求頁面的效率大打折扣，在用戶使用中會(huì)出現(xiàn)不流暢，斷斷續(xù)續(xù)的不良感受。同時(shí)，H5技術(shù)自身渲染性能較弱：對(duì)復(fù)雜的圖形樣式，多樣的動(dòng)效，自定義字體等的支持性不強(qiáng)。因此，應(yīng)注意以下幾點(diǎn)：1.簡(jiǎn)化不重要的動(dòng)畫/動(dòng)效；2.簡(jiǎn)化復(fù)雜的圖形文字樣式；3.減少頁面渲染的頻率和次數(shù)。
3 Hybrid App 混合型App開發(fā)
優(yōu)點(diǎn)：（1）體驗(yàn)好
（2）穩(wěn)定性強(qiáng)動(dòng)態(tài)性強(qiáng)
（3）成本相對(duì)低跨平臺(tái)
缺點(diǎn)：對(duì)團(tuán)隊(duì)技術(shù)棧要求相對(duì)高性能優(yōu)化
Hybrid App就是Native結(jié)合Web混合開發(fā)，Native+JS代碼代表作是cordova前身是phonegap，現(xiàn)在移交給Apache，核心JsBridge，JS調(diào)Java，Java調(diào)JS。因?yàn)榛旌祥_發(fā)，所以體驗(yàn)接近原生、穩(wěn)定性強(qiáng)而且發(fā)版快。
2 Viewport視口
2.1 視口
視口是移動(dòng)設(shè)備上用來顯示網(wǎng)頁的區(qū)域，一般會(huì)比移動(dòng)設(shè)備可視區(qū)域大，寬度可能是980px或者1024px，目的是為了顯示下整個(gè)為PC端設(shè)計(jì)的網(wǎng)頁。這樣帶來的后果是移動(dòng)端會(huì)出現(xiàn)橫向滾動(dòng)條，為了避免這種情況，移動(dòng)端會(huì)將視口縮放到移動(dòng)端窗口的大小。這樣會(huì)讓網(wǎng)頁不容易觀看，可以用meta標(biāo)簽，name="viewport"來設(shè)置視口的大小，將視口的大小設(shè)置為和移動(dòng)設(shè)備可視區(qū)一樣的大小。
在移動(dòng)端用來承載網(wǎng)頁的這個(gè)區(qū)域，就是我們的視覺窗口，viewport（視口），這個(gè)區(qū)域可以設(shè)置高度寬度，可以按比例放大縮小，而且能設(shè)置是否允許用戶自行縮放。
2.2參數(shù)說明
width：寬度設(shè)置的是viewport寬度，可以設(shè)置device-width特殊值
initial-scale：初始縮放比，大于0的數(shù)字
maximum-scale：最大縮放比
minimum-scale：最小縮放比
user-scalable：用戶是否可以縮放，yes或no（1或0）
<!--viewport只有移動(dòng)端才能識(shí)別-->
<!--設(shè)置寬度 設(shè)置成和設(shè)備一樣的寬度(width=device-width)-->
<!--設(shè)置默認(rèn)的縮放比 initial-scale =1.0-->
<!--設(shè)置是否允許用戶自行縮放 user-scalable：no or yes-->
2.3 設(shè)置方法
<meta name="viewport" content="width=device-width,initial-scale=1.0,user-scalable=no">
3 移動(dòng)端適配布局
使用百分比自適應(yīng)布局（流式布局）同時(shí)需要對(duì)移動(dòng)端的viewport視口進(jìn)行設(shè)置，就可以達(dá)到適配的目的。
3.1 流體布局+少量響應(yīng)式
流體布局：使用百分比來設(shè)置元素的寬度，元素的高度按實(shí)際高度寫固定值，流體布局中，元素的邊線（border）無法用百分比，可以使用樣式中的計(jì)算函數(shù)calc()來設(shè)置寬度，或者使用box-sizing屬性將盒子設(shè)置為邊線計(jì)算盒子尺寸。
響應(yīng)式布局：使用媒體查詢的方式，通過查詢?yōu)g覽器的寬度，不同的寬度應(yīng)用不同的樣式塊，每個(gè)樣式塊對(duì)應(yīng)的是該寬度下的布局方式，從而實(shí)現(xiàn)響應(yīng)式布局，響應(yīng)式布局的頁面可以適配多種終端屏幕（pc、平板、手機(jī)）。
3.2 基于rem的布局
rem指的是參照根節(jié)點(diǎn)的文字大小，根節(jié)點(diǎn)指的是html標(biāo)簽，設(shè)置html標(biāo)簽的大小，其他的元素相關(guān)尺寸設(shè)置用rem。這樣，所有元素都有了統(tǒng)一的參照標(biāo)準(zhǔn)，改變html文字的大小，就會(huì)改變所有元素用rem設(shè)置的尺寸大小。
手機(jī)和PC端分開來寫，只是 狹義響應(yīng)式設(shè)計(jì) 的一種發(fā)展和延伸罷了。他們的界限沒有，也并不需要那么清晰。移動(dòng)端/PC端網(wǎng)頁開發(fā)建議
根據(jù)你的產(chǎn)品特點(diǎn)，進(jìn)行兩種不同的設(shè)計(jì)，根據(jù)你的設(shè)計(jì)需求，選擇合適的技術(shù)方案。
A與B不是硬幣的正反面，它們?yōu)榱私鉀Q同一個(gè)問題而生，它們是同一種思想的延伸。其實(shí)無論是什么解決方案，我們先來看看我們想要解決的問題：
“屏幕尺寸越來越多，不同設(shè)備的交互特質(zhì)也有著巨大的差別，我們希望我們的網(wǎng)站能夠在移動(dòng)手機(jī)、平板、桌面電腦，在鍵鼠、觸摸、無障礙設(shè)備上都有優(yōu)秀的用戶體驗(yàn)。所以，我們需要網(wǎng)站的用戶界面在不同的平臺(tái)上有所不同?！?/b>
那怎么做呢，一個(gè)解決方案應(yīng)運(yùn)而生：
響應(yīng)式設(shè)計(jì) (Responsive Web design)狹義上，我們把主要依靠前端 CSS （包括 Media Query 媒體查詢，百分比流式布局，網(wǎng)格與Typography系統(tǒng)……）來對(duì)各種屏幕尺寸進(jìn)行響應(yīng)的做法，稱之為響應(yīng)式布局，又稱作自適應(yīng)網(wǎng)頁設(shè)計(jì)，或者彈性設(shè)計(jì)。
這種主要依靠CSS的方案有很多優(yōu)點(diǎn)，比如：
設(shè)計(jì)元素很容易被復(fù)用，設(shè)計(jì)成本低前端只需要維護(hù)一套CSS代碼，維護(hù)成本低桌面端與移動(dòng)端的設(shè)計(jì)十分接近，令用戶感到“熟悉”不需要任何服務(wù)器端的支持與業(yè)務(wù)耦合程度低，復(fù)用程度高（ 以至于 Bootstrap、Foundation 等一干框架都跟進(jìn)了這個(gè)解決方案 ）但問題也很明顯，比如：
設(shè)計(jì)需求復(fù)雜時(shí)，前端的開發(fā)成本沒有任何減輕無論是針對(duì)桌面還是移動(dòng)的CSS代碼（甚至圖片資源文件）都會(huì)被同等的下載到客戶端（沒有考慮移動(dòng)端的網(wǎng)絡(luò)優(yōu)化）如果JS不寫兩套，桌面端的交互和移動(dòng)端的交互很難針對(duì)平臺(tái)作出差異
如果你的移動(dòng)用戶對(duì)網(wǎng)站所有的功能和內(nèi)容有著與桌面用戶同等的需求，比如 新聞、報(bào)紙（媒體類）網(wǎng)站，或者活動(dòng)、專題頁等 偏重信息傳達(dá)而輕交互 的網(wǎng)站，那么這個(gè)解決方案其實(shí)恰到好處：
觸摸屏優(yōu)化（胖手指）、減少次要信息…… 這些通過 CSS 解決就夠了。
但是，如果我想要做更多的 「移動(dòng)化設(shè)計(jì)」，比如 減少信息層級(jí)、增強(qiáng)手勢(shì)操作、讓網(wǎng)頁更接近一個(gè)Native App ？
好吧，為了更復(fù)雜的需求，為了我們的網(wǎng)站能更牛逼的 「響應(yīng)」 各個(gè)平臺(tái)，
又有了這些解決方案：
服務(wù)器端（后端）：
RESS （Responsive Web Design with Server Side Components）通過服務(wù)器端組件的響應(yīng)式網(wǎng)頁設(shè)計(jì)
提倡 RESS 的人認(rèn)為：基于前端 CSS 的響應(yīng)式方案只是一種妥協(xié)：
“ UI 只是在很被動(dòng)的進(jìn)行「調(diào)整」，而不能真正達(dá)到各個(gè)平臺(tái)的最優(yōu)。好的設(shè)計(jì)應(yīng)該達(dá)到「這個(gè)設(shè)備該有的體驗(yàn)」（Device Experiences）。 ”
RESS 的本質(zhì)還是服務(wù)器端動(dòng)態(tài)的生成，返回 HTML、JS、CSS、圖像等資源文件，但是只使用同一個(gè) URL 就可以提供給移動(dòng)端定制化更強(qiáng)的網(wǎng)頁，同時(shí)還大大節(jié)省了網(wǎng)絡(luò)資源。
前端（主要是JS），比如：
在 JavaScript 中實(shí)現(xiàn)兩套邏輯，分別兼容鍵鼠、觸摸設(shè)備通過 UA、特性檢測(cè) 在前端做設(shè)備判斷，對(duì)資源進(jìn)行異步加載，渲染不同模版通過 特性檢測(cè) 在前端做設(shè)備判斷，使用不同的業(yè)務(wù)邏輯前端的模塊化也可以幫助解決這個(gè)問題，比如針對(duì)不同的平臺(tái)加載不同的模塊……
這下，我們的網(wǎng)站可以更牛逼的 “響應(yīng)” 各個(gè)平臺(tái)了。
（對(duì)，我還是稱之為響應(yīng)：這的確還是在“響應(yīng)”啊 ，不是嗎？）
但是等下……
后端開發(fā)成本上去了，前端開發(fā)成本也上去了，配合著估計(jì)產(chǎn)品、設(shè)計(jì)資源也都上去了，那我們?yōu)槭裁床桓纱喟?移動(dòng)設(shè)備網(wǎng)站 和 桌面設(shè)備網(wǎng)站 分開呢??？
是啊，如果你的需求真的都到這一步了，你的移動(dòng)網(wǎng)站也應(yīng)該可以被稱作 WebApp 了。這種時(shí)候，把移動(dòng)設(shè)備網(wǎng)站徹底分開或許真的是更好的選擇。
開發(fā)資源如此充足，你還可以讓專門的團(tuán)隊(duì)來維護(hù)移動(dòng)端的網(wǎng)站。
（嗯，BAT 就是這么干的）
于是又一個(gè)概念來了：
獨(dú)立的移動(dòng)版網(wǎng)站 （按題主的話來說：手機(jī)和PC端分開來寫）不過，它有那么獨(dú)立么？
我們知道，我們?cè)L問網(wǎng)站是通過 URL 來訪問的。
將移動(dòng)網(wǎng)站 和 桌面網(wǎng)站 分開，如果不使用 RESS 技術(shù)，往往也就意味著要維護(hù)兩個(gè)URL（不同的二級(jí)域名）
難道我們要讓所有桌面用戶自覺訪問 http://taobao.com ，所有 移動(dòng)用戶 都自覺訪問 http://m.taobao.com ？
不可能吧
于是，我們還是得依靠前端或服務(wù)器端的一次 “響應(yīng)”（設(shè)備檢測(cè)），做 URL 重定向，才能將不同設(shè)備的用戶帶到那個(gè)為他們準(zhǔn)備的網(wǎng)站。
在線咨詢