摘要:手淘下,,分了份字體不適合使用計算不同點網易的方法比較便于計算,淘寶復雜一些。網易的適配在添加第三方插件的時候,相對方便,淘寶因為全局縮放,會影響第三方插件的樣式。
兩個門派 根據屏幕寬度設置 rem
計算方式:
rem 根據屏幕寬度計算:屏幕寬度越大,元素的尺寸越大。
可以把網頁想象成一張等比縮放的圖片,當你屏幕寬度增大,圖片被拉寬,同時高度也會等比例增長。
以iPhone6為例,假設1rem = 100px, 一個寬度 100px 的 div 在 iPhone6 (750px)下就是 1rem,iPhone6plus (828px)下就是 1rem = 110px;
這個門派細分的話還有兩個分支,我們分別以網易和手淘為例
不設置viewpoint參考網易:
iPhone6(2dpr)和iPhone6plus(3dpr)的寬度下,兩者1rem分別為50px和55.2px,兩者比例為 750 / 828 ,dpr沒有參與計算;head中的viewport縮放一直是1。
具體來看 rem 的使用
上圖中的圖片元素的高度設置為1.4rem,可知其在設計稿中的高度為140px,那為什么實際顯示為 70px 呢?其實仔細一看,html 元素的 font-size 被設置成了 50px !那為什么html上的font-size是50px呢?我的理解是:因為設計稿是2倍圖,實際高度要除以2才行,高度為140px 的元素,其實要寫成 .7rem,但每次計算樣式都要除以2,太麻煩了,換個思路,如果直接將 rem 除以 2,那么計算尺寸時,只需要除以 100 即可,一勞永逸,提高了開發效率
設置viewport參考手淘:
iPhone6 下,1rem = 75px;
iPhone6plus 下,1rem = 124.2px。 750 (828 / 750) = 82.8px,再根據dpr縮放,82.8px (3/2) = 124.2px。
為什么82.8px還要乘以1.5呢?因為手淘在viewport上面做了處理,頁面整體縮小為i6尺寸的2/3,因此需要在單位尺寸上增加等比例的大小。
在寫樣式的時候,PS上量出的尺寸除以75。。。
還有坑爹的地方是,字體大小font-size一般情況下不適合跟隨寬度縮放,可能只能寫媒體查詢。
網易和淘寶兩者共同之處兩者都有一個共同的特點:可以把rem當作類似vw來用,因為他們都把寬度等分了。
網易:i6下,1rem = 100px ,7.5rem = 750px; 分了7.5份。
手淘:i6下,1rem = 75px,10rem = 750px;分了10份;
字體不適合使用rem計算
不同點:
網易的方法比較便于計算,淘寶復雜一些。
網易的適配在添加第三方插件的時候,相對方便,淘寶因為全局縮放,會影響第三方插件的樣式。
淘寶的方法可以輕松實現1px border,而網易需要特殊處理。
整合兩者?目的:方便計算 + viewprot縮放
在網易的基礎上改進計算方法:
i6下,1rem等于100px,viewport縮放0.5;
6p下,由于寬度變大:100px 1.104 = 110.4px;又有viewpoint縮放:110.4px 1.5 = 165.6px,1rem = 165.6px;
例子:
點我
根據 DPR 設置 rem計算方式:
dpr越大,手機的屏幕越大,看到的范圍越廣,尺寸和dpr相關。
一般情況下dpr和 rem 的關系為:
dpr1 ==> 50px
dpr2 ==> 100px
dpr3 ==> 150px
看例子中的代碼來理解
dpr = 2時:
dpr = 3時:
總結var dpr, rem, scale; var docEl = document.documentElement; var fontEl = document.createElement("style"); var metaEl = document.querySelector("meta[name="viewport"]"); dpr = window.devicePixelRatio || 1; //IP6的設計稿,rem=100px,dpr=2,縮放0.5; rem = 100 * dpr / 2; //rem = docEl.clientWidth * dpr / 10; //rem = docEl.clientWidth / 6.4; //相對于640 100px scale = 1 / dpr; // 設置viewport,進行縮放,達到高清效果, iphone6為例 物理像素750 css像素375,將視口寬度設置兩倍,在縮小 metaEl.setAttribute("content", "width=" + dpr * docEl.clientWidth + ",initial-scale=" + scale + ",maximum-scale=" + scale + ", minimum-scale=" + scale + ",user-scalable=no"); // 設置data-dpr屬性,留作的css hack之用 docEl.setAttribute("data-dpr", dpr); // 動態寫入樣式 docEl.firstElementChild.appendChild(fontEl); fontEl.innerHTML = "html{font-size:" + rem + "px!important;}"; // 給js調用的,某一dpr下rem和px之間的轉換函數 window.rem2px = function (v) { v = parseFloat(v); return v * rem; }; window.px2rem = function (v) { v = parseFloat(v); return v / rem; }; window.dpr = dpr; window.rem = rem;
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/112019.html
摘要:并且除了常用的端,還要考慮微信端,或者是端。所以我們要有一套機制,在端上走的代碼,在端或者微信端上走端對應的代碼。對于一個從零開始的移動端項目,我總結了以上這些移動開發難點,希望之后的人能少踩點坑,站在我的肩膀上提高項目開發的效率和質量。 從零搭建移動H5開發項目實戰 前端H5的前世今身 在Pc的時代,前端技術無疑統治了大多數用戶的交互界面!而在移動為王的今天,NA開發在早期占領了大多...
摘要:并且除了常用的端,還要考慮微信端,或者是端。所以我們要有一套機制,在端上走的代碼,在端或者微信端上走端對應的代碼。對于一個從零開始的移動端項目,我總結了以上這些移動開發難點,希望之后的人能少踩點坑,站在我的肩膀上提高項目開發的效率和質量。 從零搭建移動H5開發項目實戰 前端H5的前世今身 在Pc的時代,前端技術無疑統治了大多數用戶的交互界面!而在移動為王的今天,NA開發在早期占領了大多...
摘要:在移動端頁面當中,其中適配是經常會遇到的問題,這塊主要有死個方法可以適用。目前全網找或者是嘗試來看,確實沒有一個十全十美的適配的解決方案,只能不斷在實踐應用當中慢慢填坑最近做了兩個關于h5頁面對接公眾號的項目,不得不提打開微信瀏覽器內置地圖導航的功能確實有點惡心。下次想起來了的話,進行總結分享一下如何處理。在vue移動端h5頁面當中,其中適配是經常會遇到的問題,這塊主要有死個方法可以適用。 ...
閱讀 1223·2021-11-25 09:43
閱讀 1337·2021-09-26 09:55
閱讀 2330·2021-09-10 11:20
閱讀 3365·2019-08-30 15:55
閱讀 1441·2019-08-29 13:58
閱讀 1164·2019-08-29 12:36
閱讀 2337·2019-08-29 11:18
閱讀 3407·2019-08-26 11:47