言

在日常開發中，經常需要根據設備的類型來做不同的適配或邏輯處理。特別是在移動端開發中，判斷用戶使用的設備類型是手機還是平板電腦是非常常見的需求。本文將介紹使用 JavaScript 判斷設備類型的方法，并提供相應的代碼示例。

設備類型判斷方法

方法一：使用 User-Agent 字符串

User-Agent 是瀏覽器在發送 HTTP 請求時，會在請求頭中附帶的一個字符串，其中包含了有關瀏覽器和操作系統的信息。我們可以通過解析 User-Agent 字符串來判斷設備類型。

// 獲取 User-Agent 字符串

const userAgent = window.navigator.userAgent;

// 判斷是否是手機

const isMobile = /Mobile/i.test(userAgent);

// 判斷是否是平板電腦

const isTablet = /Tablet/i.test(userAgent);

上述代碼首先通過 window.navigator.userAgent 獲取到當前瀏覽器的 User-Agent 字符串。然后通過正則表達式匹配判斷是否是手機或平板電腦。

方法二：使用屏幕寬度判斷

另一種判斷設備類型的方法是根據屏幕寬度進行判斷。通常，手機的屏幕寬度比較窄，而平板電腦的屏幕寬度較寬。

// 獲取屏幕寬度

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 來獲取到屏幕寬度，然后根據寬度范圍判斷設備類型。

完整示例

下面是一個完整的示例代碼，演示了如何根據設備類型來顯示不同的提示信息：

// 獲取 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("您正在使用桌面電腦訪問");

以上代碼中，在判斷設備類型后，通過控制臺打印不同的提示信息。

總結

本文介紹了兩種常見的判斷設備類型的方法，并提供了相應的代碼示例。通過這些方法，我們可以根據設備類型來進行不同的適配或邏輯處理，提升用戶的體驗。在實際開發中，可以根據具體需求選擇合適的方法來判斷設備類型。

如若轉載，請注明出處：開源字節 https://sourcebyte.vip/article/348.html

幾篇文章已經基本上把Web App和Native App的優劣講清楚了。

不過還是想提醒大家注意，Web App，現在有時候也稱為輕應用，不僅是通過瀏覽器就能打開的應用?，F在隨著HTML 5在手機端的優越性，已經慢慢稱為了Web App的主流。Web App除了出現在PC的瀏覽器中，還大量出現在手機瀏覽器中或一些平臺級應用中，例如微信中大量的交互內容，都屬于Web App的范疇。

HTML 5取代的只是之前的HTML和Flash

HTML5是一種徹徹底底的Web技術，包括最新的網頁端的腳本語言HTML5語言、Javascript 2.0和CSS 3.0這三部分。HTML5的主要目標是取代原有的腳本語言HTML，提供更好的交互效果和更豐富的API，以及更高的運行效率。

HTML5取代的是很多很多年前產生的HTML版本。熟悉互聯網的人肯定清楚，互聯網可謂日新月異，但是支撐整個互聯網的語言HTML，在HTML5以前卻變化不大，這個嚴重阻礙了互聯網本身的發展，這才是產生HTML5的一個根本原因。還有以前也常見Flash的應用場景，會被HTML5取代。

現在對HTML5的指責，主要是針對HTML5的性能，也就是常說的“用戶體驗”這一方面，由于HTML5是腳本語言，再加上Javascript 2.0實際上還是單線程運行的，運行的效率上客觀地講，確實比不上Native App。但是，如果用HTML5做前端的輕應用，哪怕是在手機上實現，性能已經足夠了，這也是為什么越來越多基于HTML5的輕應用出現的手機端的原因。另外，隨著瀏覽器對HTML5的支持越來越好，手機CPU速度越來越快，以及各種引擎對HTML5的優化，用戶體驗會越來越好。

因此，很多人主觀的把整個Native App行業和HTML5對立起來，這本身就是有問題的。 另外，反觀Native App，開放應用數量龐大，小團隊眾多（賺錢的很少），同質化嚴重，模仿門檻低，刷榜問題嚴重，都困擾了Native App的發展。

HTML5的新一輪高速增長：微信

下圖是今年下半年的HTML5搜索指數，有一個明顯的提升。除了基于HTML 5開發的Web本身，隨著微信的發展，大量的基于HTML5的內容找到了出口，內容數量瘋狂增長中！而現在對HTML5的需求還遠遠沒有得到釋放，相信很快很多其它的平臺也會支持HTML5的內容，讓我們拭目以待！

在社會化媒體和自媒體的大環境下，客戶把更大精力放在實用的微信輕應用上，而越來越少直接花錢購買Native App，道理很簡單，如果采用Native App的方式，我要傳播到1000人，并讓他們下載安裝是個非常難的事兒，但是如果做成輕應用往朋友圈里一傳，可能1萬人都很輕易達到。

HTML5慢慢演變為一個剛性需求，在需求旺盛的帶動下，前端程序員/HTML5工程師的工資水平原來越高，而且好的還非常難求。另一方面，Android和iOS開發工程師，市場需求已經明顯放緩。

更有大量的HTML5的公司順勢而生，做大量的Web App應用。產生HTML5內容的成本也越來越低，伴隨這技術的發展，包括國內外都有大量的可視化工具可以快速生成基于HTML5的Web App應用。

對于HTML5被Facebook棄用這件事，除了記住扎克伯格的懊悔之外，我們不能忽略的是還有一篇報道，如下圖所示。

這篇報道說明了什么？并不是Facebook本身不用HTML5了，而是Facebook這個Native App不直接采用HTML5的方式開發。這兩者的區別可就太大了，這也引出我的下一個問題。

HTML 5適合小公司，適合做內容

我是HTML5的堅定支持者，但是我至少現在還不認為HTML5可以做所有東西，至少一些太過復雜的重度游戲、一些大型的門戶（包括上面說的Facebook）、一些涉及高運算或復雜算法的應用，我個人認為至少現階段還不適應用HTML5去開發。

所以...HTML5和Native App會走向融合 ！

HTML5 Web App和Native App各有優勢，互為補充，能不能不把技術直接對立起來，而是用技術的進步來解決技術還存在的問題，使二者從對立走向融合。而且我個人覺得結合的場景最好在大型的Native App平臺，并且這些平臺是可以UGC或PGC產生內容的。

我們以微信為例，微信這個應用本身就是一個Native App，但是在這個巨大的平臺里面，又可以容納海量的HTML5 Web App，這樣的輕應用，充分發揮Native App的運行效率，同時又以海量的Web App來擴充其內容，給用戶帶來更豐富的體驗和更優質的交互內容，這樣不是很好嗎？

現在來看一下如果基于HTML5的Web App和Native App融合，形成一種Hybrid App，會給我們帶來什么好處吧：

同時還解決了，海量的Native App利用效率不高的問題，通過Hybrid App內部的Web App來動態提供交互內容，而不是安裝按量的Native App應用。

另外，由于服務的統一性，降低了需要學習每個Native App的用戶時間成本。

Hybrid App的優勢顯而易見，成本低、跨平臺、不用下載-安裝-更新、動態數據、維護容易，而且有現成的內容出口。而且我們這里的Hybrid App主要是指在大型平臺化應用（Native Platform App）結構之下的Hybrid App，可以理解為1個Native App對應N個Web App的結構，或是一個母Native App和N個子Web App的結構，而不是簡單的把Web開發和Native App開發做一個結合。

在技術上，Hybrid App的架構好處也顯而易見，例如，HTML5不能自動播放語音或視頻，但是微信可以。同時，微信也開放各種接口給內部的Web App調用，這樣就擴展了原生的HTML5 Web App的功能，且更好的提供服務，開發上也非常簡單。

本文作者是孟智平，VXPLO 互動大師 CEO，郵箱：troy@vxplo.com

致歉：36氪上周發表的一篇討論HTML5未來的文章《Web與App的未來不是生死之爭，而是融合，騰訊就在這么干》是根據筆名為Hans的作者（移動互聯網從業者，微信號1396255225）之前的投稿修改，調整了文章結構、更換了標題，導致部分觀點的表述和原文有所出入。在等待Hans郵件審核的時候編輯誤觸發表，雖然責任編輯一經發現后馬上撤下，但是還是給Hans本人帶來困擾。對本文對Hans可能造成一切損失表示歉意，同時責任編輯會承擔相應處罰，未來我們也會加強和投稿者的溝通，優化流程，保證此類事件不再發生。再次同時向36氪的讀者和Hans致歉。