国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【收集-轉載】前端布局

未東興 / 3206人閱讀

摘要:談談的屏與安卓的各種屏布局也好,用進行縮放也罷,文字的適配問題也是,都是基于我們想對各個不同的設備所進行的匹配。

感謝csdn原文:淺談前端移動端頁面開發(布局篇)
感謝:移動前端自適應解決方案和比較
使用Flexible實現手淘H5頁面的終端適配

一. viewport

什么是viewport
簡單來講,viewport就是瀏覽器上,用來顯示網頁的那一部分區域了,也就是說,瀏覽器的實際寬度,是和我們手機的寬度不一樣的,無論你的手機寬度是320px,還是640px,在手機瀏覽器內部的寬度,始終會是瀏覽器本身的viewport。如今的瀏覽器,都會給自己的本身提供一個viewport的默認值,可能是980px,或者是其他值。就以手機來說吧,目前,新版本的手機瀏覽器,絕大部分是以980px作為默認的viewport值的。我這里對新版本的不同平臺下的瀏覽器做了測試,經過測試,iphone下的默認viewport為980px,安卓下的瀏覽器,目前主流的最新瀏覽器(比如chrome,還有很多國產的像qq,uc)的viewport也是980px了。

viewport是用來干什么的
viewport的默認值,一般來說是大于手機屏幕的。這樣就可以做到當我們在瀏覽桌面端網頁的時候,可以讓桌面端端網頁正常顯示(我們普通頁面設計的時候,一般頁面的主區域是以960px來做的,所以980px這個值,可以做到桌面端網頁的正常顯示)。但是,其實我們手機的屏幕寬度是沒有960px的,因此瀏覽器會出現橫向滾動條。同時,即使是基于980的viewport,我們在移動端瀏覽我們的桌面頁面的體驗其實也并不好,所以,一般的,我們會專門給瀏覽器設計一個移動端的頁面。

對viewport的控制
如今可以絕大部分瀏覽器里(即主流的安卓瀏覽器和iOS),都支持對viewport的一個控制了。一般的,我們會這么寫。

viewport默認有6個屬性
width: 設置viewport的寬度(即之前所提及到的,瀏覽器的寬度詳),這里可以為一個整數,又或者是字符串"width-device"

initial-scale: 頁面初始的縮放值,為數字,可以是小數
minimum-scale: 允許用戶的最小縮放值,為數字,可以是小數
maximum-scale: 允許用戶的最大縮放值,為數字,可以是小數
height: 設置viewport的高度(我們一般而言并不能用到)
user-scalable: 是否允許用戶進行縮放,"no"為不允許,"yes"為允許

我們把這個標簽是在head里面,像這樣


這樣就可以做到對viewport的控制了

二. 關于我們的設備

三個需要了解的概念:

PPI: 可以理解為屏幕的顯示密度

DPR: 設備物理像素和邏輯像素的對應關系,即物理像素/邏輯像素

Resolution: 就是我們常說的分辨率

物理像素與邏輯像素
看了我們上面內容一的第一點之后,或許有些人會有些疑問,我的安卓手機,或者iphone6plus(目前應該僅限于這一款機型吧),買回來的是1920x1080的或者其他更高的,比我之前所謂的那個viewport默認的980px要大。
這樣的問題,也就是我之前所說的物理像素與邏輯像素的關系了(即DPR)。以1920x1080為例,1080為物理像素,而我們在viewport中,獲取到的,比如"width-device",是邏輯像素。所以之前viewport的默認值,所比對的大小,其實是邏輯像素的大小,而非物理像素的大小。
以iphone6為例,在不做任何縮放的條件下,iphone6的獲取到的"width-device"為375px,為屏幕的邏輯像素。而購買時我們所知的750px,則為屏幕的物理像素。

CSS的問題
有了上面第二點的一些基礎,還是以iphone6為例,我們可以知道,其實我們所寫的1px,在iphone6上為2px的物理像素。所以,最后的,給出一個結論。就是我們寫的1px,在移動端,是邏輯像素的1px,而非物理像素的1px。

三. 使用rem布局

簡單說下rem
rem是根據頁面的根元素的font-size的一個相對的單位,即

html{
    font-size: 16px;
}    

比如當我們在一個div中,如此寫

div{
    width: 2rem;
}

那么我們的width,是16*2 = 32px
rem做到適配不同分辨率
這個是現在手機淘寶的移動端的解決方案,即使用rem的特性,來對頁面進行布局。
下面舉一個例子
假定設計稿的大小為750,那么我們則將整個圖分成100份來看(下面的題外話會說明為什么會分成100份來看)
那么,我們現在就讓根部元素的font-size為75px

html{
    font-size: 75px;
}

那么,我們現在就可以比對設計稿,比如設計稿中,有一個div元素,寬度,高度都為75px,那么我們這樣寫即可

div{
    height: 1rem;
    width: 1rem;
}

可能看到這里,一些人還是不明白怎么用rem做到適配不同的分辨率,那么我們再來
現在,我們換設備了,不用這個設備是一個width為640的手機
那么這個時候,我們的rem單位就起到作用了。
我們的rem全是根據html的font-size來改變的,所以說,這個時候,我們只需要把html下的font-size改成64px。那么,我們之前的div,因為是根據html下的font-size動態變化的,那么。此時也就變成了寬度和高度都為64px的東西了。這樣,就可以做到適配不同的屏幕分辨率了。(其實就是個等比縮放)
總結一下,我們的解決方案,其實就是 設計稿的像素/html的font-size = 用來代替px的rem。
這一個步驟,我們需要通過JS來進行操作。
對于js的操作在下面會提到。

DPR的問題

視覺姐姐給了我們設計稿,并交由我們實現,那么,我們應該去認真的實現:-)(試想你做了一張圖,而前端很多地方并沒有按照你所想的,你所給的去做,而是私自改變了很多東西,你肯定會不高興的)
那么1px會出現什么問題呢。
還記得我們第二大點講的,我們的設備,是有物理像素和邏輯像素的。而假設我們的設計稿是750的,同時還是以iphone6為例,此時如果我們的viewport是這樣的


之前說過,在不做任何縮放的條件下,iphone6獲取到的viewport為375px。
然后我們的頁面中有個div,他有一個邊框值,如下

div{
    height: 5rem;
    widht:5rem;
    border: 1px solid #000
}

此時我們寫的1px,實際上是邏輯像素,而我們在iphone6上看到的是物理像素,于是這個時候,我們眼睛所看到的其實是2px(參考第二點第三個問題)
所以此時我們需要在viewport上做文章了,此時先明確,如果要獲取到真正的1px,那么我們需要這么做,將viewport改為


即對屏幕做0.5倍的縮放。這樣,我們就能得到實際的1px。
所以到這里,我們還要明確一點,viewport的meta標簽,我們這里也只能通過js來動態生成。
同時,這樣寫,據說還可以避免比如inline的SVG等元素按照邏輯像素的渲染。避免了整個頁面清晰度的打折(其實我并不能看出來)
文字適配問題
最近深深糾結與rem與px做字體單位的問題,還是先分別談下二者吧。

rem與px的特點:
以rem作為字體單位:我們可以讓頁面整體的文字,也跟隨著html的font-size來進行改變,這樣,在不同的屏幕下,可以做到文字相對屏幕的比例是一樣的。

以px作為字體單位: 這個是目前很多網站還是依然采用的方法。因為以上面所寫的,以rem作為字體單位。無論在任何屏幕下面,我們的文字都會根據屏幕做一個適應。試想這樣一個場景。你買了一個大屏手機(5.7寸的),而別人用的是4寸的手機。以rem作為字體單位的話,那大屏手機看到的文字多少和小屏手機確實一樣的了。這樣來做,其實并不符合我們買大屏手機的期待。同時,以rem作為字體單位,可能會導致出現很多奇怪的字體大小(畢竟是根據html的font-size動態變化的嘛),同時這其中還涉及到了一個點陣尺寸的概念,這個在下面來講。

字體大小引發的系列問題:
字體大小:我們平時也看過,很多網站,是不以奇數作為字體大小的。我稍微查了些東西,在知乎上的現在網頁設計中的為什么少有人用 11px、13px、15px 等奇數的字體?問題下,有一些比較好的解答,我就不再多說(我也并不能比這個問題說的更多),總的來說,其實就是偶數寬度的字體能夠顯得均衡,以及一個點陣的問題。不過因為要談及點陣,所以我拿上面回答中的一個內容舉例。

倘若一個字體,只提供了12px,14px,16px的點陣。那么當你寫13px,15px,17px的時候。就并沒有其字體大小所對應的點陣。那么這樣就造成了一個問題。他們會使用其相鄰的點陣,比如對應使用了12px,14px,16px的點陣,而導致一個問題,文字占用的大小確實改變,但點陣卻并沒有改變。

文字適配的解決方案:
上面說了這么多,我們總要有一套解決方案吧

對于一些標題性的文字,我們依然可以用rem。讓他隨著屏幕來進行縮放,因為標題性文字一般較大,而較大的文字,點陣對其影響就越小。這樣,即使出現奇怪的尺寸,也能夠讓字體得到很好的渲染。
對于一些正文內容的文字(即站在使用者的角度,你不希望他進行縮放的文字)。我們采用px來進行處理。

四.安卓與ios不得不說的問題(解決篇)

在 三.使用rem布局 里面,我們給出了各種情況的解決方案,并且,在我舉例的時候,熱衷于使用iphone來舉例,但其實,上面的所有問題,不是僅僅iphone會出現的問題,安卓也是一樣。但是,如果你已經看完了上面,那么這里,才是真正給出我們解決方案的地方,并且,這個解決方案并不完善。
談談iphone的r屏與安卓的各種屏
rem布局也好,用viewport進行縮放也罷,文字的適配問題也是,都是基于我們想對各個不同的設備所進行的匹配。這套方案很好,然而也有其兼顧不到的地方。即安卓和ios的屏幕的一些問題,當然,細的東西我們不談,我們只談dpr。
先談iphone
其實iphone為開發者考慮到了很多東西,為了讓開發者便于開發,在6plus出現之前,iphone的dpr始終也就是2(即前面所談的物理像素/邏輯像素=2),即使是6plus出現了,iphone到底其實也就只有2,3這兩個dpr。我們很容易對其做到兼顧。
再談安卓
安卓并沒有對自己的屏幕叫做r屏,但是其原理和iphone的r屏可以說是一樣。r屏做的是什么,把兩個(三個)物理像素,丟到了一個邏輯像素里面,讓屏幕展現的更清晰(當然,這是我片面的理解,不過我覺得大體來說并沒有錯,我們也不用去深入探討r屏還有什么東西,我也并不懂)。而安卓也是一樣,他也同樣把n個物理像素丟到了一個邏輯像素里面。而這里的n,也就是dpr值(所以當我看到好多人問安卓為什么不采用r屏的時候,我真的也是……醉了?)。而安卓的dpr值,并不像iphone那樣,就只有兩個值。安卓的dpr是千奇百怪的,可能是1.5,2,3,4,2.5等等的都有。(甚至我還看到了1.7之類的,安卓的各個設備商,玩的真尼瑪high啊。怎么高興怎么來。)
所以,對安卓的屏幕的dpr的處理,其實是很頭疼的,因為,他和我們對字體的處理,有了很大的沖突。這個在下面提及
首先看看手淘的解決方案
rem布局
用js獲取到頁面的寬度,然后對其進行寬度/10的處理,再將其寫到html的font-size中。手淘的flexible.js里面的這一部分,并為了方便看懂做了些改寫。大體就是這樣的
function refreshRem(){

 var docEl = window.document.documentElement;
var width = docEl.documentElement.getBoundingClientRect().width;

var rootSize = width/10;
docEl.style.fontSize = rootSize + "px";

}
dpr的配置
首先,在引入flexible.js之前,我們可以對dpr進行手動的配置,即使用自定義的meta標簽來配置dpr(看清楚是flexible,而非viewport)

iniital-dpr是把dpr強制設定為給定的值,而maximum-dpr則是給出一個最大的dpr限制,然后對其和系統的dpr做一個比較。
然后依然為了方便閱讀我把flexble.js這一部分的代碼抽象出來,

    var doc = window.document
    var metaEl = doc.querySelector("meta[name="viewport"]");
    var flexibleEl = doc.querySelector("meta[name="flexible"]");
    var dpr = 0;
    var scale = 0;            //縮放比例
    //在meta標簽中,已經有了viewport,則使用已有的viewport,并根據meta標簽,對dpr進行設置
    if (metaEl) {
        console.warn("將根據已有的meta標簽來設置縮放比例");
        var match = metaEl.getAttribute("content").match(/initial-scale=([d.]+)/);
        if (match) {
            scale = parseFloat(match[1]);
            dpr = parseInt(1 / scale);
        }
    //如果在meta標簽中,我們手動配置了flexible,則使用里面的內容
    } else if (flexibleEl) {
        var content = flexibleEl.getAttribute("content");
        if (content) {
            var initialDpr = content.match(/initial-dpr=([d.]+)/);
            var maximumDpr = content.match(/maximum-dpr=([d.]+)/);
            if (initialDpr) {
                dpr = parseFloat(initialDpr[1]);
                scale = parseFloat((1 / dpr).toFixed(2));    
            }
if (maximumDpr) {
dpr = parseFloat(maximumDpr[1]);
scale = parseFloat((1 / dpr).toFixed(2));
}
}
}

這樣,我們通過flexible的分析與獲取,對dpr進行了書寫。不過其實這里,是有個問題的。即在書寫maximum的的情況下,其實根本沒有像文檔中給我們的說法一樣,做一個比較,而是做了和initialDpr一樣的一個處理。不過這里也不對其做一個探討了。
然后,這套解決方案,然后當我們在meta標簽里面并沒有對viewport以及flexible兩個的任意一個進行書寫的時候,他也是會自動獲取一個dpr值的

if (!dpr && !scale) {
    var isAndroid = window.navigator.appVersion.match(/android/gi);
    var isIPhone = window.navigator.appVersion.match(/iphone/gi);、
    //devicePixelRatio這個屬性是可以獲取到設備的dpr的
    var devicePixelRatio = win.devicePixelRatio;
    if (isIPhone) {
    // iOS下,對于2和3的屏,用2倍的方案,其余的用1倍方案
    if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                
        dpr = 3;
    } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){
        dpr = 2;
    } else {
        dpr = 1;
    }
} else {
    // 其他設備下,仍舊使用1倍的方案
    dpr = 1;
    }
    scale = 1 / dpr;
}
這里我們可以看到,手機淘寶并沒有對安卓的dpr進行一個適配,原因之后再講。
然后到了這里,我們獲取到了我們需要的dpr值,并根據dpr值獲取到了我們所需要的縮放值(即scale)
然后我們要做的,就是在并沒有viewport的meta標簽對情況下自己動態將這個標簽寫進我們的header,形式是這樣的

這樣,dpr的配置,也就完成了,當然,安卓設備并沒有對dpr進行一個配置(上面的動態生成就不給出js了)
文字的解決方案
由于手淘暫時并沒有對安卓做一個處理,所以,這里,只是對iphone做了一個處理
即在html上,加入了一個自定義屬性,data-dpr。

還是以750的設計稿為例(即iphone6)
假如設計稿上某a標簽是32px,那么,我們要這么寫
a{
    font-size: 16px
}
/*iphone6*/
[data-dpr="2"] a{
    font-size: 32px
}
/*iphone6plus*/
[data-dpr="3"] a{
    font-size: 32px
}

現在的一些問題
正如我們看到的,手淘目前的方案里面,是沒有考慮到安卓dpr的問題的。即,這套方案,只對于iphone的r屏做了一個處理,而對于安卓,并沒有做dpr的處理。我們來分析下原因吧(個人拙見)。
我們希望字體能夠以px來展現,同時,我們也希望我們的東西能對dpr做一個適配。對于ios,這自然是可行的,即采用了data-dpr的自定義屬性來調整文字。4到6寫一套字體大小,6p寫一套字體大小,然后在對dpr為1的屏幕寫一套字體大小。其實這種寫法還是很惡心,不過基于對dpr的適配,這樣寫也算是個解決方案了。
不過同樣的解決方案到安卓就不行了,安卓的dpr有時候會很亂(比如現在在goole的手機測試里面可以看到,安卓的dpr,lg的某些設備還采用了1.7那樣的奇怪dpr)。而當1.7dpr這種不規范的數字出現的時候,我們就不能采用之前的解決方案了,比如
[data-dpr="1.7"] a{

font-size: 25px

}
這樣的東西是不可能去寫的,那萬一還有2.25,2.5之類的呢?我們都要拿去匹配么?
其實現在,因為我們通過devicePixelRatio可以獲取到安卓的dpr值,即可以做到對安卓設備的dpr一個匹配。但是,文字如果采用px的話,確實是很難做到匹配的。
即總結一下,就是說,對于安卓的dpr匹配,目前來說,是沒有什么問題的,但是,對于dpr匹配之后的字體,那肯定是有問題的。
常見的dpr下的字體,我們依然可以解決,但是不常見的dpr,我們確實很難做到對dpr的解決。那如何解決這些問題呢。目前以我本人這個不太靈光的腦袋,確實也不曉得該如何進行一個處理了,起碼做不到很好的解決。
不過,還是丟上些個人的觀點吧。
在之前的對dpr的判斷中,是根據了設備進行判斷,即安卓不對dpr進行改變,僅對ios的設備進行改變。那么,我們其實可不可以以dpr的值來做一個處理呢?即像這樣寫

if (!dpr && !scale) {
    //devicePixelRatio這個屬性是可以獲取到設備的dpr的
    var devicePixelRatio = win.devicePixelRatio;
    //判斷dpr是否為整數
    var isRegularDpr = devicePixelRatio.toString().match(/^[1-9]d*$/g)
    if (isRegularDpr) {
    // 對于是整數的dpr,對dpr進行操作
     if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                
        dpr = 3;
    } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){
        dpr = 2;
    } else {
        dpr = 1;
    }
} else {
    // 對于其他的dpr,人采用dpr為1的方案
    dpr = 1;
    }
    scale = 1 / dpr;
}    

我們對這里做了一點點修改,即來判斷dpr是否是規則的,也就是是否是我們常見的1,2,3等,然后,我們只對規則的dpr,來進行一個字體的處理。這樣,iphone依然還是用之前的匹配方案。而其實目前安卓,很多的設備還是比較常見的dpr了,所以我們這里,將之前對設備的判斷,轉變成對dpr是否是整數的一個判斷。其他地方不變,可以解決對安卓dpr的部分匹配。
同樣,開發的時候,如果并不在乎字體的問題的話,大可以直接使用rem。那樣是可以做到dpr和文字都適配的問題。不過正如我們講到字體的時候所說的,使用rem是很多用戶不希望的(大屏機還是和小屏機看到一樣多的內容),同時,還有點陣的問題。

參考

手機淘寶的flexible設計與實現

題外話:

iphone6plus很有趣的地方

iphone6plus照理來說的,其實際dpr是2.87左右的,不過,為了方便開發者來開發,iphone6plus對其做了一個調整,將dpr調整為3,然后在對屏幕進行了一個縮放。這樣做,自然是方便了開發者前去開發,然而,這樣做,也有了一些性能上的損失。(iphone為開發者考慮的還是挺周全的,看看隔壁安卓,dpr怎么爽怎么來,都特么自己玩自己的)

有意思的vh和vw

vh,vw目前還存在很大程度的兼容性問題,所以還并沒有采用。
vh,vw有什么特點呢
這兩個元素分別會把屏幕上的可視高度(說通俗點就是你手機屏幕那個框框頭裝起的東西),寬度,分成100份來看,比如先前我們用rem來處理的地方,我們需要在html元素下寫上font-size: 75px,然后再在div下寫上width:1rem。而有了vh,vw之后,我們如此處理html的font-size就好。
html {

font-size: 10vw;

}
這樣寫,省去了一部js操作的步驟。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/115424.html

相關文章

  • 自己平時收集的css、html筆記(適合初級前端攻城獅)

    摘要:實習了一年時間,陸陸續續記錄下來一堆筆記,不過也丟失了一些以后會持續更新擴展,現在把碰到的知識點歸納于此,方便翻閱一部分取消自動識別數字為撥打號碼移動開發響應式布局二部分字母強制大寫解決中滑動速度慢或者卡的問題防止復制,兼  實習了一年時間,陸陸續續記錄下來一堆筆記,不過也丟失了一些... 以后會持續更新、擴展,現在把碰到的知識點歸納于此,方便翻閱 一、html部分   1.取消iPhone...

    番茄西紅柿 評論0 收藏0
  • css相關 - 收藏集 - 掘金

    摘要:在正式前端一些小細節前端掘金英文原文,翻譯未來的太讓人興奮了一方面,是全新的頁面布局方式另一方面,是酷炫的濾鏡顏色等視覺效果。老司機教你更好的進行編程個技巧前端掘金并不總是容易處理。 CSS3 實現文字流光漸變動畫 - 前端 - 掘金來自百度前端技術學院的實踐任務:有趣的鼠標懸浮模糊效果,參考:http://ife.baidu.com/course/d...,用CSS3實現了一下,順便...

    molyzzx 評論0 收藏0
  • 查漏補缺 - 收藏集 - 掘金

    摘要:醞釀許久之后,筆者準備接下來撰寫前端面試題系列文章,內容涵蓋瀏覽器框架分鐘搞定常用基礎知識前端掘金基礎智商劃重點在實際開發中,已經非常普及了。 這道題--致敬各位10年阿里的前端開發 - 掘金很巧合,我在認識了兩位同是10年工作經驗的阿里前端開發小伙伴,不但要向前輩學習,我有時候還會選擇另一種方法逗逗他們,拿了網上一道經典面試題,可能我連去阿里面試的機會都沒有,但是我感受到了一次面試1...

    YuboonaZhang 評論0 收藏0
  • 我的大前端- 收藏集 - 掘金

    摘要:下面圍繞的這樣的目的,即左右知乎網頁上屏幕截圖功能的實現前端掘金背景最近注意到知乎的屏幕截圖反饋功能,感覺非常不錯。正如你期望的,文中的闖關記之垃圾回收和內存管理前端掘金題圖來源,授權基于協議。 微信小程序實戰學習 起手式 DEMO 仿肯德基 - 前端 - 掘金小程序?大場景? 微信小程序本質上來說就是一個 HTML 5(移動網頁) 應用,用view、scoll-view代替了div標...

    LdhAndroid 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<