吹不黑，我觉得百度首页是一个非常适合实践的项目，它会涉及到以下几个知识点：CSS选择器、HTML结构定义、盒子模型、Flex、CSS定位css盒模型，然后我就分析一下这个知识点用在哪里
定义 HTML 结构
很多菜鸟在收到一个页面的时候，可能会觉得没有办法下手，虽然我们首先要做的是定义 HTML 的结构css盒模型，但是选择合适的 HTML 元素，比如百度首页这个页面，我们怎么定义，如右图所示：
HTML结构的合理定义可以使我们的代码更容易编写
使用弹性
弹性布局是
在工作中用得特别频繁，但它也是最好的官方一维布局解决方案，比如下面的模块：
此部分可以使用挠曲布局的挠度方向、挠度增长和挠度-收缩属性，并且您需要确定如何设置主轴、拉伸和缩短挠曲布局
此零件可以使用弹性居中布局、弹性生长拉伸、弹性基础等
包型号
包型号
是CSS中一个很基础的概念，之前跟同学们说的时候，ta感觉很沉闷，实际百度首页的时候，用的是包模型的时候输入框和按钮对齐高度
CSS定位
在实现百度首页的时候，我们也可以使用 CSS 的定位位置属性来编写，比如下面这部分位于导航栏的最左边，就可以用定位来做：
总结
与传统的PCWeb或联通WEB不同，在腾讯视频学习的包端，连接大屏幕显示器（TV）的情况下，很多可以在PC端和移动端流畅运行的网页动画受到硬件层面的限制，包端的表现往往不尽如人意。
基于此，对于性能
网络动画的问题，仅仅停留在经过长时间优化的OK上是不够的，如果你想在包端运行一部接近60FPS的流畅动漫，你必须深入挖掘每一个可以改进的方法。
流畅动漫的标准
从理论上讲，FPS 越高，动画
更流畅，大多数设备的屏幕刷新率为60次/秒，所以一般来说，当FPS为60帧/秒时，动画效果最好，即每帧消耗时间为16.67ms。
直观的体验，不同的分辨率体验
包端动漫优化在
腾讯视频自习室的最后，在网页动画优化之前，一些复杂动画的分辨率只有10~30FPS，非常显著，带来了非常糟糕的用户体验。
经过优化，10~30FPS的动漫可以优化到30~60FPS，即使没有优化到最完美，在目前包包硬件的条件下，也已经有了非常大的改进。
包端网络动漫性能比较
首先，我们将比较不同类型的网络动漫在包侧的表现。相比之下，CSS动漫在包边的表现要优于Javascript动漫，而在CSS动漫中轮播图css，使用GPU硬件加速的动漫的表现要优于没有硬件加速的动画。
所以在包边，实现一个网络动漫，优先级是：
GPU硬件加速CSS动漫
>非硬件加速CSS动漫>Javascript动漫
动漫绩效报告剖析
要进行优化，您必须得到数据的支持。比较优化前后是否有改进。对于动漫，判断动漫的标准是 FPS 值。
所以现在的关键是如何估计每个动漫运行时的帧数，这里我使用 requestAnimationFrame 函数来估算动漫运行时的帧数。
考虑到包都是安卓，而且大部分都是较低版本，硬件性能不可预测，首先很多中间 API 很难用，其次，动漫分辨率只是近似于这里
原理是，通常技巧 requestAnimationFrame 会在 1 秒内执行 60 次，即没有屏幕流动。假设动漫从时间 A 开始，在时间 B 结束，持续 xms。如果中间请求动画帧总共执行n次，则此动画的功耗约为：n/（B-A）。
核心代码如下，可以近似每秒的页面分辨率，我们额外记录一个allFrameCount来记录rAF执行次数，以估计每个动漫的分辨率：
varrAF=function（）{
返回（
窗口请求动画帧||
窗口.webkit请求动画框架||
函数（回调）{
window.setTimeout（回调，1000/60）;
）;
}（）;
变框=0;
varallFrameCount=0;
varlastTime=Date.now（）;
varlastFameTime=Date.now（）;
varloop=function（）{
varnow=Date.now（）;
varfs=（now-lastFameTime）;
varfps=Math.round（1000/fs）;
上一个名声时间=现在;
如果没有0，在动画的开头和结尾记录这个值之间的差异来计算FPS
allFrameCount++;
框架++;
if（now>1000+lastTime）{
varfps=Math.round（（frame*1000）/（now-lastTime））;/
/console.log（'fps'，fps）;每秒帧数
帧=0;
上次时间=现在;
};
rAF（loop）;
研究推论
因此，我们的目标是在使用 GPU 硬件加速的基础上，更深入地优化 CSS 动画，并首先给出最后的优化步骤解决方案：
简化 DOM 并合理化布局
使用 TRANSFORM 而不是左侧和顶部以减少性能模型的使用
控制频繁动漫的层次结构关系
考虑使用遗嘱变更
使用开发工具时间线找出导致高运行时间和丢帧的关键操作
下面对每个步骤进行说明。
渲染网页的每一帧
要达到 60FPS，每帧的预算时间仅略高于 16 纳秒（1 秒/60 = 16.67 微秒）。但实际上，浏览器有一个整理工作要做，所以你的所有工作都需要在短短 10 微秒内完成。
而每一帧，如果需要，我们可以控制部分，这也是像素到屏流水线中的关键步骤如下：
完整的像素管线 JS/CSS >样式>布局>草图>合成：
JavaScript。一般来说，我们使用 JavaScript 来实现一些视觉变化的效果。例如，使用 jQuery 的 animate 函数制作动画、对数据集进行排序或向页面添加一些 DOM 元素。事实上，不仅是 JavaScript，还有其他常见的实现视觉变化效果的方法，比如 CSSAnimations、Transitions 和 WebAnimationAPI。
样式估计。此过程是使用匹配选择器（例如 .headline 或 .nav>.nav__item）来估计哪些 CSS3 规则适用于哪个元素的过程。一旦知道规则，就会应用规则并估计每个元素的最终样式。
布局。一旦你知道要对元素应用哪些规则，浏览器就可以开始估计它想要抓取多少空间及其在屏幕上的位置。网页的布局模式意味着一个元素可以影响其他元素，例如元素的长度，这通常会影响其子元素和整个树中的节点的长度，因此布局过程对于浏览器来说是经常发生的。
素描。草图是填充像素的过程。它涉及绘制文本、颜色、图像、边框和阴影，基本上包括元素的每个可见部分。草图通常在多个表面上完成，通常称为图层。
合成。由于页面的某些部分可能以多个图层绘制，因此需要以正确的顺序在屏幕上绘制这些草图才能正确呈现页面。这对于与另一个元素重叠的元素很重要，因为一个错误可能导致一个元素错误地显示在另一个元素下方。
事实上，并非每一帧都会经过管道的每个部分。我们的目标是，对于动画的每一帧，对于上面的流水线过程，如果可以预防就避免，如果无法阻止，则最大限度地优化。
优化动漫步骤
先给一个台阶，调一部动漫，有一定的准则要遵循，一步一步地进入动漫：
1. 简化 DOM 和合理布局
关于这一点没有太多要说的，但如果可以的话，简化 DOM 结构对页面随时都有帮助。
2. 使用 TRANSFORM 而不是左和上，以减少性能样式的使用
现代浏览器在完成具有以下四个属性的动漫时具有较低的消费成本：
如果可以，请尝试仅使用上述四个属性来控制动漫。不同的
风格在消费表现方面是不同的，改变一些属性比改变其他属性的成本更高，所以更容易冻结动画。
例如，更改元素的框阴影比更改元素的文本颜色需要更多的绘图。更改元素的宽度可能比更改其转换的开销稍高。例如，从呈现的角度来看，box-shadow 属性非常注重性能，因为与其他样式相比，它们的草图绘制代码执行时间太长。
这意味着，如果经常需要重新绘制性能密集型模型，则会遇到性能问题。其次，你需要知道没有什么是恒定的，明天性能不佳的模型今天可能会被优化，但浏览器之间也存在差异。
启用 GPU 硬件加速
在一天结束时
，以上四个属性动漫消费低的原因是GPU硬件加速开启了。动漫元素生成自己的图形层。
一般来说，我们可以使用启用GPU加速的方式
这会导致元素
声明 variant 属性以生成图形层，该图形层告诉浏览器元素将被转换，从而允许浏览器提前计划。
使用 will-change 并不一定会导致性能改进，并且由于浏览器仍将运行此属性的布局和草图绘制过程，即使它期望此更改，尽早告知浏览器也不会有太大的性能改进。这样做的好处是创建新视口的成本很高，最好在需要时匆忙创建它，而不是首先创建它。
对于 Safari 和一些无法识别意志变化的旧浏览器，他们需要使用某种 translate3D 进行黑客攻击，这通常是使用
因此，通常情况下，在生产环境中，我们可能需要使用以下代码来打开硬件加速：
将改变：变换;
变换：翻译Z（0）;
3.控制频繁动漫的等级关系
动漫级控制是指将需要CSS动画的元素的z索引尽可能保持在页面顶部，避免浏览器创建必要的图形层（GraphicsLayer）来提高渲染性能。
好的，这里
再次提到图形层，这是浏览器渲染原理的知识（在WebKit/blink内核下）。它可以加速动漫，但也有相应的加速坑！
简而言之，为了提高动漫的性能，浏览器不必在动漫的每一帧中每次都重绘整个页面。在特定形式中，可以触发它以生成具有单独图形层的合成层。
这需要动画的
元素都包含在这个合成层下，这样动画的每一帧只需要重绘图形层，从而达到提高动漫性能的目的。
此类元素何时触发图形层的创建？目前，当满足以下任一条件时，将创建一个图层：
这个小点中提到的动漫级别的控制原因，在于上一代层的最后一篇文章：
该元素具有低 z 索引的同级元素，并包含一个复合图层。
这是有坑的地方，首先我们需要清楚两件事：
我们希望我们的动漫是GPU加速的，所以我们将以类似transform：translateZ（）的形式生成一个GraphicsLayer层。
图形层
很好，但越多越好，渲染内核的每一帧都会遍历所有当前的 GraphicsLayers 并估计它们的下一帧重绘区域，因此过多的 GraphicsLayer 估计也会对渲染造成性能影响。
考虑到这两点，我们回到我们之前谈到的坑。
假设我们有一个带有 ul 列表的轮播，结构如下：
旋转木马地图
列表 李
列表 李
列表 李
列表 李
假设它们被定义为 CSS：
.swiper{
位置：静态;
动画：10s移动无限;
.list{
职位：相对;
@keyframesmove{
100%{
变换：翻译3d（10px，0，0）;
因为translate3d（10px，0，0）动漫被添加到.swipeper中，所以会生成一个GraphicsLayer，如右图所示，用开发者工具可以打开该图层的显示，图形外的白色边框代表生成一个单独的复合图层，具有单独的GraphicsLayer。
然而！在上图中，我们没有向下面的列表添加任何触发 GraphicsLayer 生成的属性，并且它还有一个黑色边框，生成一个单独的复合层。
原因是里面的元素有一个低 z 指数的同级元素和一个复合层。我们不希望列表元素也生成图形层，但由于 CSS 层次结构，较低的列表级别低于之前的划扫器，因此它被动地生成一个 GraphicsLayer。
使用 Chrome，我们还可以观察到这些层次结构关系，我们可以看到 .list 的层次结构低于 .swipeer 的层次结构：
因此，让我们将 CSS 更改为：
.swiper{
职位：相对;
z指数：100;
.list{
职位：相对;
在这里，我们明确地将 .swipeper 级别设为低于 .list，然后打开开发者工具观察：
可以看出，这一次，.list 元素早已失去了红色边框，说明此时还没有生成 GraphicsLayer。再看一下层次结构：
此时，层次结构是我们希望看到的，.list 元素不会触发 GraphicsLayer 的生成。我们希望需要硬件加速的.swipeper保持在顶部，并且仅在每次动画期间独立重绘该区域的这一部分。
总结这个坑最早
见于张云龙发表的文章中 CSS3硬件加速也有坑，这里总结补充：
4. 在元素的属性实际更改之前，使用将更改提前计划
例
.示例{
将改变：变换;
其中已经提到了意志改变。
Will-change 为 Web 开发人员提供了一种告诉浏览器元素将更改的方法轮播图css，以便浏览器可以在元素属性实际更改之前计划优化元素。这些优化可以提前计划一些复杂的估算工作，使页面更具响应性和响应性。
值得注意的是，要很好地使用此属性并不是很容易：
5. 使用开发工具时间轴观察找出导致高流逝时间和丢帧的关键操作1）对比截图，观察每帧包含的内容和具体操作 2）找到有帧数的帧，分析帧中不同步骤的经过时间比例，并有针对性地进行优化 3）观察是否存在内存泄漏并汇总
对于包边 CSS 动画的性能，很多方面还在探索中，本文中的很多内容在之前的文章中都已经出现过，这里更多的是总结和提炼成一个可以参考和执行的流程。
本文中的优化方案研究也适用于PCWeb和联通Web，文章难免会有错误和疏忽，请随时询问。
发表评论