目次
背景
ビジュアル ドラフト
いくつか概念
几个问题
最后
参考文章
ホームページ ウェブフロントエンド htmlチュートリアル モバイル高解像度、マルチスクリーン適応ソリューション [出典: http://div.io/topic/1092]_html/css_WEB-ITnose

モバイル高解像度、マルチスクリーン適応ソリューション [出典: http://div.io/topic/1092]_html/css_WEB-ITnose

Jun 24, 2016 am 11:22 AM

Lovesueee 8 か月前に公開

モバイル高解像度、マルチスクリーン適応ソリューション

背景

  1. モバイル H5 ページを開発
  2. 異なる解像度の携帯電話に対応
  3. 異なる画面サイズに対応 モバイル

ビジュアル ドラフト

フロントエンド開発の前に、Visual MM はビジュアル ドラフトと呼ばれる PSD ファイルを提供します。

モバイル開発では、ページの高精細効果を実現するために、ビジュアルドラフトの仕様は次の 2 点に従うことがよくあります:

  1. まず、ベンチマークとして携帯電話の画面の幅と高さを選択します。 (以前は iPhone 4 4​​80 の 320×でしたが、現在は iPhone6 の 375×667 です)。
  2. Retina スクリーン (例: dpr=2) の場合、高精細効果を実現するために、ビジュアル ドラフトのキャンバス サイズはベースラインの 2 倍になります。つまり、ピクセル数は元の 4 倍になります ( iPhone6の場合:元の375×667は750×1334になります)。

質問:

  1. dpr=2 の携帯電話の場合、なぜキャンバス サイズ × 2 で高解像度の問題が解決できるのですか?
  2. サイズが 2 倍のビジュアルドラフトの場合、特定の CSS コーディング (つまり、レイアウトの問題) で各ブロックの実際の幅と高さを復元するにはどうすればよいですか?

質問がある場合は、下を向いてください...

いくつか概念

具体的な分析を行う前に、まず次の主要な基本概念 (用語) を理解しておく必要があります。

物理ピクセル (物理ピクセル)

物理ピクセルは、ディスプレイ (携帯電話の画面) 上の最小の物理表示単位であり、オペレーティング システムのスケジューリングに基づいて、各デバイスのピクセルは独自の色値と輝度値を持ちます。

デバイス非依存ピクセル (密度非依存ピクセル)

デバイス非依存ピクセル (密度非依存ピクセルとも呼ばれます) は、コンピューター座標系の点として考えることができます。この点は、プログラムで使用できる仮想ピクセルを表します。例: css ピクセル) に変換され、関連するシステムによって物理ピクセルに変換されます。

つまり、物理ピクセルとデバイスに依存しないピクセルの間には一定の対応関係があり、これが次に説明するデバイスのピクセル比率です。

デバイス ピクセル比 (デバイス ピクセル比)

デバイス ピクセル比 (略して dpr) は、物理ピクセルとデバイスに依存しないピクセルの対応を定義します。その値は次の式に従って取得できます:

设备像素比 = 物理像素 / 设备独立像素 // 在某一方向上,x方向或者y方向
ログイン後にコピー

JavaScript では、window を使用できます。 .devicePixelRatio は現在のデバイスの dpr を取得します。

CSS では、-webkit-device-pixel-ratio、-webkit-min-device-pixel-ratio、および -webkit-max-device-pixel-ratio を通じてメディア クエリを実行でき、異なる DPR を持つデバイスに対していくつかのクエリを実行できます。スタイルの適応 (これは、Webkit コアを備えたブラウザーと Web ビューのみに適用されます)。

上記の概念を組み合わせて、例を挙げてみましょう:

iPhone6 を例に挙げてみましょう:

  1. デバイスの幅と高さは 375 × 667 であり、デバイスに依存しないピクセル (または CSS ピクセル) として理解できます。
  2. dpr は 2 です。上記の計算式によれば、物理ピクセルは ×2、つまり 750×1334 になります。

画像を使って表現する、それだけです (写真を盗用してごめんなさい):

上の画像からわかるように、そのような CSS スタイル:

width: 2px;height: 2px;
ログイン後にコピー

異なる画面上 (通常の画面と網膜) screen) では、CSS ピクセルによって表現されるサイズ (物理サイズ) は同じですが、1 つの CSS ピクセルに対応する物理ピクセル数が一定ではない点が異なります。

通常の画面では、1 CSS ピクセルは 1 物理ピクセル (1:1) に対応します。
Retina スクリーンでは、1 つの CSS ピクセルは 4 つの物理ピクセル (1:4) に対応します。

ビットマップ ピクセル

ビットマップ ピクセルは、ラスター イメージ (png、jpg、gif など) の最小データ単位です。各ビットマップ ピクセルには、独自の表示情報 (表示位置、色の値、透明度など) が含まれています。

そういえば、網膜下の写真の表示について話さなければなりませんか?

理論的には、1 ビットマップ ピクセルは 1 物理ピクセルに対応するため、画像は完全かつ鮮明に表示されます。

通常の画面では問題ありませんが、Retina 画面ではビットマップのピクセルが不足し、画像がぼやけてしまいます。

画像を使用して表します:

上の図に示すように: dpr=2 の Retina スクリーンの場合、1 つのビットマップ ピクセルは 4 つの物理ピクセルに対応します。単一のビットマップ ピクセルはそれ以上分割できないため、次のようにすることができます。最も近い色のみを選択すると、画像がぼやけてしまいます (上記の色の値に注意してください)。

したがって、高解像度の画像の問題については、画像を 2 倍にする (@2x) 方が良い解決策となります。

例: 200×300 (CSS ピクセル) img タグの場合は、400×600 の画像を指定する必要があります。

このようにして、ビットマップのピクセル数は元の数の 4 倍になり、網膜スクリーンの下では、ビットマップのピクセル数と物理的なピクセル数の比率が 1:1 になり、画像が自然に鮮明になります。これで以前に残った疑問、ビジュアルドラフトのキャンバスサイズがなぜ×2なのかについても説明されています。

ここで別の質問がありますが、通常の画面で 2 倍の画像が使用されるとどうなりますか?

很明显,在普通屏幕下,200×300(css pixel)img标签,所对应的物理像素个数就是200×300个,而两倍图片的位图像素个数则是200×300*4,所以就出现一个物理像素点对应4个位图像素点,所以它的取色也只能通过一定的算法(显示结果就是一张只有原图像素总数四分之一,我们称这个过程叫做downsampling),肉眼看上去虽然图片不会模糊,但是会觉得图片缺少一些锐利度,或者是有点色差(但还是可以接受的)。

用一张图片来表示:

针对上面的两个问题,我做了一个demo(内网访问)狂戳这里。

demo中,100×100的图片,分别放在100×100,50×50,25×25的img容器中,在retina屏幕下的显示效果。

条形图,通过放大镜其实可以看出边界像素点取值的不同:

  • 图1,就近取色,色值介于红白之间,偏淡,图片看上去会模糊(可以理解为图片拉伸)。
  • 图2,没有就近取色,色值要么是红,要么是白,图片看上去很清晰。
  • 图3,就近取色,色值介于红白之间,偏重,图片看上去有色差,缺少锐利度(可以理解为图片挤压)。
  • 爱字图,可以通过看文字"爱"来区分图片模糊还是清晰。

    (ps:如果看上去不明显,可以用手机扫码网页(内网地址)或者点击原图看会更直观点。

    几个问题

    这里说一下,移动端H5开发,在不同分辨率,不同屏幕手机下会遇到的几个经典问题。

    retina下,图片高清问题

    这个问题上面已经介绍过解决方案了:两倍图片(@2x),然后图片容器缩小50%。

    如:图片大小,400×600;

    1.img标签

    width: 200px;height: 300px;
    ログイン後にコピー

    2.背景图片

    width: 200px;height: 300px;background-image: url(image@2x.jpg);background-size: 200px 300px; // 或者: background-size: contain;
    ログイン後にコピー

    这样的缺点,很明显,普通屏幕下:

    1. 同样下载了@2x的图片,造成资源浪费。
    2. 图片由于downsampling,会失去了一些锐利度(或是色差)。

    所以最好的解决办法是:不同的dpr下,加载不同的尺寸的图片。

    不管是通过css媒体查询,还是通过javascript条件判断都是可以的。

    那么问题来了,这样的话,不就是要准备两套图片了嘛?(@1x 和@2x)

    我想,做的好的公司,都会有这么一个图片服务器,通过url获取参数,然后可以控制图片质量,也可以将图片裁剪成不同的尺寸。

    所以我们只需上传大图(@2x),其余小图都交给图片服务器处理,我们只要负责拼接url即可。

    如,这样一张原图:

    https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg // 原图
    ログイン後にコピー

    可以类似这样,进行图片裁剪:

    // 200×200https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_200x200.jpg// 100×100https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_100x100.jpg
    ログイン後にコピー

    (ps: 当然裁剪只是对原图的等比裁剪,得保证图片的清晰嘛~)

    retina下,border: 1px问题

    这大概是设计师最敏感,最关心的问题了。

    首先得说一下,为什么存在retina下,border: 1px这一说?

    我们正常的写css,像这样border: 1px;,在retina屏幕下,会有什么问题吗?

    先来,来看看下面的图:

    上面两张图分别是在iphone3gs(dpr=1)和iphone5(dpr=2)下面的测试效果,对比来看,对于1px的border的展示,它们是一致的,并无区别。

    那么retina显示屏的优势在哪里,设计师为何觉得高清屏下(右图)这个线条粗呢?明明和左右一样的~

    还是通过一张图来解释(原谅我再次盗图):

    上图中,对于一条1px宽的直线,它们在屏幕上的物理尺寸(灰色区域)的确是相同的,不同的其实是屏幕上最小的物理显示单元,即物理像素,所以对于一条直线,iphone5它能显示的最小宽度其实是图中的红线圈出来的灰色区域,用css来表示,理论上说是0.5px。

    所以,设计师想要的retina下border: 1px;,其实就是1物理像素宽,对于css而言,可以认为是border: 0.5px;,这是retina下(dpr=2)下能显示的最小单位。

    然而,无奈并不是所有手机浏览器都能识别border: 0.5px;,ios7以下,android等其他系统里,0.5px会被当成为0px处理,那么如何实现这0.5px呢?

    最简单的一个做法就是这样(元素scale):

    .scale{    position: relative;}.scale:after{    content:"";    position: absolute;    bottom:0px;    left:0px;    right:0px;    border-bottom:1px solid #ddd;    -webkit-transform:scaleY(.5);    -webkit-transform-origin:0 0;}
    ログイン後にコピー

      

    我们照常写border-bottom: 1px solid #ddd;,然后通过transform: scaleY(.5)缩小0.5倍来达到0.5px的效果,但是这样hack实在是不够通用(如:圆角等),写起来也麻烦。

    当然还有其他好多hack方法,网上都可以搜索到,但是各有利弊,这里比较推荐的还是页面scale的方案,是比较通用的,几乎满足所有场景。

    对于iphone5(dpr=2),添加如下的meta标签,设置viewport(scale 0.5):

    <meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5, minimum-scale=0.5,user-scalable=no">
    ログイン後にコピー

    这样,页面中的所有的border: 1px都将缩小0.5,从而达到border: 0.5px;的效果。

    有人担心页面scale后会影响性能,@妙净同学做过性能测试,见这里(内网地址)。

    看一下实现后的效果图对比(右图为优化过的):

    (ps: 图片被压缩过,可能看上去并不明显,可以用手机扫码或者点击这里(内网地址)对比看看)

    然而,页面scale,必然会带来一些问题:

    1. 字体大小会被缩放
    2. 页面布局会被缩放(如: div的宽高等)

    这两个问题后面讲到...

    多屏适配布局问题

    移动端布局,为了适配各种大屏手机,目前最好用的方案莫过于使用相对单位rem。

    基于rem的原理,我们要做的就是: 针对不同手机屏幕尺寸和dpr动态的改变根节点html的font-size大小(基准值)

    这里我们提取了一个公式(rem表示基准值)

    rem = document.documentElement.clientWidth * dpr / 10
    ログイン後にコピー

    说明:

    1. 乘以dpr,是因为页面有可能为了实现1px border页面会缩放(scale) 1/dpr 倍(如果没有,dpr=1),。
    2. 除以10,是为了取整,方便计算(理论上可以是任何值)

    所以就像下面这样,html的font-size可能会:

    iphone3gs: 320px / 10 = 32px

    iphone4/5: 320px * 2 / 10 = 64px

    iphone6: 375px * 2 / 10 = 75px

    对于动态改变根节点html的font-size,我们可以通过css做,也可以通过javascript做。

    css方式,可以通过设备宽度来媒体查询来改变html的font-size:

    html{font-size: 32px;}<br />//iphone 6 @media (min-device-width : 375px) {   html{font-size: 64px;}}<br />// iphone6 plus @media (min-device-width : 414px) {    html{font-size: 75px;}}*/
    ログイン後にコピー

      

    缺点:通过设备宽度范围区间这样的媒体查询来动态改变rem基准值,其实不够精确,比如:宽度为360px 和 宽度为320px的手机,因为屏宽在同一范围区间内(<375px),所以会被同等对待(rem基准值相同),而事实上他们的屏幕宽度并不相等,它们的布局也应该有所不同。最终,结论就是:这样的做法,没有做到足够的精确,但是够用。

    javascript方式,通过上面的公式,计算出基准值rem,然后写入样式,大概如下(代码参考自kimi的m-base模块)

    var dpr, rem, scale;var docEl = document.documentElement;var fontEl = document.createElement('style');var metaEl = document.querySelector('meta[name="viewport"]');dpr = window.devicePixelRatio || 1;rem = docEl.clientWidth * dpr / 10;scale = 1 / dpr;// 设置viewport,进行缩放,达到高清效果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;
    ログイン後にコピー

      

    这种方式,可以精确地算出不同屏幕所应有的rem基准值,缺点就是要加载这么一段js代码,但个人觉得是这是目前最好的方案了。

    因为这个方案同时解决了三个问题:

    1. border: 1px问题
    2. 图片高清问题
    3. 屏幕适配布局问题

    说到布局,自然就得回答一下最初的留下的那个问题:如何在css编码中还原视觉稿的真实宽高?

    前提条件:

    1. 拿到的是一个针对iphone6的高清视觉稿 750×1334
    2. 采用上述的高清方案(js代码)。

    如果有一个区块,在psd文件中量出:宽高750×300px的div,那么如何转换成rem单位呢?

    公式如下:

    rem = px / 基准值;
    ログイン後にコピー

    对于一个iphone6的视觉稿,它的基准值就是75(之前有提到);

    所以,在确定了视觉稿(即确定了基准值)后,通常我们会用less写一个mixin,像这样:

    // 例如: .px2rem(height, 80);.px2rem(@name, @px){    @{name}: @px / 75 * 1rem;}
    ログイン後にコピー

    所以,对于宽高750×300px的div,我们用less就这样写:

    .px2rem(width, 750);.px2rem(height, 300);
    ログイン後にコピー

    转换成html,就是这样:

    width: 10rem; // -> 750pxheight: 4rem; // -> 300px
    ログイン後にコピー

    最后因为dpr为2,页面scale了0.5,所以在手机屏幕上显示的真实宽高应该是375×150px,就刚刚好。

    倘若页面并没有scale 0.5,我们的代码就得这样:

    .px2rem(width, 375);.px2rem(height, 150);
    ログイン後にコピー

    这样的宽高,我们往往是这样得来的:

    1. 将750×1334的视觉稿转成375×667的大小后,再去量这个区块的大小(感觉好傻)。
    2. 在750×1334量得区块宽高是750×300px后,再口算除以2(感觉好麻烦)。

    最后给出一张没有布局适配(上图)和用rem布局适配(下图)的对比图:

    (上面的手机分别是:iphone3gs, iphone5, iphone6)

    很明显可以看出,rem适配的各个区块的宽高都会随着手机屏宽而改变,最最明显的可以看一下图片列表那部分,最后一张图视觉稿要求只出现一点点,rem布局在任何屏幕下都显示的很好。

    字体大小问题

    既然上面的方案会使得页面缩放(scale),对于页面区块的宽高,我们可以依赖高清视觉稿,因为视觉稿本来就×2了,我们直接量就可以了,那么对于字体该如何处理呢?

    对于字体缩放问题,设计师原本的要求是这样的:任何手机屏幕上字体大小都要统一,所以我们针对不同的分辨率(dpr不同),会做如下处理:

    font-size: 16px;[data-dpr="2"] input {  font-size: 32px;}
    ログイン後にコピー

      

    (注意,字体不可以用rem,误差太大了,且不能满足任何屏幕下字体大小相同)

    为了方便,我们也会用less写一个mixin:

    .px2px(@name, @px){    @{name}: round(@px / 2) * 1px;    [data-dpr="2"] & {        @{name}: @px * 1px;    }    // for mx3    [data-dpr="2.5"] & {        @{name}: round(@px * 2.5 / 2) * 1px;    }    // for 小米note    [data-dpr="2.75"] & {        @{name}: round(@px * 2.75 / 2) * 1px;    }    [data-dpr="3"] & {        @{name}: round(@px / 2 * 3) * 1px    }    // for 三星note4    [data-dpr="4"] & {        @{name}: @px * 2px;    }}
    ログイン後にコピー

      

    (注意:html的data-dpr属性就是之前js方案里面有提到的,这里就有用处了)

    根据经验和测试,还是会出现这些奇奇葩葩的dpr,这里做了统一兼容~

    用的时候,就像这样:

    .px2px(font-size, 32);
    ログイン後にコピー

    当然对于其他css属性,如果也要求不同dpr下都保持一致的话,也可以这样操作,如:

    .px2px(padding, 20);.px2px(right, 8);
    ログイン後にコピー

    最后

    上面对移动端H5高清和多屏适配的一些方案总结,和知识讲解,不对的地方,还请指出来,新浪微博 - Lovesueee。

    参考文章

    1. http://www.smashingmagazine.com/2012/08/20/towards-retina-web/
    2. http://www.paintcodeapp.com/news/iphone-6-screens-demystified
    3. http://www.inserthtml.com/2012/09/designing-retina-devices/
    4. http://iconmoon.com/blog2/iphone-6-plus-screen-size/
    5. http://dieulot.net/css-retina-hairline

     

    このウェブサイトの声明
    この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

    ホットAIツール

    Undresser.AI Undress

    Undresser.AI Undress

    リアルなヌード写真を作成する AI 搭載アプリ

    AI Clothes Remover

    AI Clothes Remover

    写真から衣服を削除するオンライン AI ツール。

    Undress AI Tool

    Undress AI Tool

    脱衣画像を無料で

    Clothoff.io

    Clothoff.io

    AI衣類リムーバー

    AI Hentai Generator

    AI Hentai Generator

    AIヘンタイを無料で生成します。

    ホットツール

    メモ帳++7.3.1

    メモ帳++7.3.1

    使いやすく無料のコードエディター

    SublimeText3 中国語版

    SublimeText3 中国語版

    中国語版、とても使いやすい

    ゼンドスタジオ 13.0.1

    ゼンドスタジオ 13.0.1

    強力な PHP 統合開発環境

    ドリームウィーバー CS6

    ドリームウィーバー CS6

    ビジュアル Web 開発ツール

    SublimeText3 Mac版

    SublimeText3 Mac版

    神レベルのコード編集ソフト(SublimeText3)

    公式アカウントのキャッシュの更新の難しさ:バージョンの更新後のユーザーエクスペリエンスに影響を与える古いキャッシュを回避する方法は? 公式アカウントのキャッシュの更新の難しさ:バージョンの更新後のユーザーエクスペリエンスに影響を与える古いキャッシュを回避する方法は? Mar 04, 2025 pm 12:32 PM

    公式アカウントのWebページはキャッシュを更新します。これはシンプルでシンプルで、ポットを飲むのに十分な複雑です。あなたは公式のアカウントの記事を更新するために一生懸命働きましたが、ユーザーはまだ古いバージョンを開くことができますか?この記事では、この背後にあるtwist余曲折と、この問題を優雅に解決する方法を見てみましょう。それを読んだ後、さまざまなキャッシュの問題に簡単に対処でき、ユーザーが常に新鮮なコンテンツを体験できるようになります。最初に基本について話しましょう。それを率直に言うと、アクセス速度を向上させるために、ブラウザまたはサーバーはいくつかの静的リソース(写真、CSS、JSなど)やページコンテンツを保存します。次回アクセスするときは、もう一度ダウンロードすることなく、キャッシュから直接検索できます。自然に高速です。しかし、このことは両刃の剣でもあります。新しいバージョンはオンラインです、

    HTML5フォーム検証属性を使用してユーザー入力を検証するにはどうすればよいですか? HTML5フォーム検証属性を使用してユーザー入力を検証するにはどうすればよいですか? Mar 17, 2025 pm 12:27 PM

    この記事では、ブラウザのユーザー入力を直接検証するために、必要、パターン、MIN、MAX、および長さの制限などのHTML5フォーム検証属性を使用して説明します。

    WebページのPNG画像にストローク効果を効率的に追加する方法は? WebページのPNG画像にストローク効果を効率的に追加する方法は? Mar 04, 2025 pm 02:39 PM

    この記事では、CSSを使用したWebページへの効率的なPNG境界追加を示しています。 CSSはJavaScriptやライブラリと比較して優れたパフォーマンスを提供し、微妙または顕著な効果のために境界幅、スタイル、色を調整する方法を詳述していると主張しています

    HTML5のクロスブラウザー互換性のベストプラクティスは何ですか? HTML5のクロスブラウザー互換性のベストプラクティスは何ですか? Mar 17, 2025 pm 12:20 PM

    記事では、HTML5クロスブラウザーの互換性を確保するためのベストプラクティスについて説明し、機能検出、プログレッシブエンハンスメント、およびテスト方法に焦点を当てています。

    &lt; datalist&gt;の目的は何ですか 要素? &lt; datalist&gt;の目的は何ですか 要素? Mar 21, 2025 pm 12:33 PM

    この記事では、HTML&lt; Datalist&GT;について説明します。オートコンプリートの提案を提供し、ユーザーエクスペリエンスの改善、エラーの削減によりフォームを強化する要素。

    &lt; Progress&gt;の目的は何ですか 要素? &lt; Progress&gt;の目的は何ですか 要素? Mar 21, 2025 pm 12:34 PM

    この記事では、HTML&lt; Progress&gt;について説明します。要素、その目的、スタイリング、および&lt; meter&gt;との違い要素。主な焦点は、&lt; Progress&gt;を使用することです。タスクの完了と&lt; Meter&gt; statiの場合

    HTML5&lt; time&gt;を使用するにはどうすればよいですか 日付と時刻を意味的に表す要素? HTML5&lt; time&gt;を使用するにはどうすればよいですか 日付と時刻を意味的に表す要素? Mar 12, 2025 pm 04:05 PM

    この記事では、html5&lt; time&gt;について説明します。セマンティックデート/時刻表現の要素。 人間の読み取り可能なテキストとともに、マシンの読みやすさ(ISO 8601形式)のDateTime属性の重要性を強調し、Accessibilitを増やします

    &lt; meter&gt;の目的は何ですか 要素? &lt; meter&gt;の目的は何ですか 要素? Mar 21, 2025 pm 12:35 PM

    この記事では、html&lt; meter&gt;について説明します。要素は、範囲内でスカラーまたは分数値を表示するために使用され、Web開発におけるその一般的なアプリケーション。それは差別化&lt; Meter&gt; &lt; Progress&gt;およびex

    See all articles