整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
在日常開發(fā)中，經(jīng)常需要根據(jù)設(shè)備的類型來做不同的適配或邏輯處理。特別是在移動端開發(fā)中，判斷用戶使用的設(shè)備類型是手機還是平板電腦是非常常見的需求。本文將介紹使用 JavaScript 判斷設(shè)備類型的方法，并提供相應(yīng)的代碼示例。
User-Agent 是瀏覽器在發(fā)送 HTTP 請求時，會在請求頭中附帶的一個字符串，其中包含了有關(guān)瀏覽器和操作系統(tǒng)的信息。我們可以通過解析 User-Agent 字符串來判斷設(shè)備類型。
// 獲取 User-Agent 字符串
const userAgent = window.navigator.userAgent;
// 判斷是否是手機
const isMobile = /Mobile/i.test(userAgent);
// 判斷是否是平板電腦
const isTablet = /Tablet/i.test(userAgent);
上述代碼首先通過 window.navigator.userAgent 獲取到當前瀏覽器的 User-Agent 字符串。然后通過正則表達式匹配判斷是否是手機或平板電腦。
另一種判斷設(shè)備類型的方法是根據(jù)屏幕寬度進行判斷。通常，手機的屏幕寬度比較窄，而平板電腦的屏幕寬度較寬。
// 獲取屏幕寬度
const screenWidth = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
// 判斷是否是手機
const isMobile = screenWidth < 768;
// 判斷是否是平板電腦
const isTablet = screenWidth >= 768 && screenWidth < 1024;
上述代碼中，我們通過 window.innerWidth、document.documentElement.clientWidth 和document.body.clientWidth 來獲取到屏幕寬度，然后根據(jù)寬度范圍判斷設(shè)備類型。
下面是一個完整的示例代碼，演示了如何根據(jù)設(shè)備類型來顯示不同的提示信息：
// 獲取 User-Agent 字符串
const userAgent = window.navigator.userAgent;
// 獲取屏幕寬度
const screenWidth = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
// 判斷是否是手機
const isMobile = /Mobile/i.test(userAgent) || screenWidth < 768;
// 判斷是否是平板電腦
const isTablet = /Tablet/i.test(userAgent) || (screenWidth >= 768 && screenWidth < 1024);
if (isMobile) {
console.log("您正在使用手機訪問");
} else if (isTablet) {
console.log("您正在使用平板電腦訪問");
} else {
console.log("您正在使用桌面電腦訪問");
以上代碼中，在判斷設(shè)備類型后，通過控制臺打印不同的提示信息。
本文介紹了兩種常見的判斷設(shè)備類型的方法，并提供了相應(yīng)的代碼示例。通過這些方法，我們可以根據(jù)設(shè)備類型來進行不同的適配或邏輯處理，提升用戶的體驗。在實際開發(fā)中，可以根據(jù)具體需求選擇合適的方法來判斷設(shè)備類型。
如若轉(zhuǎn)載，請注明出處：開源字節(jié) https://sourcebyte.vip/article/348.html
app 內(nèi)嵌H5頁面，個人中心頁面模板，包含 列表 按鈕 圖片 icon 搜索 布局 上傳 對話框 。
手機演示地址：http://www.17sucai.com/preview/10221/2017-01-20/ceshi/index.html — my-read.html — my-secure.html — my-put.html — my-up.html
手機演示地址：http://www.17sucai.com/pins/demoshow/22887
手機版大氣信息管理系統(tǒng)界面模板
手機演示地址：http://www.17sucai.com/pins/demoshow/22475
藍色的手機登錄模板
手機演示地址：http://www.17sucai.com/pins/demoshow/22480
蘋果風(fēng)格
手機演示地址：http://www.17sucai.com/pins/demoshow/20946
幾篇文章已經(jīng)基本上把Web App和Native App的優(yōu)劣講清楚了。
不過還是想提醒大家注意，Web App，現(xiàn)在有時候也稱為輕應(yīng)用，不僅是通過瀏覽器就能打開的應(yīng)用。現(xiàn)在隨著HTML 5在手機端的優(yōu)越性，已經(jīng)慢慢稱為了Web App的主流。Web App除了出現(xiàn)在PC的瀏覽器中，還大量出現(xiàn)在手機瀏覽器中或一些平臺級應(yīng)用中，例如微信中大量的交互內(nèi)容，都屬于Web App的范疇。
HTML 5取代的只是之前的HTML和Flash
HTML5是一種徹徹底底的Web技術(shù)，包括最新的網(wǎng)頁端的腳本語言HTML5語言、Javascript 2.0和CSS 3.0這三部分。HTML5的主要目標是取代原有的腳本語言HTML，提供更好的交互效果和更豐富的API，以及更高的運行效率。
HTML5取代的是很多很多年前產(chǎn)生的HTML版本。熟悉互聯(lián)網(wǎng)的人肯定清楚，互聯(lián)網(wǎng)可謂日新月異，但是支撐整個互聯(lián)網(wǎng)的語言HTML，在HTML5以前卻變化不大，這個嚴重阻礙了互聯(lián)網(wǎng)本身的發(fā)展，這才是產(chǎn)生HTML5的一個根本原因。還有以前也常見Flash的應(yīng)用場景，會被HTML5取代。
現(xiàn)在對HTML5的指責(zé)，主要是針對HTML5的性能，也就是常說的“用戶體驗”這一方面，由于HTML5是腳本語言，再加上Javascript 2.0實際上還是單線程運行的，運行的效率上客觀地講，確實比不上Native App。但是，如果用HTML5做前端的輕應(yīng)用，哪怕是在手機上實現(xiàn)，性能已經(jīng)足夠了，這也是為什么越來越多基于HTML5的輕應(yīng)用出現(xiàn)的手機端的原因。另外，隨著瀏覽器對HTML5的支持越來越好，手機CPU速度越來越快，以及各種引擎對HTML5的優(yōu)化，用戶體驗會越來越好。
因此，很多人主觀的把整個Native App行業(yè)和HTML5對立起來，這本身就是有問題的。 另外，反觀Native App，開放應(yīng)用數(shù)量龐大，小團隊眾多（賺錢的很少），同質(zhì)化嚴重，模仿門檻低，刷榜問題嚴重，都困擾了Native App的發(fā)展。
HTML5的新一輪高速增長：微信
下圖是今年下半年的HTML5搜索指數(shù)，有一個明顯的提升。除了基于HTML 5開發(fā)的Web本身，隨著微信的發(fā)展，大量的基于HTML5的內(nèi)容找到了出口，內(nèi)容數(shù)量瘋狂增長中！而現(xiàn)在對HTML5的需求還遠遠沒有得到釋放，相信很快很多其它的平臺也會支持HTML5的內(nèi)容，讓我們拭目以待！
在社會化媒體和自媒體的大環(huán)境下，客戶把更大精力放在實用的微信輕應(yīng)用上，而越來越少直接花錢購買Native App，道理很簡單，如果采用Native App的方式，我要傳播到1000人，并讓他們下載安裝是個非常難的事兒，但是如果做成輕應(yīng)用往朋友圈里一傳，可能1萬人都很輕易達到。
HTML5慢慢演變?yōu)橐粋€剛性需求，在需求旺盛的帶動下，前端程序員/HTML5工程師的工資水平原來越高，而且好的還非常難求。另一方面，Android和iOS開發(fā)工程師，市場需求已經(jīng)明顯放緩。
更有大量的HTML5的公司順勢而生，做大量的Web App應(yīng)用。產(chǎn)生HTML5內(nèi)容的成本也越來越低，伴隨這技術(shù)的發(fā)展，包括國內(nèi)外都有大量的可視化工具可以快速生成基于HTML5的Web App應(yīng)用。
對于HTML5被Facebook棄用這件事，除了記住扎克伯格的懊悔之外，我們不能忽略的是還有一篇報道，如下圖所示。
這篇報道說明了什么？并不是Facebook本身不用HTML5了，而是Facebook這個Native App不直接采用HTML5的方式開發(fā)。這兩者的區(qū)別可就太大了，這也引出我的下一個問題。
HTML 5適合小公司，適合做內(nèi)容
我是HTML5的堅定支持者，但是我至少現(xiàn)在還不認為HTML5可以做所有東西，至少一些太過復(fù)雜的重度游戲、一些大型的門戶（包括上面說的Facebook）、一些涉及高運算或復(fù)雜算法的應(yīng)用，我個人認為至少現(xiàn)階段還不適應(yīng)用HTML5去開發(fā)。
所以...HTML5和Native App會走向融合 ！
HTML5 Web App和Native App各有優(yōu)勢，互為補充，能不能不把技術(shù)直接對立起來，而是用技術(shù)的進步來解決技術(shù)還存在的問題，使二者從對立走向融合。而且我個人覺得結(jié)合的場景最好在大型的Native App平臺，并且這些平臺是可以UGC或PGC產(chǎn)生內(nèi)容的。
我們以微信為例，微信這個應(yīng)用本身就是一個Native App，但是在這個巨大的平臺里面，又可以容納海量的HTML5 Web App，這樣的輕應(yīng)用，充分發(fā)揮Native App的運行效率，同時又以海量的Web App來擴充其內(nèi)容，給用戶帶來更豐富的體驗和更優(yōu)質(zhì)的交互內(nèi)容，這樣不是很好嗎？
現(xiàn)在來看一下如果基于HTML5的Web App和Native App融合，形成一種Hybrid App，會給我們帶來什么好處吧：
同時還解決了，海量的Native App利用效率不高的問題，通過Hybrid App內(nèi)部的Web App來動態(tài)提供交互內(nèi)容，而不是安裝按量的Native App應(yīng)用。
另外，由于服務(wù)的統(tǒng)一性，降低了需要學(xué)習(xí)每個Native App的用戶時間成本。
Hybrid App的優(yōu)勢顯而易見，成本低、跨平臺、不用下載-安裝-更新、動態(tài)數(shù)據(jù)、維護容易，而且有現(xiàn)成的內(nèi)容出口。而且我們這里的Hybrid App主要是指在大型平臺化應(yīng)用（Native Platform App）結(jié)構(gòu)之下的Hybrid App，可以理解為1個Native App對應(yīng)N個Web App的結(jié)構(gòu)，或是一個母Native App和N個子Web App的結(jié)構(gòu)，而不是簡單的把Web開發(fā)和Native App開發(fā)做一個結(jié)合。
在技術(shù)上，Hybrid App的架構(gòu)好處也顯而易見，例如，HTML5不能自動播放語音或視頻，但是微信可以。同時，微信也開放各種接口給內(nèi)部的Web App調(diào)用，這樣就擴展了原生的HTML5 Web App的功能，且更好的提供服務(wù)，開發(fā)上也非常簡單。
本文作者是孟智平，VXPLO 互動大師 CEO，郵箱：troy@vxplo.com
致歉：36氪上周發(fā)表的一篇討論HTML5未來的文章《Web與App的未來不是生死之爭，而是融合，騰訊就在這么干》是根據(jù)筆名為Hans的作者（移動互聯(lián)網(wǎng)從業(yè)者，微信號1396255225）之前的投稿修改，調(diào)整了文章結(jié)構(gòu)、更換了標題，導(dǎo)致部分觀點的表述和原文有所出入。在等待Hans郵件審核的時候編輯誤觸發(fā)表，雖然責(zé)任編輯一經(jīng)發(fā)現(xiàn)后馬上撤下，但是還是給Hans本人帶來困擾。對本文對Hans可能造成一切損失表示歉意，同時責(zé)任編輯會承擔相應(yīng)處罰，未來我們也會加強和投稿者的溝通，優(yōu)化流程，保證此類事件不再發(fā)生。再次同時向36氪的讀者和Hans致歉。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
