㈠ web網站怎麼獲取訪問的移動設備的屏幕大小
相比較桌面端，用戶越來越多的從移動設備端訪問網頁，這已經不是什麼新鮮事。然而開發者還是需要努力去讓網站更好的適應現在的移動設備，與此同時，從谷歌最近宣布的消息可以看出，它可能會懲罰那些不能為移動設備用戶提供良好用戶體驗的網站，這也迫使開發者努力做好這方面事宜。本文介紹了一些技巧可以幫助你更好的提供良好的移動用戶體驗。 以下為譯文： 最近，谷歌員工暗示，不能提供友好用戶體驗的網站將受到來自谷歌搜索通信量的懲罰，谷歌在最近幾年已經介紹了多個演算法的變化，傷害了許多網站的流量。 不過谷歌的懲罰不應該是你努力使網站友好的主要動機，你的主要動機應該是為你的用戶提供他們想要的東西，為他們提供最好的用戶體驗。所以確保你的網站友好的對象是移動用戶，而不是谷歌。 選擇一個移動方案，著眼於更好的滿足網站用戶的需求 這里主要有四個方法可以為用戶提供更好的移動用戶體驗： 1. 創建一個單獨的手機網站 如果你想提供一個不同於桌面網站用戶體驗的移動用戶體驗，創建一個單獨的網站，讓移動用戶只有一個選擇。 這個解決方案可能在某些情況下有意義，但是由於其過程類似於建立一個全新的網站，因此許多Web開發者都避免這種方法。 由於谷歌認為這樣的移動用戶網站是不同於桌面網站的另一個網站，所以你應該在桌面網站設置一個rel=alternate鏈接tag，類似於： 而在移動網站頁面應包含rel=canonical鏈接tags，類似於： 2. 動態服務 移動和桌面網站不同URL的存在可能會給用戶造成一些混淆。另一方面，僅從屏幕寬度來判斷用戶設備是否是移動設備並不是一個可靠的方法。 因此你或許可以考慮動態服務，它可以用相同的URL服務於移動和桌面網站，只需根據用戶設備提供不同的HTML。 這種方法有點復雜，因為你需要有能力檢測用戶所使用設備的類型，如User-Agent(瀏覽器向伺服器發送的數據頭)。你可以在PHP中實現它(variable $_SERVER['HTTP_USER_AGENT'])，然後你需要查詢資料庫來確定設備尺寸，以此來計算設備是否是一個小屏幕。 當你通過相同的URL為不同的設備提供不同的HTML時，你還需要發送HTTP Vary響應，讓谷歌機器人知道你依賴用戶設備的網站，其工作是不同的，你可以使用下面的方法實現： Header('Vary: User-Agent'); ?> 3. 響應Web頁面 響應Web頁面是指頁面在Web頁面尺寸中適應性的調整變化。這意味著，如果Web頁面改變其尺寸，使用相同HTML代碼的頁面布局將在某種程度下適應本身。 在實踐中，不僅不同尺寸屏幕上出現的頁面緯度不同，而且這些頁面也需要適應設備方向的變化。比如說，當用戶旋轉設備的時候，如果開啟了重力感應，其頁面也會隨之改變。因為屏幕的寬度和高度發生了改變。 這種方法被稱為響應，因為它使用相同的HMTL動態的適應屏幕的變化，所以它非常的靈活。這種響應通常是使用CSS media查詢來實現，這里有個示例： .c640 { display: block; } @media (max-width: 640px) { .c640 { display: none; } } 4. 移動應用 這種方法可以說是一種互補的解決方案，它包含在可以安裝在用戶設備上的移動應用中，有利用本地設備的能力。而且有些原生功能，用戶無法通過訪問你的網站來獲得，例如向他們的設備發送一些推送通知等。 十個網站響應的技巧 1. 從網站訪問次數最多的頁面開始 如果你使用的是類似Wordpress這樣的常見內容管理系統，你的工作將簡單很多，因為你只需要通過一個響應站點更換主題即可。 如果你有一個基於定製開發的網站，比如說是PHP類的情況下，你將需要為適應移動用戶做一些定製開發。 如果你有一個擁有上千頁面的大網站，還要適應PHP類。你的工作將是巨大的，可能需要數月時間才能完成。因此你需要為這些影響更多用戶的頁面制定一個標准。 在PHP類網站的情況下，很容易確定影響更多用戶的頁面是發布於網站上的包，因為它們獲得更多的訪問量。除此之外，其他被訪問最多的網頁類型就不是很明確了。 因此你需要考慮站點谷歌分析報告，如果你擔心谷歌啟動演算法更新，處罰非移動友好站點，那麼最好看一下網站管理員工具報告，特別是Search Queries和Top Pages。 你可以使用PHP網站管理員工具API類來提取你所需要的頁面報告。 2. 使用瀏覽器開發者工具在小屏幕上預覽你的頁面 一旦你找到了首要處理的頁面，你需要掌控目前可能出現的問題，防止它們呈現在移動設備的屏幕上。 現在的瀏覽器(如Chrome)會提供工具，可以上你在不同的屏幕尺寸上預覽頁面。 3. 使視窗適應屏幕尺寸 在這一點中，你首先要做的事是定義一個可以根據屏幕尺寸調整的視窗。(視窗是指一個頁面的可見部分)，如果一個頁面太大，不適應當前的屏幕解析度，這時可能需要滾動條。 定義視窗可以通過窗口寬度匹配設備寬度來實現，可以通過HTML標記指定的視窗參數。下面的這個例子里，我們定義窗口寬度匹配設備寬度，初始縮放范圍從1開始。這意味著移動瀏覽器將調整頁面寬度縮放比例來適應設備寬度。 4. 從頁眉頁腳開始 當你通過窗口寬度匹配設備寬度定義視窗後，你可能會注意到針對桌面的頁面不適應小型移動設備屏幕，會出現溢出問題。這是你需要構建HTML響應。通常情況下，所有的網站都有帶有頁面和頁腳HTML的頁面。你可以從這里開始，因為你改變這些頁面和頁腳將影響所有的頁面。 5. 使用菜單按鈕收縮導航欄 PHP類網站下，可以使用兩個水平菜單：一個常見的導航，另一個用於記錄用戶操作。 橫向菜單可以利用可用的水平空間的優勢，所以基本上所有的響應頁面，其導航菜單都會有兩個版本：一個是寬屏幕時，整個菜單選項可以水平顯示，另一個則是菜單搜索按鍵加一個搜索欄。 網站使用media查詢來顯示單一類型的導航(或另一個)，下面代碼演示的是HTML和CSS實現該功能的簡化版本： Desktop menu here Mobile menu here @media (max-width: 1024px) { .c1025 { display: none; } } @media (min-width: 1025px) { .u1025 { display: none; } } 用PHP類構建的菜單按鈕使用了一個很好的技巧來避免對JavaScript的需求。它使用一個隱藏的表單復選框來控制下拉菜單的可見性。 下面是使用HTML和CSS渲染這類菜單的簡化版本： All class groups Latest entries Top 10 charts Blog Forums Help FAQ Icon Image here .menu-items { position: absolute; z-index: 1001; background-color: #103754; border-color: #cccccc; border-style: solid; border-width: 1px; padding: 4px; top: 32px; line-height: 36px; } .menu-items a { color: #C3F0FF; font-weight: bold; text-decoration: none; } #navigation-menu { display: inline-block; padding: 6px 10px 0px 10px; } #navigation-menu .menu-items { display: none; } #navigation-button:checked + .menu-items { display: inline-block; } #navigation-menu input[type="checkbox"], #navigation-menu ul span.drop-icon { display: none; } 6. 犧牲不重要頁面元素 完成頁眉頁腳，你還要繼續你的步伐，穿梭於網站每個類型頁面中，按照頁面訪問優先順序(參照前文)。 使用瀏覽器開發工具在小屏幕上預覽頁面，減少視窗分離器寬度，直到頁面元素溢出視窗。 這時你需要找出哪些不重要的頁面元素，你可以使用CSS樣式通過media查詢犧牲和隱藏它們。 下面演示的是media查詢定義逐漸減少點，用於隱藏不同頁面元素： @media (max-width: 1024px) { .c1025 { display: none; } @media (min-width: 1025px) { .u1025 { display: none; } } @media (max-width: 499px) { .c499 { display: none; } } @media (max-width: 799px) { .c799 { display: none; } } @media (max-width: 640px) { .c640 { display: none; } } @media (max-width: 360px) { .c360 { display: none; } } 7. 使用Google Page Speed Insights來解決懸而未決的問題 谷歌驗證一個網站是否移動友好的標准有什麼?在視窗上顯示恰好的可見內容只是其中的一個標准，還有其他一些不太好評估的，比如接觸點的距離(如鏈接和按鈕)。 幸運的是，谷歌提供了一個工具來幫助我們發現需要修復的問題，這只是Google Page Speed Insights工具的一部分。 你只需要輸入一個你製作的頁面URL，它會向你展示一個等級(0%-100%)，讓你知道你的頁面在手機上的可用性等級，它還會顯示該頁面目前所存在的問題。 8. 圖像適應頁面寬度限制 你可能會遇到這樣一個問題，需要適應小屏幕的頁面存在很多的圖片元素。這時你有兩種選擇，一是如前面提到的，犧牲圖片元素;二是自動的調節圖片的寬度和高度，該方法適用於有可用的空間。 第二種方法可以通過將圖片的寬度設置為100%(或其他百分比)來實現，然後將圖片高度設置為自動，以此來保證原始圖片的比例。如下段代碼所示例的那樣： @media (max-width: 55em) { .blog-post-body p img { width: 100%; height: auto; } } 與圖像相關的另一個方面是，如果你的菜單和圖標使用的是小圖像時，當瀏覽器縮放視窗來匹配設備寬度，那些小圖片看起來會很大，如果那些圖片解析度很低的時候，更是會破壞整個頁面的質量。而解決這種問題的一個方法是使用高解析度圖片，設置較小值的寬度來匹配設備。 9. 安全“填充”鏈接和按鈕四周 谷歌工具可能會報告的另一個典型問題是，你的鏈接或按鈕太接近對方了，這很容易導致錯誤操作。你可以利用CSS樣式表“填充”這些鏈接和按鈕的空間，下面是一個簡單的示例： .safe-padding { padding: 2px; line-height: 200%; } 10.使用谷歌網站管理員工具：移動可用性報告 谷歌在Google Webmaster Tools網站上為我們提供了另一種工具：Mobile Usability(移動可用性)。它可以給你一個進程的概念，以及任何你可能或者你認為沒有解決的問題。 這個工具顯示不同類型的問題：觸摸元素太近、小字體尺寸、寬度固定窗口……。它可以給你提供擁有這些問題的頁的總數以及URL。不過工具不會實時報告這些，實際報告大概會延遲一個星期，所以它的報告中或許會存在你已修復的問題。盡管如此，它也是很有用處的，任何頁面的問題都會有一個鏈接，你對此會一目瞭然。 總結 對Web開發者來說，調整網站以適應移動設備是乏味和無聊的任務，遠沒有前端工作給人帶來的興奮。然而這是必須的進行的一項任務。 移動適應工作仍在繼續，只有部分頁面適應了移動設備，所以在未來我們會看到更多的變化。 無論如何，本文是為了分享一些有用的信息給那些正處於網站適應移動設備過程的人們。如果您已經經歷過類似的過程，或者您有其他相比較本文所分享的技巧而言更好的方法。您可以留下您的觀點，分享您的經驗。
㈡ 移動端Web頁面適配方案（整理版）
<meta charset="utf-8">
@(概述)[基本概念|百分比|rem|vw/vh|響應式設計]
移動端web頁面的開發，由於手機 屏幕尺寸 、 解析度 不同，或者需要考慮 橫豎屏 問題，為了使得web頁面在不同移動設備上具有相適應的展示效果，需要在開發過程中使用合理的適配方案來解決這個問題。
早期網頁設計採用 靜態布局 ，通過 <meta> 標簽中的 applicable-device 應用設備標識識別移動設備，即 <meta name = 'applicable-device' content = 'mobile'> ，在 <meta> 標簽中的 viewport 標簽中設置 width ，通過 js 動態修改標簽的 initial-scale 使得頁面等比縮放，剛好占滿整個屏幕。一些文章中有提到靜態布局中頁面各個元素採用 px 為單位，這種方案實現簡單，不存在兼容性問題，但用戶體驗很不友好。
後面出現 流式布局 ，使用百分比 % 定義寬度，高度使用 px 固定，根據可視區域大小實時進行尺寸調整，通常使用 max-width/min-width 控制尺寸范圍過大或者過小。這種方案實現比較簡單，但在大屏手機或橫豎屏切換場景下可能會導致頁面元素被拉伸變形，字體大小無法隨屏幕大小發生變化。
順應不同頁面字體大小展現問題，出現了 彈性布局 。這種布局方案下，包裹文字的元素的尺寸採用 em/rem 為單位，頁面主要劃分區域的尺寸依據情況使用 px 、百分數或者 em/rem 。如一些高校的網站 jlu ，頁面的主要劃分區域使用 px 和百分比，包裹文字的元素和文字採用 em 。
上面的這幾種方案下，頁面元素的大小按照屏幕解析度進行適配調整，但是整體布局不變，對於 響應式web設計 ，網頁布局會隨著訪問它的視口及設備的不同呈現不同的樣式，在實現上可能會以上多種方案的結合，同時搭配 媒體查詢 技術使用，使得一個頁面在多個終端 (PC, mobile, pad) 呈現滿意效果，如 mashable 。
[TOC]
像素，是屏幕上顯示數據的最基本的點，表示相對大小。不同解析度下相同長度的 px 元素顯示會不一樣，是因為像素點的個數相同情況下，不同解析度下每個像素點對應的像素寬度不同。比如同樣是 14px 大小的字，在 1366×768 顯示屏下會顯示的小，在 1024×768 顯示屏下會相對大。也稱為 物理像素（設備像素 ），是解析度的尺寸單位。
印刷行業常用單位，能夠使用測量設備測得的長度，等於 1/72 英寸。
在不同屏幕上， css 像素呈現的物理尺寸一致，但 css 像素對應的物理像素具數不同。標準的顯示密度下， 1 個 css 像素對應一個物理像素，縮放時， 1 個 css 像素對應的物理像素會減增。是一種 設備獨立像素(device independent pixels: DIPs)
像素密度，每英寸所擁有的像素數。值越高，顯示畫面細節越豐富。計算公式為：[圖片上傳失敗...(image-245547-1621406560980)]
，其中 [圖片上傳失敗...(image-2b7617-1621406560980)]
和 [圖片上傳失敗...(image-f0525f-1621406560980)]
是解析度的寬高，[圖片上傳失敗...(image-2b6254-1621406560980)]
是屏幕尺寸。
列印設備每英寸印刷出來的點有多少個，值越高，圖片越細膩。
設備物理像素和設備獨立像素比 ，即[圖片上傳失敗...(image-6bbc3c-1621406560980)]
是指在理想布局寬度，使用多少個物理像素來渲染一個css像素。js中通過 window.devicePixelRatio 獲取，css中通過 -webkit-device-pixel-ratio , -webkit-min-device-pixel-ratio , -webkit-max-device-pixel-ratio 進行媒體查詢。
<meta> 標簽中定義了一些元數據信息，通過設置 <meta name = "viewport"> ，提供有關 視口初始大小 的信息，供 移動設備 使用。屬性值為
移動端涉及 布局視口 （Layout Viewport）、 視覺視口 （Visual ViewPort）和 理想視口 （Ideal ViewPort）。
與移動端web頁面適配有關的手機屏幕特性包括
硬體所支持的，屏幕每行的像素 * 每列的像素點數，單位是 px 。
設備獨立的，軟體可以達到的，個人理解是使得軟體/頁面在不同屏幕上顯示出來的效果一致。
像素解析度 ÷ 邏輯解析度等於 倍率 ，如 @3x 表示解析度的 3 倍。一個已知物理像素大小的元素，如果在普通屏中其設備像素等於 css 像素，但在一些高清屏中，如 Retina 顯示屏，一個css像素對應 2 或 3 個設備像素，這時顯示出來的元素會變小。為了讓元素如期待顯示，需要傳入 原始設計稿尺寸 × 倍率 的設計稿，根據 DPR 的定義，這樣載入後能夠達到同樣的效果。
手機屏幕對角線長度換算成英寸的大小
貼上 源碼 分析
視口 是瀏覽器中用於呈現網頁的區域，移動端的視口通常指的是 布局視口
使用 css 預處理器把設計稿尺寸轉換為 vw 單位，包括 文本 ， 布局高寬 ， 間距 等，使得這些元素能夠隨視口大小自適應調整。以 1080px 設計稿為基準，轉化的計算表示為
響應式設計 使得一個網站同時適配 多種設備 和 多個屏幕 ，讓網站的布局和功能隨用戶的使用環境（屏幕大小、輸出方式、設備/瀏覽器能力而變化），使其視覺合理，交互方式符合習慣。如使得內容區塊可伸縮與自由排布，邊距適應頁面尺寸，圖片適應比例變化，能夠自動隱藏/部分顯示內容，能自動折疊導航和菜單。
㈢ 如何調整網頁大小與屏幕適應
第一種方法：可以按著Ctrl鍵，然後滾動滑鼠滑輪對網頁大小進行調整。調整到與電腦屏幕大小相適應的程度即可。
第二種方法：點擊瀏覽器右下角的縮放頁面比例，然後對網頁進行相對應的調整即可。
㈣ 移動端web 怎麼調整table使用各種手機屏幕的大小
設置width 100%就可以了，另外在html頂端，需要設置<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">
㈤ 移動web終端 viewport設置
移動web，顧名思義就是在移動端的web頁面，比如我們可以在手機的UC瀏覽器中訪問淘寶等網站：
可以發現淘寶的移動web版本和pc上web版本有很大的不同，在移動web版本中更像是模擬了native應用中的頁面。所以移動web的開發和pc上web的開發肯定也是有很大的不同。
先看正常的pc上web頁面在移動設備上的展示：
從上圖可以看出，正常PC上的網頁在移動設備被縮放了，這樣對於商城購物類的網站來說，用戶體驗非常差，所以就更應該要有適配移動設備的頁面了。
那麼究竟是怎樣適配移動端的頁面呢？答案就是viewport，可以將viewport理解為瀏覽器中用來承載網頁的那一層。默認情況下移動設備上瀏覽器會自動將viewport的值設置為980px或者1024px，不過手機的屏幕沒有那麼大，這時候網頁就縮放了。
到這里，web適配移動設備的方案就出來，讓viewport=手機的寬度就好了。是的，正常情況下都是這么用的：
在meta標簽中設置viewport的寬度為設備的寬度， initial-scale=1 的意思是頁面的縮放比例為1， user-scalable=no 的意思是禁止用戶縮放頁面， minimum-scale=1,maximum-scale=1 的意思是設置用戶的最大最小縮放比，當設置了 user-scalable=no 之後這兩個屬性值就沒有意義了。
以上就是viewport的主流設置，不錯淘寶（m.taobao.com）就是非主流的設置，淘寶的移動web頁面中viewport沒有設置寬度：
所以淘寶的viewport的width應該是用js動態獲取的。
㈥ 移動端網頁設計尺寸標准
涉移動端設計和開發的同學們，基本都會在尺寸問題上糾結好一陣子才能摸到頭緒。那麼大家知道移動端網頁設計尺寸標準是多少呢?下面一起來看看!
現象
首先說現象，大家都知道移動端設備屏幕尺寸非常多，碎片化嚴重。尤其是Android，你會聽到很多種解析度：480x800, 480x854, 540x960, 720x1280, 1080x1920，而且還有傳說中的2K屏。近年來iPhone的碎片化也加劇了：640x960, 640x1136, 750x1334, 1242x2208。
不要被這些尺寸嚇倒。實際上大部分的app和移動端網頁，在各種尺寸的屏幕上都能正常顯示。說明尺寸的問題一定有解決方法，而且有規律可循。
像素密度
要知道，屏幕是由很多像素點組成的。之前提到那麼多種解析度，都是手機屏幕的實際像素尺寸。比如480x800的屏幕，就是由800行、480列的像素點組成的。每個點發出不同顏色的光，構成我們所看到的畫面。而手機屏幕的物理尺寸，和像素尺寸是不成比例的。最典型的例子，iPhone 3gs的屏幕像素是320x480，iPhone 4s的屏幕像素是640x960。剛好兩倍，然而兩款手機都是3.5英寸的。
所以，我們要引入最重要的一個概念：像素密度，也就是PPI(pixels per inch)。這項指標是連接數字世界與物理世界的橋梁。
Pixels per inch，准確的說是每英寸的長度上排列的像素點數量。1英寸是一個固定長度，等於2.54厘米，大約是食指最末端那根指節的長度。像素密度越高，代表屏幕顯示效果越精細。Retina屏比普通屏清晰很多，就是因為它的像素密度翻了一倍。
倍率與邏輯像素
再用iPhone 3gs和4s來舉例。假設有個郵件列表界面，我們不妨按照PC端網頁設計的思維來想像。3gs上大概只能顯示4-5行，4s就能顯示9-10行，而且每行會變得特別寬。但兩款手機其實是一樣大的。如果照這種方式顯示，3gs上剛剛好的效果，在4s上就會小到根本看不清字。
在現實中，這兩者效果卻是一樣的。這是因為Retina屏幕把2x2個像素當1個像素使用。比如原本44像素高的頂部導航欄，在Retina屏上用了88個像素的高度來顯示。導致界面元素都變成2倍大小，反而和3gs效果一樣了。畫質卻更清晰。
在以前，iOS應用的資源圖片中，同一張圖通常有兩個尺寸。你會看到文件名有的帶@2x字樣，有的不帶。其中不帶@2x的用在普通屏上，帶@2x的用在Retina屏上。只要圖片准備好，iOS會自己判斷用哪張，Android道理也一樣。
由此可以看出，蘋果以普通屏為基準，給Retina屏定義了一個2倍的倍率(iPhone 6plus除外，它達到了3倍)。實際像素除以倍率，就得到邏輯像素尺寸。只要兩個屏幕邏輯像素相同，它們的顯示效果就是相同的。
Android的解決方法類似，但更復雜一些。因為Android屏幕尺寸實在太多，解析度高低跨度非常大，不像蘋果只有那麼幾款固定設備、固定尺寸。所以Android把各種設備的像素密度劃成了好幾個范圍區間，給不同范圍的設備定義了不同的倍率，來保證顯示效果相近。像素密度概念雖然重要，但用不著我們自己算，iOS與Android都幫我們算好了。
如圖所示，像素密度在120左右的屏幕歸為ldpi，160左右的歸為mdpi，以此類推。這樣，所有的Android屏幕都找到了自己的位置，並賦予了相應的倍率：
ldpi [0.75倍]
mdpi [1倍]
hdpi [1.5倍]
xhdpi [2倍]
xxhdpi [3倍]
xxxhdpi [4倍]
各型號iPhone的倍率比較簡單，我們後面會講到。那麼Android手機那麼多，具體怎麼分?哪些手機是幾倍的倍率呢?我們先看一張表，這是友盟2014年10月到2015年03月的數據：
就目前市場狀況而言，各種手機的解析度可以這樣粗略判斷。雖然不全面，但至少在1年內都還有一定的參考意義：
ldpi 如今已絕跡，不用考慮
mdpi [320x480](市場份額不足5%，新手機不會有這種倍率，屏幕通常都特別小)
hdpi [480x800、480x854、540x960](早年的低端機，屏幕在3.5英寸檔位;如今的低端機，屏幕在4.7-5.0英寸檔位)
xhdpi [720x1280](早年的中端機，屏幕在4.7-5.0英寸檔位;如今的中低端機，屏幕在5.0-5.5英寸檔位)
xxhdpi [1080x1920](早年的高端機，如今的中高端機，屏幕通常都在5.0英寸以上)
xxxhdpi [1440x2560](極少數2K屏手機，比如Google Nexus 6)
自然地，以1倍的mdpi作為基準。像素密度更高或者更低的設備，只需乘以相應的倍率，就能得到與基準倍率近似的顯示效果。
不過需要注意的是，Android設備的'邏輯像素尺寸並不統一。比如兩種常見的屏幕480x800和1080x1920，它們分別屬於hdpi和xxhdpi。除以各自倍率1.5倍和3倍，得到邏輯像素為320x533和360x640。很顯然，後者更寬更高，能顯示更多內容。所以，即使有倍率的存在，各種Android設備的顯示效果仍然無法做到完全一致。
單位
不難發現，真正決定顯示效果的，是邏輯像素尺寸。為此，iOS和Android平台都定義了各自的邏輯像素單位。iOS的尺寸單位為pt，Android的尺寸單位為dp。說實話，兩者其實是一回事。
單位之間的換算關系隨倍率變化：
1倍：1pt=1dp=1px(mdpi、iPhone 3gs)
1.5倍：1pt=1dp=1.5px(hdpi)
2倍：1pt=1dp=2px(xhdpi、iPhone 4s/5/6)
3倍：1pt=1dp=3px(xxhdpi、iPhone 6)
4倍：1pt=1dp=4px(xxxhdpi)
單位決定了我們的思考方式。在設計和開發過程中，應該盡量使用邏輯像素尺寸來思考界面。設計Android應用時，有的設計師喜歡把畫布設為1080x1920，有的喜歡設成720x1280。給出的界面元素尺寸就不統一了。Android的最小點擊區域尺寸是48x48dp，這就意味著在xhdpi的設備上，按鈕尺寸至少是96x96px。而在xxhdpi設備上，則是144x144px。
無論畫布設成多大，我們設計的是基準倍率的界面樣式，而且開發人員需要的單位都是邏輯像素。所以為了保證准確高效的溝通，雙方都需要以邏輯像素尺寸來描述和理解界面，無論是在標注圖還是在日常溝通中。不要再說「底部標簽欄的高度是96像素，我是按照xhdpi做的」這樣的話了。
Web怎麼辦
移動端頁面的絕對單位仍然是px，至少代碼里這么寫，但它的道理也和app一樣。由於像素密度是設備本身的固有屬性，它會影響到設備中的所有應用，包括瀏覽器。前端技術可以善加利用設備的像素密度，只需一行代碼，瀏覽器便會使用app的顯示方式來渲染頁面。根據像素密度，按相應倍率縮放。
以iPhone 5s為例，屏幕的解析度是640x1136，倍率是2。瀏覽器會認為屏幕的解析度是320x568，仍然是基準倍率的尺寸。所以在製作頁面時，只需要按照基準倍率來就行了。無論什麼樣的屏幕，倍率是多少，都按邏輯像素尺寸來設計和開發頁面。只不過在准備資源圖的時候，需要准備2倍大小的圖，通過代碼把它縮成1倍大小顯示，才能保證清晰。
實際應用
大家最關心的還是實際運用，畫布該怎麼設置。我們就iOS、Android、Web三個平台來分別梳理一下。不過在這之前，我要為使用PS進行設計的朋友介紹一個小技巧。
之前我說過，我們要以邏輯像素尺寸來思考界面。體現到設計過程中，就是要把單位設置成邏輯像素。打開PS的首選項——單位與標尺界面，把尺寸和文字單位都改成點(Point)。這里的點也就是pt，無論設計iOS、Android還是Web應用，單位都用它。當然，各平台單位名稱還是要記住的。這里我們用的只是它的原理，不用在意名稱。
要調節倍率，則通過圖像大小里的DPI來控制。這個DPI，其實就是PPI，像素密度。有個常識大家都知道，屏幕上的設計DPI設成72，印刷品設計DPI設成300。為什麼是這兩個數字?
首先說300，這和人眼的分辨能力有關。由於1英寸是固定長度，每1英寸有多少個像素點決定了畫質清晰程度。之前說過，這就是像素密度，也就是DPI。DPI達到300以上，其細膩程度就會給人真實感，像真實世界中的物件。相反，DPI只有10的話，在你一個食指指節大小的長度內只有10個像素，這明顯就是馬賽克了。所以印刷品要設成300，才能保證清晰。
再說72，這有一定的歷史原因。最早的圖形設計是在mac電腦上進行的，mac本身的顯示器解析度就是72。PS中把圖像DPI也設成72，就能保證屏幕上顯示的尺寸和列印尺寸相同，便於設計。72的PC顯示器解析度逐漸成為一種默認的行業標准，這套規則就這么沿用下來。
現在回到正題，我們怎麼通過DPI來調節倍率?既然屏幕本身的解析度是72，DPI設成72剛好是1倍尺寸，那設成72的兩倍就是倍率為2的屏幕了，就這么簡單。
下面來看看3個平台各自的畫布設置：
iPhone
iPhone的屏幕尺寸各不相同，我說的是邏輯像素尺寸，這確實是讓人很頭疼的事情。如果想用一套設計涵蓋所有iPhone，就要選擇邏輯像素折中的機型。
從市場佔有率數據來看，目前最多的是iPhone5/5s的屏幕。倍率為2，邏輯像素320x568。上升勢頭最猛，未來有望登上第一的是iPhone 6的屏幕。倍率為2，邏輯像素375x667。
按照這兩種尺寸來設計，都是比較主流的做法。可以兼顧短一些的iPhone 4s，大一點的6 plus也不會過於空曠。
不過在切圖的時候要注意，由於iPhone 6 plus的3倍圖是由2倍圖放大而來，所以點陣圖要注意保證清晰。
Android
都說Android碎片化嚴重，但它現在反而比iOS好處理。因為如今的Android屏幕邏輯像素已經趨於統一了：360x640，就看你設成幾倍了。想以xhdpi為准，就把DPI設成72x2=144。想以xxhdpi為准，就把DPI設成72x3=216。
對於那些比較老的低端機，寬度是480px的那批，畫面確實會小一些，顯示內容會更少。稍微留意一下，重要內容盡量保持在界面中上部分。
當然，這些機型不出一年就會被邊緣化，基本淘汰。現在能運轉的也是當作功能機在用，軟體多了必卡無疑，用戶體驗無從談起。不作考慮也是OK的。
Web
手機端網頁就沒有統一標准了，比較流行的做法是按照iPhone 5的尺寸來設計。倍率2，邏輯像素320x568。
這樣的做法比較實在，倍率2的屏幕無論在iOS還是Android方面都是主流，而且又是2倍屏幕中邏輯像素最小的。所以圖片的尺寸可以保持在較小的水平，頁面載入速度快。當然，缺點就是在倍率3的設備上看，圖片不是特別清晰。
如果追求圖片質量，願意犧牲載入速度，那麼可以按照最大的屏幕來設計。也就是iPhone 6 plus的尺寸，倍率3，邏輯像素414x736。
總結
移動端的尺寸比PC端復雜，關鍵就在倍率。但也正因為倍率的存在，把大大小小的屏幕拉回到同一水平線，得以保證一套設計適應各種屏幕。站在這條水平線的角度看，會發現它很好理解。
㈦ 如何移動桌面上web項目或調整其大小
首先確定你的 web項目沒有鎖定(桌面--右擊--排列圖標）
然後將滑鼠移到圖片的頂上，出現控制條 OK啦
㈧ web前端 移動端和pc端顯示比例一般都要怎麼調整
如果你自己拿不準的話用一套ui框架是比較好的，他能同時兼容各個屏幕的樣式，如果你不想用框架，那麼你要想想你的網頁是否適合做PC和手機的兼容
㈨ 手機移動web開發 如何做到控制頁面大小不變
手機的屏幕有大有小，移動web最好做成響應式布局，也就是自適應屏幕，沒有固定寬高，這樣的話，在所有手機上都可以正常顯示。ico的話可以使用字體圖標，現在大部分手機瀏覽器都支持html5和css3的。
Web前端開發工程師是一個很新的職業，在國內乃至國際上真正開始受到重視的時間不超過7年。Web前端開發是從網頁製作演變而來的，名稱上有很明顯的時代特徵。在互聯網的演化進程中，網頁製作是Web 1.0時代的產物，那時網站的主要內容都是靜態的，用戶使用網站的行為也以瀏覽為主。
㈩ 移動Web怎麼做屏幕適配
業內比較流行的做法（參考阿里的flexible），有以下要點： 1、設置viewport為設備寬度（這里不一定，但目前先這樣足矣） 2、將viewport分成10rem，並計算出1rem在當前瀏覽器的像素值，把它賦予html標簽的font-size（分成10rem只是為了方便計算而已） 3、寫CSS代碼時，遇到要適配的地方，比如width，margin，padding等，就不要再用px了，改成用rem JS和Html代碼如下： CSS代碼做了類似如下的修改： 運行結果如下：邊距和頭像圖片都隨屏幕變化而變化了。