优点：
无需插件和移动主题，对联通设备友好，适应各种窗口大小。只需将@mediascreen属性添加到 CSS 中，即可根据浏览器长度确定和输出不同的长度和宽度值。
打算工作 1：设置元标记
首先，在使用 Media 时，需要设置以下代码以兼容所连接设备的演示效果：
**
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
解释了此代码的几个参数：
**
width = device-width：宽度等于当前设备的宽度
height = device-height：高度等于当前设备的高度
initial-scale：初始的缩放比例（默认设置为1.0）
minimum-scale：允许用户缩放到的最小比例（默认设置为1.0）
maximum-scale：允许用户缩放到的最大比例（默认设置为1.0）
user-scalable：用户是否可以手动缩放（默认设置为no，因为我们不希望用户放大缩小页面）
打算工作2：加载兼容的JS文件
由于IE8不支持HTML5或CSS3Media，因此需要加载两个JS文件以确保代码兼容。
**
预期工作 3：默认将 IE 渲染方式设置为最高（这部分可以添加或不添加）。
如今，许多人们的IE浏览器已经升级到IE9
以上，发生了许多奇怪的事情，比如现在的IE9浏览器，浏览器的文档模式是IE8。若要避免这些情况，需要以下代码才能使 IE 的文档模式保持最新：
**
<meta http-equiv="X-UA-Compatible" content="IE=edge">
如果要使用固定版本的IE，可以编写：
**
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
或者你也可以这样写：
**
<meta http-equiv="X-UA-Compatible" content="IE=Edge，chrome=1">
如何在此代码前面加上 chrome=1？
如果用户的笔记本配备了 chrome 插件 Google ChromeFrame（Microsoft嵌入式浏览器框架 GCF），则可以使用 Webkit 引擎和 V8 引擎在笔记本上进行 IE 的排版和计算，无论版本如何;如果用户没有安装此插件，则此代码将允许IE在最高文档模式下解释功效。
建议使用此代码，但也可以不使用它。
步入 CSS3Media 写作
我们来看看下面的代码，恐怕很多人经常在响应式网站的CSS中看到这样的代码：
**
@media screen and (max-width: 960px){
body{
background: #000;
}
}
这可能是编写媒体的标准方式移动端css3，其中的 CSS 代码意味着在页面大于 960px 时执行页面下方的 CSS。
有人会注意到此代码中有一个屏幕，这意味着告诉设备在复制页面时使用衬线字体移动端css3，并在屏幕上显示时使用无衬线字体。但目前很多网站会直接省略 screen，因为如果网站不需要考虑用户的抄袭，可以直接这样写：
**
@media (max-width: 960px){
body{
background: #000;
}
}
如果浏览器大小小于 960px：
**
@media screen and (min-width:960px){
body{
background:orange;
}
}
您还可以混合使用以前的用法：
**
@media screen and (min-width:960px) and (max-width:1200px){
body{
background:yellow;
}
}
这里的代码意味着当页面长度小于 960px 且大于 1200px 时，执行以下 CSS。
所有介质参数摘要
以上是最常用的媒体查询器的三个特点，小于、等于、大于的编写方式。媒体查找器的全部功能肯定不止这三个功能，其部分参数用法总结如下：
**
width:浏览器可视宽度。
height:浏览器可视高度。
device-width:设备屏幕的宽度。
device-height:设备屏幕的高度。
orientation:检测设备目前处于横向还是纵向状态。
aspect-ratio:检测浏览器可视宽度和高度的比例。(例如：aspect-ratio:16/9)
device-aspect-ratio:检测设备的宽度和高度的比例。
color:检测颜色的位数。（例如：min-color:32就会检测设备是否拥有32位颜色）
color-index:检查设备颜色索引表中的颜色，他的值不能是负数。
monochrome:检测单色楨缓冲区域中的每个像素的位数。（这个太高级，估计咱很少会用的到）
resolution:检测屏幕或打印机的分辨率。(例如：min-resolution:300dpi或min-resolution:118dpcm)。
grid：检测输出的设备是网格的还是位图设备。
注意下面的顺序，如果把@media（min-width：768px）写在底部，那就很悲惨了：
**
@media (min-width: 1200){ //>=1200的设备 }
@media (min-width: 992px){ //>=992的设备 }
@media (min-width: 768px){ //>=768的设备 }
这是因为如果屏幕长度为 1440，因为 1440>768 将不是 1200。
因此，当使用最小宽度时，小的在上面，大的在前面;同样，如果使用最大宽度，则大的在顶部，小的在前面。
**
@media (min-width: 768px){ //>=768的设备 }
@media (min-width: 992px){ //>=992的设备 }
@media (min-width: 1200){ //>=1200的设备 }
@media (max-width: 1199){ //<=1199的设备 }
@media (max-width: 991px){ //<=991的设备 }
@media (max-width: 767px){ //<=768的设备 }
横向和纵向屏幕
**
/* 竖屏 */
@media screen and (orientation: portrait) and (max-width: 720px) { 对应样式 }
/* 横屏 */
@media screen and (orientation: landscape) { 对应样式 }
PC端按屏幕长度大小排序
**
分辨率 比例 | 设备尺寸
1024*500 （8.9寸）
1024*768 （比例 4：3 | 10.4寸、12.1寸、14.1寸、15寸; ）
1280*800 （比例 16：10 |15.4寸）
1280*1024 （比例 5：4 | 14.1寸、15.0寸）
1280*854 （比例 15：10 | 15.2）
1366*768 （比例 16：9 | 不常见）
1440*900 （比例 16：10 17寸 仅苹果用）
1440*1050 （比例 5：4 | 14.1寸、15.0寸）
1600*1024 （比例 14：9 不常见）
1600*1200 （比例 4：3 | 15、16.1）
1680*1050 （比例 16：10 | 15.4寸、20.0寸）
1920*1200 （23寸）
摘要： 使用3D硬件加速提高动画性能时，最好将z-index属性降低到元素中，人为干扰复合层的排序，这样可以有效减少chrome创建的不必要的复合层，提高渲染性能，尤其是移动优化的效果。以下为原文：CSS3硬件加速也有陷阱！！人们常说css3移动端，想要在移动端有流畅的动漫表现，最近应该用3D硬件加速潜入浏览器内核的一些细节，看来是有漏洞的......第二章介绍了网页的结构，其中提到了 Webkit 硬件加速的形式，它将要渲染的元素放在一个特定的“合成层”中，可以在 chrome 控制台中像这样打开：
选择“显示合成图层边框”后，
您可以看到具有动漫 3D 转换的元素将被红色边框圈出，表示它们以新的“合成层”渲染，如下所示：
蓝色细线是浏览器渲染时的“tile”，浏览器在勾勒页面时只会勾勒出可视区域一定范围内的瓷砖，为了节省性能费用，而红色边框框向上，则表示这个元素渲染在一个特殊的复合层中，而主文档不在同一个图层之后我觉得这个视图挺有意思的， 所以我以前看过一个国外项目，不看我不知道，一看就吓尿了：
这个项目什么时候让所有元素都加速到3D了？！仔细检查了框架元素后，没有任何需要合成图层渲染的迹象，我真的哔哔了狗......我开始一个接一个地删除元素，简化代码，很快意识到罪魁祸首就在这里：
头部中那种旋转木马动漫元素的存在，其实导致下面所有的相对和绝对定位元素都被放置在复合层中......查找了一些信息：图层创建条件何时可以使元素获取自己的图层？尽管Chrome的启发式方法随着时间的推移而发展，但就目前而言，以下任何条件都会创建层：主要是最后一个，我认为在英语翻译中不是很准确，显然：Element有一个具有较低z索引的同级，它具有合成层（换句话说）。它呈现在合成层的顶部）意味着，如果存在一个元素，其同级元素在复合层中呈现，并且同级元素的 z 索引相对较小，则该元素（无论是否应用硬件加速样式）也将放置在复合层中。最可怕的是，浏览器可能会创建一个复合层来渲染复合层之后的所有相对或绝对定位的元素，因此具有上一个项目截图的效果。我还想知道为什么这个页面滚动卡住了，显然没有太多的 DOM，但现在看来问题就在这里！所以我写了一个页面来告诉你这个东西到底有多强大：
我在此页面中放置了一个 H1 标题，应用 Translate3D 动画，使其在合成层中渲染，然后在此元素前面创建了 2000 个列表，每个列表都有一个图像、一个标题和一个日期显示，其中图像和日期显示是绝对定位的，父容器 LI 相对定位， 然后，您可以根据上述说明打开Chrome的“显示”组合图层边框的选项，以查看此页面的内容复合层分布：
就像这只鸟，很难想象这样的页面在向上滚动时会卡住什么。我当时使用的是 Mac 机器，快速拖动滚动条 Chrome 已经很费力了，然后我写了一个简单的滚动条连接操作：setInterval（'document.body.scrollTop++'， 0）;然后使用时间轴获取页面性能：
“复合层”的估计结果是 96.206 毫秒！！这仍然在我的Mac系统上哦，手机真的会卡住。我在页面上放了一个开关“为动漫元素设置 z-index”，点击此复选框后，它会使用 js 添加 position：relative 和 z-index： 1 到哪个动漫 H1 元素，这种做法的原理是人为地改进动漫元素的 z-index，让浏览器知道这个元素的层顺序， 并且不会很脑残地让其他z指数比它高的元素进入复合层，看这个效果：
光是给动漫元素设置更高的z指数，就能解决这些雷霆降低复合层的问题，他们有点无语......完成后，使用滚动条连接功能来捕获页面性能：
完全恢复正常，由纪优！你可以用支持“硬件加速”的“Android”移动浏览器测试上面的页面，在动漫元素中添加z-index之前和之后的性能差异非常显着。不过并不是所有的浏览器都有这个问题，我的 Safari、Mac 上的 Firefox 没有明显区别，Android 手机上的 QQ 浏览器似乎很正常，猎豹、UC、Oppen、webview 等浏览器明显不同，更多的测试要靠你去发现。最后总结一下：在使用 3D 硬件加速提升动画性能时，最好给元素减少一个 z-index 属性，人为干扰复合层的排序，这样可以有效减少 chrome 创建的不必要的复合层，提高渲染性能，尤其是移动优化的效果。您现在可以解决此类问题，尤其是在使用轮播和动画加载的页面上，这很常见。另外css3移动端，建议在追逐性能问题时开启“显示合成图层边框”选项，如果页面有很多红框，那肯定是错误的。最后，我再次推荐《Webkit Technology Insider》一书。浏览器内核之于前端工程师，就像操作系统之于前端工程师一样，毕竟是我们程序运行的主机环境，多了解就很容易找出很多问题。
发表评论