## 究竟以哪個為設備獨立像素 ### window.innerwidth、window.screen.width 的區別 開始時（`viewport scale=1`），二者的值是相同的，但是 `scale=2` 頁面放大時，也就是設備獨立像素縮小時，`window.innerwidth` 縮小了（按scale倍數縮小，除以scale），而`window.screen.width`不變（也可以說window.screen.width為初始默認的設備獨立像素）。 當不在移動環境中時，`window.screen.width`始終為顯示器屏幕的寬，`window.innerwidth`為瀏覽器可見區域的寬，包含滾動條（`$(window).width()`不包含滾動條）。 * * * * * ### 設備的獨立像素的表示 window.innerWidth：瀏覽器可見區域寬度（包含滾動條，不過在移動端滾動條不單獨占寬度，不占空間的，不滾動時還是完全透明的），這個值其實就可以表示設備獨立像素的值了，甚至可以把它解讀為設備獨立像素。 **viewport scale大于1時，頁面放大，window.innerWidth縮小，設備的獨立像素減少，即點數量減少，為原來的1/scale。** **viewport scale小于1時，頁面縮小，window.innerWidth放大，設備的獨立像素增多，即點數量增多，為原來的1/scale。** * * * * * ### 分析 淘寶：html.clientWidth ```javascript var html = document.documentElement var rem = html.clientWidth / 10 html.style.fontSize = rem + 'px' ``` 小米：html.getBoundingClientRect().width ```javascript var html = document.documentElement var e = html.getBoundingClientRect().width document.documentElement.style.fontSize = e / 7.2 + "px" ``` 他們的實驗區別： 1. window.innerWidth: 628 2. html.clientWidth：617 3. html.getBoundingClientRect().width：616.6666870117188 以上是在PC模式下的值，可以看到： 1是包含滾動條的。 2不包含滾動條，但是不夠精確，明顯是四舍五入取整的值，對精確計算不友好。 3不包含滾動條，最精確，能精確到小數位后13位。 > 在移動端，縮放時，他們都會變化，是相同的，但偶爾window.innerWidth的值會比后兩者大1px（鼠標移到html元素上顯示的值與后兩者相同）。 回想之前我們視口縮放viewport scale： ```javascript // 注意這里，設置視口縮放時沒有設置 width=device-width metaEl.setAttribute('content', 'initial-scale=' + scale + ',maximum-scale=' + scale + ',minimum-scale=' + scale + ',user-scalable=no,viewport-fit=cover'); ``` 之前`window.innerwidth`和`window.screen.width`對比時，我們已經知道了，頁面放大時，設備獨立像素縮小，`window.innerwidth` 縮小了，而`window.screen.width`不變，`window.screen.width`只會隨著窗口大小而改變。 **`window.innerWidth`、`html.clientWidth`、`html.getBoundingClientRect().width`，三者沒有區別，表現的特性相同，它們的值與將鼠標移到html元素上顯示的值相同，都能代表隨著視口縮放而變化的設備獨立像素。** >[danger] 看來移動端開發很多東西還是要真機測試才行啊，上面的測試是在PC瀏覽器上模擬的，真機測試不是這樣：只要scale不為1，后兩者竟然都是980，看來還是得用window.innerWidth才靠譜啊。 上面是沒有設置`width=device-width`時的效果。 試想一下，如果又設置縮放，又設置最佳視口寬度等于設備寬度會不會相互矛盾呢？ 我們同時設置試一下： ```javascript // 注意這里，設置視口縮放時同時也設置了 width=device-width metaEl.setAttribute('content', 'width=device-width,initial-scale=' + scale + ',maximum-scale=' + scale + ',minimum-scale=' + scale + ',user-scalable=no,viewport-fit=cover'); ``` 首先我們發現，視口縮放不會觸發`resize`事件了，之前是可以觸發的。 當`scale>1`時`html.clientWidth`、`html.getBoundingClientRect().width`的值始終與將鼠標移到html元素上顯示的值相同（始終為初始默認的設備獨立像素值），不會跟隨視口縮放而改變，只有當`scale<1`時才正常，也就是說，它倆最小不會小于初始默認的設備獨立像素值（即最小不會小于window.screen.width的值）。 只有`window.innerWidth`能一直正常體現視口縮放時設備獨立像素隨著變化了。 那么此時，我們在想，到底使用哪個算基準值呢？ 基準值 = ? / Z （Y = P / Z） 顯然使用后兩個的話，縮放時基準值也會保持不變，就會出現不正常，rem元素也會被縮放。 總結：不同時設置時，他們基本沒有什么區別，無論用哪個做為基準值計算都是一樣的，沒有區別。同時設置時，問題就出來了，**同時設置是錯誤的做法，不要同時設置**，并且width默認就是device-width，所以其實可以不用設置這一項。 （不合理就不合理，不然視口縮放不會觸發`resize`事件就不好了） * * * * * 如果只進行比較簡單的適配，視口這樣設置就可以了： ```html <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1.0,viewport-fit=cover"> ``` 如果有用到視口縮放，就一定不要使用`width=device-width`。 * * * * * ### vh可以替代js實時計算的方案 我們是通過 `resize` 事件實時計算 基準值的，這種適配方案依賴于JS，如果不使用JS能實現類似的適配嗎？ 也可以，答案是用 vh 拼多多就是用的vh ```css html { font-size: 100vh / Z; } ``` 原理與JS版的同理。 ***** last update：2018-7-21 07:39:03