1.明確統一@x圖的標準,以750x1334切下來的圖 爲@2x的標準
2.使用以屏幕寬度爲基準的相對單位,爲了適配,從設計稿到成品確定存在換算過程
3.爲位圖的容器設置寬高
適配後效果圖:基本不會出現很不理想的情況
html
其實已750x1334設計出來的圖,切下來,剛恰好就是2x圖,縮小1倍就是1x,乘以1.5就是3x圖前端
不是的 !!好比750px的iphone6 量出75px的物體,在375px的手機裏確定只有35px。因此爲了適配你必需轉換成以屏幕寬度爲標準的相對單位,因此換算過程確定是存在的,由於設計稿只是一個750的基準
。
@x圖只針對於圖片和圖標,這種須要用到位圖的地方詳細原理請點擊查看.其目標既是在等大的容器內裝入像素更大的位圖,從而補足像素點的缺失。
由於只有用到位圖的地方纔會出現像素缺失和像素丟失的情況,其餘的元素都是系統繪製的矢量圖形不受是不是高清屏幕的影響。react
若是@x圖比實際須要小,那麼圖像就會模糊。android
若是@x圖比實際須要大時會出現什麼問題,其實這種狀況也會出現問題只是問題不明顯,會出現的問題就是圖像失真,由於設備實際上沒那麼多像素點顯示,就是丟失一些像素點。這種狀況通常不易察覺,可是問題確定是存在的。這就是爲何有些同志拿到大圖了,卻以爲能夠的緣由,由於只要他限制了圖片的大小,他本身也看不出問題。
另外還有一點,就是web前端同志拿到的圖片會過大,這個影響就比較大了。
因此不是用越大的圖就越好。ios
@x圖標準仍是按照上方的標準。若是發現ps切下來的@2x比設計稿裏的大了,既是出現錯誤。
另外程序端仍是建議按設計稿給用到圖片的地方設置寬高,這樣防止換了大圖後圖片撐開的問題。web
rem是指相對於根元素的字體大小的單位。那麼根據該原理:咱們只需能動態獲取屏幕的dpr及寬度信息,並改變根元素的font-size,其他的全部頁面元素也將會進行改變
。編程
<html data-dpr="1" style="font-size: 41.4px;"> </html>
詳細原理請點擊查看
可是該方案有個問題,rem單位很不直觀。好比大小爲80px的按鈕, 按上面標準換算成rem爲1.946rem[這就蛋疼了,你沒法直觀看出這個按鈕多大,修改起來更是蛋疼。若是沒有一套優雅的管理方案,後期修改基本靠感受或者畫點時間計算下==],接下來和你們聊聊如何優雅的使用rem單位。小程序
假設對於一個iphone6的視覺稿,咱們定義它的基準值就是75 該基準值是根據你的定義變的
關於基準值有問題可見
這樣咱們就能夠按照設計稿的大小寫進程序,從而便於維護和識別sass
//輔助函數 // 例如: .px2rem(height, 80); @mixin px2rem(@name, @px){ @{name}: @px / 75 * 1rem; }
原理與上面的rem相同,也來得更簡單。由於vw原本就相對可視窗口寬度的百分比不受顯示器分辨率的影響
。微信
須要注意有版本要求:android4.4以上版本;ios8以上版本 最新兼容性查看
另外也存在百分比在設計稿中轉換到程序上的不直接問題
一樣在定好設計稿後,能夠書寫sass函數來輔助編程
假設設計稿爲750*1330 上的按鈕大小爲120px,那麼能夠這麼書寫
//.px2rem(width, 120); @mixin px2vw(@name, @px){ @{name}: @px / 750 * 1vw; }
圖片這裏由於h5端特殊,既要考慮流量,又要考慮清晰度,這裏推薦仍是直接使用@2x圖吧!別折騰了!
rpx爲小程序本身的單位,會對設備進行適配
rpx與[750*1330]設計稿px的關係1px==1rpx,可是在iphone6上0.5px==1rpx 詳見
Taro 方案的初心就是爲了打造一個多端開發的解決方案。目前 Taro 代碼能夠支持轉換到 微信/百度/支付寶/字節跳動小程序 、 H5 端 以及 移動端(React-Native)。Taro.js是京東出品的小程序框架,經使用除了不支持一些react語法外,基本無大槽點[這裏不經要吐槽下騰訊官方的wepy,真是坑死人不償命!請慎用慎用!]該框架直接服務到位,代碼直接書寫px單位[又不用記多一個rpx單位了😊],程序框架自動幫你轉換😁,那麼爽的嗎? 就是這麼爽!由於別人Taro的目標是write one, use everyWhere!!