从B站动身，用Chrome devTools performance阐发页面若何衬着

页面是若何衬着的？凡是会得到“解析 HTML、css 合成 Render Tree，就能够衬着了”的答复。但是详细都做了些什么，却很少有人细说，我们今天就从 Chrome 的性能东西起头，详细看看一个页面是若何停止衬着的，以及停止页面优化时需要存眷哪些目标。

以“老二次元”网站 bilibili 为例，我们将通过火析 performance 面板，串联起 Chrome 页面衬着流程，以及页面的部门量化目标的含义，来看页面详细是若何衬着的。

获取performance数据

起首，翻开Chrome devTools， 抉择 performace面板，点击录造按钮起头录造。

之后为了避免我们阐发页面时呈现无关的骚乱，我们通过以下步调降低骚乱项：

翻开 Chrome 无痕形式。

封闭所有在 Chrome 无痕形式下启用的拓展（假设有的话）。

在地址栏输进 面板，点击录造按钮。

在已经录造的情状下，地址栏回车，恳求 B 站，可能 10s 后，停行录造。

我们从上到下，将图分红以下几块，如下图所示：

展开全文

掌握面板

概览面板

收集面板

Web Vitals

线程面板

内存面板

聚合面板

掌握面板

掌握面板有 4 部门内容，别离为：

disable java samples：启用后会隐躲一些 JS 挪用栈的展现。在一些性能较弱的设备例如挪动端上，能够开启那项功用。

Network：能够用来模仿各类收集情况。

enableadvanced paint instrumention (slow)：启用后 paint 面板会展现与绘造相关事务的更详尽的信息。

CPU：能够用来模仿差别的 CPU 性能。

disable java samples：启用后会隐躲一些 JS 挪用栈的展现。在一些性能较弱的设备例如挪动端上，能够开启那项功用。

Network：能够用来模仿各类收集情况。

enableadvanced paint instrumention (slow)：启用后 paint 面板会展现与绘造相关事务的更详尽的信息。

CPU：能够用来模仿差别的 CPU 性能。

概览面板

概览面板是各项目标的一个概览，包罗了 FPS 帧数、CPU 占用、NET 情状、内存利用情状等。

简单举个例子，好比 FPS 帧数能够曲看的看出 FPS 的凹凸，绿色代表低的部门。而 CPU 栏的黄色代表着 js，紫色代表计算款式和规划，绿色代表绘造。

收集面板

收集面板用于展现正在恳求中的各部门的构成情状。

Web vitals

Web vitals 是网站的 Web 体验目标，此中包罗 LCP（更大内容绘造）、FID（初次输进延迟）、cls (累计规划偏移)等。

线程面板

线程面板用于展现衬着当前页面所利用到的线程，包罗有 Main 线程、GPU 线程、Raster 线程、Chrome_ChildIOThread、Compositor 线程等等。此中 Main 线程，就是我们日常平凡说的大部门 js 的运行情况，即主线程。

内存面板

展现 js 内存、GPU 内存、节点数、监听事务数的改变。

聚合面板

当点击主线程中的火焰图时，此面板会展现展现详细包罗施行时间、施行构成、挪用栈等等的信息聚集。

Chrome是若何衬着页面的？

第一个恳求

以第一个恳求为例，我们来详细看一下 Chrome 是若何停止页面衬着的？仍然是以对 中程度箱线图起头的部门。

此中两边横线中间深淡色方框的部门是程度箱线图，是用来展现某部门在整体中的比例关系。好比我们看到那个长长的箱型图，通过曲看感触感染，就能晓得对前面一部门横线挺长的，蓝色部门里淡色部门很长，深色的短，右边的横线几乎看不到。那那些又别离能展现什么信息？

起首，点开箱型图最下方的聚合面板（Summary），上面鲜明写着：此乃页面源。欲求小破站， 末生皆让我……耗时一秒半。

然后在 Network tab 里查看该恳求的 timing 部门，能够得到如下图：

那里的各个部门别离代表：

Queueing（列队）：阅读器会在一些情状下让恳求列队期待，好比那个恳求的优先级不高，有更高优先级的恳求存在；在利用 用于在磁盘缓存平分配空间。

Stalled（停顿）：它可能会因为上述列队中的任何原因而停顿。

DNS lookup（DNS 查询）：解析那个域名的IP地址。需要重视的是，当我们屡次拜候统一域名时，那部门不会呈现在 timing 中。

Initial connection（初始毗连）：阅读器成立毗连，包罗 tcp 三次握手、重试以及协商 SSL。图中的紫色部门，就代表了在初始毗连过程中的 SSL 协商部门。

Request sent（发送恳求）：正在发送恳求

Waiting (TTFB) 期待第一字节时间：阅读器在期待第一个响应的字节，TTFB 即 Time To First Byte。那个时间包罗一个往返的延迟和办事预备响应的时间之和。

Content Download （内容下载）：阅读器正在领受响应，阅读器能够通过收集或者 serviceWorker 来间接领受。那个值是读取响应体的总时间。因为收集欠安或者阅读器正在忙于施行其他工做而延迟了对响应体的读取，读取的时间可能会比预期的要长。

Queueing（列队）：阅读器会在一些情状下让恳求列队期待，好比那个恳求的优先级不高，有更高优先级的恳求存在；在利用 用于在磁盘缓存平分配空间。

Stalled（停顿）：它可能会因为上述列队中的任何原因而停顿。

DNS lookup（DNS 查询）：解析那个域名的IP地址。需要重视的是，当我们屡次拜候统一域名时，那部门不会呈现在 timing 中。

Initial connection（初始毗连）：阅读器成立毗连，包罗 tcp 三次握手、重试以及协商 SSL。图中的紫色部门，就代表了在初始毗连过程中的 SSL 协商部门。

Request sent（发送恳求）：正在发送恳求

Waiting (TTFB) 期待第一字节时间：阅读器在期待第一个响应的字节，TTFB 即 Time To First Byte。那个时间包罗一个往返的延迟和办事预备响应的时间之和。

Content Download （内容下载）：阅读器正在领受响应，阅读器能够通过收集或者 serviceWorker 来间接领受。那个值是读取响应体的总时间。因为收集欠安或者阅读器正在忙于施行其他工做而延迟了对响应体的读取，读取的时间可能会比预期的要长。

那里相信已经有小伙伴重视到了，当阅读器忙于其他工作时也会让读取时间变长。也就是说，当你的 js 把主线程持久占据的时候，就会影响 content download。

下图是 Network 下的对应资本的 waterfall：

如今我们回到最起头说的各色横条上，在程度箱线图中左上角的深蓝色小方块代表着那个恳求有着更高的优先级。碰着有浅蓝色的，则表达较低优先级。同时右边横线对应 Network 面板中展现的 Request Sent之前的所有工作的时间。淡色的 bar对应 Network 中 Request Sent 和 Waiting（TTFB）的时间。深色的 bar对应 Network中Content Download 的时间。右边的横线表达期待主线程所破费的时间，在 Network 面板中没有表现。

此外，可能还有些同窗重视到，在蓝色箱线图上面还能够看到还有几个灰色的箱线图。不是说 是页面的第一个恳求吗，莫非它之前还有恳求？

事实上，那个灰色箱线图相当于上一个页面的完毕。假设我们是通过从头录造的体例笔录 performance，那就会履历页面刷新的过程。而那几个灰色的其实就是页面刷新 unload 时倡议的，是 bilibili 用来笔录页面卸载时的一些数据。

说回到箱线图，能够看到在 summary 中展现 Duration 1.08 s (822.88 ms Network transfer + 260.20 ms resource loading)。那个的意思是 260ms 的时间是在 resource loading ，那里resource loading所破费的时间其实就是箱线图右侧的那条横线，期待主线程的时间。

而在 main 历程中，有横线完毕的处所，能够看到解码的数据 138,933 Bytes。

那里就呈现了几个问题：为什么Encode Data 33479 bytes 算下来是 33479/1024 = 32.69 k，而不是前面 Network 面板里的 33.5k ? 并且 Decode body 138993/1024 = 135.7k 也不是前面的 139k？贫乏的一部门数据是什么呢？

为了验证那个问题，需要清空过往所有恳求笔录，从头点击录造，录造完成后，导出收集恳求的 HAR 文件。利用 vscdoe 翻开 json 格局的 HAR 文件，觅觅 GET ：

能够看到，图上的 size 有140682 字节。text则是 base64 编码的 HTML 内容，已经被 decode 过。需要重视的是，那里的 decode 不是对 base64 的 decode，是对 gzip 的 decode。

而在那个 text 内容之后，还有一段如下内容：

此中的 _transferSize: 35593 是收集传输的体积，即传输的体积 35593 和 decode 体积 140682。同时我们在 performance 里的主历程中的 finish loading中能够看到下图数据：

如许一看，二者是不异的。阐明那个 HTML 的传输体积就是 35593 Bytes。

那为什么在 Network 面板里，我们看到的是 35.6k transferred over Network 呢？

那是因为在 Network 里展现的体积，不是除以 1024 计算的，而是除以 1000，然后四舍五进后的成果。

不外 Summary 里的 pending for xxx ms，似乎是也是期待主线程的时间，但它又是若何在 performance 表现的。目前，我还没搞清晰，假设有领会的小伙伴欢送留言讨论~

恳求其它资本

言回正传，我们如今获取到了 bilibili 网站的 HTML，接下来就需要对那个 HTML 停止处置。

通过 response header 得到 content-type:html，此时会创建一个个衬着历程，也就是主线程的那个历程。但是能够看到在主线程中的蓝色 parse HTML 之前，已经有良多 set request 被倡议了，并且那些 send request 都是 HTML 文档中的一些 js 和 css。

为什么会如许呢？不该该是先解析 HTML，才气晓得对哪些资本停止倡议恳求吗？

在 HTML 中引进的 js，存在修改 Dom 的可能，所以阅读器一般在碰着 标签后，会先暂停 HTML 解析，优先 js 的下载和施行。但是下载是相对耗时的，假设因为下载时间久而卡住了页面解析，很随便招致用户体验变差，因而 Chrome 摘用了一些优化战略。

详细来说，就是当 Chrome 衬着引擎领受到 HTML 的字节流时候，会开启一个专门用来阐发字节流中所包罗 js、css 文件的预解析线程。解析到相关信息之后，预解析线程会提早起头下载那些资本文件，如许在需要利用的时候就能够间接施行，制止了下载的期待时间。

但是也能看察到，在Parse HTML蓝色方块下方，还有一些 send request，那些怎么就不是提早下载的呢？

我的理解是，那些资本其实都是在预解析线程下载的，虽然在时间上会存在堆叠，但和主线程不属于统一个线程，所以 performance 东西会那么展现。但那又带来了另一个问题，为什么有些 js 明明在 HTML 的后面，却在前面就 send request 了，而有些 link/ 明明写在 HTML 里的前面，却在 performance 里后 send request？

那是跟资本的优先级有关。好比通俗的 标签引用的资本，通俗 link 引用的资本，或是rel=prelaod 或 as="style"预加载的资本，可能会被优先处置。而当资本是 prefetch，或者用 link rel="stylesheet" href="//s1.hdslb.com/bfs/static/jinkela/long/font/regular.css" media="print" ="this.media='all'"/那种体例的，因为优先级低，就会被延后下载。一般的其他资本，则按挨次下载。

回到 Network，能够看到在 ，那就表达了资本的重要水平。

那么那些资本的优先级是若何评定的？一般来说，拜候域名获取的 HTML、 以及预加载资本时as="style"，拥有更高优先级。通俗的 、 link 标签、 利用preload的预加载，拥有 高优先级。利用了 async/defer 的 、as=""的预加载资本拥有低优先级。利用了

link rel="stylesheet" href="//s1.hdslb.com/bfs/static/jinkela/long/font/medium.css" media="print" ="this.media='all'"

那种体例的，和不加 as="xxx"的 prefetch 预加载，就相当于异步加载，拥有更低优先级。

HTML Parse

好，到如今为行，我们已经将用到的 js、css、图片等资本下载了，然后就该进进解析 HTML 的过程了。

在 Chrome 衬着引擎内部，有个 HTMLParser 的模块。HTML 解析器负责将 HTML 转化为 Dom 构造。HTML 解析器并非等整个文档全数获取之后才起头解析，而是加载了"足够"的数据后，就起头解析了。

在 HTML Parser 的 summary 面板里能够看到，有个Range： 行。

那也从侧面印证领会析 HTML 的过程并非一次全数施行完的。

HTML 的解析生成 Dom 树的过程，能够参考文章（ 树中。

在 HTML 解析器工做过程中，会碰着 js、css 需要处置，好比蓝色条下面有黄色的 js 施行，有 parse stylesheet 的 css（那里的两个是 vendor.css 和 index.css）解析和 cssom 的构建。

当拿到了 vendor.css 和 index.css 那两个外部款式文件之后，就起头了 Recalculate Style 的过程，也就是在停止一些可能包罗递回（好比想晓得父容器的大小就得先晓得子元素的大小）的款式计算。重视，那时候 HTML 仍是没有完全解析完的，但是一旦款式计算完毕，就起头 Layout过程。

那里的Layout对应的是将 Dom tree 和 cssom 连系成 render tree的过程。render tree 是不包罗例如meta、display: none那些无需展现的元素。

分层

在款式计算之后，还需要履历一个pre-paint的过程，然后才气paint。

以前那里喊做 update layer tree， 2022年3月份之后改成了 pre-paint。那里其实是遍历 render tree 生成 layer tree 的过程。

render tree 和 layer tree 有啥差别呢？

render tree 是 Dom 和 cssom 连系的产品，是将计算后的款式添加到了 Dom 节点上。但是目前只是晓得了节点能否可见以及可见款式，还不晓得节点的切确位置和大小，那时候就需要规划。衬着引擎从　render tree　的根节点起头遍历，通过必然的规则处置后，将会得到一个 layout tree，那个 layout tree 切确的描述了每个视口内元素的位置和切当尺寸，所有的相对位置城市改变成屏幕上的绝对位置，在得知了节点能否可见、款式、位置几何信息之后，衬着引擎才有时机将 render tree　上的每个节点都转换成屏幕上的像素，那个过程也就是一般说的 绘造 paint或者栅格化 Rastering。

那 layer tree 在哪儿呢？layer tree 就在栅格化的过程傍边。

在说栅格化之前，有需要提一下　Chrome 是若何将衬着视口内的内容的。

过往　Chrome 是只在用户可视区域内停止栅格化，跟着用户滚动不竭滚动页面而调整栅格化区域，陆续栅格化并将内容填充到缺失部门。如许的缺点是当用户快速滚动的时候，页面会有卡顿感。

而如今 Chrome 摘用了一种合成 composting 的体例，将页面中的某些部门分红差别的层，别离栅格化它们，然后在合成器线程中合成。如许在页面滚动时，原素材已经有了（预备好的那些层），只需要将视口内的蹭合成为一个新帧即可。如许在用户滚动时，新帧的合效果率更高。

既然需要分层，那就要晓得那些元素应该在哪一层里，所以衬着引擎需要根据必然规则再遍历一次 layout tree 来创建 layer tree ，那个过程也就是 pre-paint，以前喊做 update layer tree。

分层也需要根据必然的规则，不是肆意一个元素都能够被拎出来当做一层，次要是两个前提：

拥有层叠上下文属性的元素会被创建成图层

拥有层叠上下文属性的元素会被创建成图层

页面是个二维的，但是层叠上下文属性会让　HTML　元素具有三维的概念。那些元素根据本身的属性优先级散布在垂曲页面的　Z　轴之上，哪些元素拥有详细参考　MDN。

需要被裁剪的处所会被创建为图层

需要被裁剪的处所会被创建为图层

当你现实的内容比容器还大的时候，就会呈现裁剪，引擎会裁剪一部门内容展现在容器区域。一般来说，呈现滚动条就会被创建为图层。

称心以上肆意一个前提就会被提拔成零丁一层。

那那在 Chrome devtools 哪里能够表现呢？在 devtools - 右侧三个点 - more tools - layers 里能够看到页面现实上被分红了许多层。

点击左侧的详细图层，能够看到详尽的绘造过程。Details 里还有被提拔为一层的原因composition reason。

Paint

通过前面分层，我们得知了元素的层级关系，但是还不晓得统一层内元素的层级关系。一般来说，后面的内容会笼盖前面内容，但是阅读器该若何晓得谁该笼盖谁呢？

那就需要衬着引擎为每一个图层创建绘造笔录 patint record 并确定谁先画谁后画，那么后画的必定就会笼盖先画的。绘造笔录能够看做一个单向链表 div - div - p - span，遍历链表即可获得绘造挨次。

如今有了图层，也有了绘造笔录挨次，那些信息将会被提交到合成器线程中停止绘图和合成。因为一个图层可能会十分大，超越了视口面积，那么图层就会履历一次朋分过程，朋分成一个个小的图块 Tile，凡是是 256*256 或 512*512 大小，那些图块停止会传递给栅格化线程池。池中的栅格化线程施行栅格化使命 Raster Task，将图块生成位图 bitmap，并优先生成视口四周的位图。

那个过程在performamce里喊做Rasterize Paint。

栅格化过程也会利用 GPU 来加速，一般又称为快速栅格化，GPU 栅格化。那也是为什么会有些 css 里写 will-change：transfrom 或者 transform: translateZ(0)，就是为了 GPU 参与绘造。素质上是操纵 will-change 和 translateZ(0) 创建了新的衬着层，从而不影响其他层级的绘造内容。

当所有的 Tile 栅格化完毕，合成器线程搜集 Draw Quads 的图块信息。Draw Quads 笔录了图块在内存中的位置和在页面阿谁位置停止绘造。然后主线程搜集那些 Draw quards 信息并合成合成器帧，并交给 GPU衬着，然后才是像素呈现在屏幕之上。那个过程在 perfomrance 里是 Compositie layers。

可惜我没有在 performance 里找到更详尽的信息来展现那个过程。

页面衬着可能就是上述的过程，次要是连系 performance 面板串联起过往的那些常识。领会了页面衬着流程，我们该若何优化页面性能呢？又需要存眷那些目标呢？

页面优化存眷哪些目标

那个目标不是凭空创造，也不是仅凭觉得，那应该是一些明白的、能够量化的目标。Chrome devtool lightHouse 列举了 6 个目标。

FCP

First content paint 代表阅读器衬着出第一个 Dom content 的时间。那里的 Dom content 包罗图片、非空白 canvas、svgs 等。假设你的页面里有 iframe，iframe 里的任何工具都不会被当成 Dom content。

FCP 好坏原则也是跟着搜集到的页面数据来不竭改变的，我们能够从 地址来查看如今世界上的页面的中位数是几。

根据目前的目标来看，FCP 时间能够简单的分为 3 档：

0 - 1.9s，1.9s - 3s，3s以上，它们别离代表还行、很一般、不太行。

当我们在某个页面中利用 LightHouse 停止评估的时候，可能会看到虽然 FCP 只要 1s，展现的也是橙色标识表记标帜。

LightHouse 里的得分是根据百分比来的。也就是说当你的 FCP 时间，是所有页面中的前 10%， 那么能够得到 90 分， 前 1% 能够得到 99 分，得到 90-100 分才会是绿色。其他的几个目标也是同样的评判原则。

影响 FCP 的原因有良多，此中一个比力常见的原因是自定义字体的加载，字体文件的加载需要必然时间，在字体文件加载完成之前，差别的阅读器会摘用差别的战略。

edge：在字体预备好前利用系统字体

Chrome：隐躲文本内容。假设 3s 后自定义字体还没预备好，则利用系统字体，曲到字体预备好，然后替代字体。

火狐：同 Chrome

safari：隐躲文本曲到字体预备好。

一个简单的办法是在@font-face 演示里增加 font-display: swap

@font-face {font-family: 'Pacifico';font-style: normal;font-weight: 400;src: url(;}

设置 swap 就是告诉阅读器是利用该字体的文本应该立即利用系统字体停止展现，当自定义字体预备停当后，替代系统字体。

或者利用 prefetch / preload 来提早获取字体相关资本。

Time to intercative

TTI 标识表记标帜着页面多久能够停止完全交互。

那里的完全交互是指：

页面已经展现了 FCP

事务处置函数已经为大部门可见页面元素停止了注册绑定

页面可以在 50ms 内对用户行为停止反响

页面已经展现了 FCP

事务处置函数已经为大部门可见页面元素停止了注册绑定

页面可以在 50ms 内对用户行为停止反响

同样我们在 的中位数是几。

降低 TTI 的常见构想是代码朋分、按需加载，删除未利用代码、压缩代码、压缩收集负载、削减 JS 对主线程的长时间占用。

Speed Index

那个目标代表了用户感知的可见区域的页面加载的快慢。

也分红 0-3.4s 、 3.4 - 5.8、超越 5.8 三挡。但是得分也同样是跟全球网页数据来比照的。

进步 speed index 的次要是通过削减 js 对主线程阻塞，让一些非需要的 js 在 Dom 衬着后再施行。

Total Block Time

总阻塞时间。那个时间是从 FCP 到 TTI 之间所有的长使命阻塞部门的时间之和。

长使命是指施行时间超越 50ms 的使命，50ms 之后的时间量就是阻塞时间。

既然是阻塞时间，降低 TBT 的办法就是想办法削减没必要要的 js 的加载、解析和施行。拆分大型脚本，对某些非同步需要的 js 利用 defer/async 或者 prefetch/preload 、或者容许的情状下停止懒加载/延迟加载、将静态资本摆设到 CDN 等等。

Largest Contentful Paint

更大内容绘造。笔录的是视口中更大的内容元素被衬着到屏幕的时间，也大致分为 0-2.5s、2.5s-4s、超越 4s 三个大范畴。

那里的类容元素是指：

img

svg 内嵌的 image 元素

利用了封面的video 元素

url 加载的带布景图的元素

包罗文本或者其他行内文本元素子元素的块级元素

img

svg 内嵌的 image 元素

利用了封面的video 元素

url 加载的带布景图的元素

包罗文本或者其他行内文本元素子元素的块级元素

重视，假设元素溢出到可视区域之外，则不算 LCP。

LCP 次要手4个方面的影响：

迟缓的办事器响应速度

迟缓的办事器响应速度

应对计划：CDN、预加载、serviceWorker

js/css 的衬着阻塞

js/css 的衬着阻塞

应对计划：

用optimize-css-assets-Webpack-plugin、uglyifyJS之类的 Webpack 插件压缩 css、js

对非需要的 js、css 延迟加载，如非需要 css 用预加载，在触发事务后再往 import xx from 'xxx'。

适宜的情状下利用内联 css。

迟缓的资本加载速度

压缩图像

预加载重要资本

压缩文本文件 Gzip、br

serviceWorker 停止缓存

客户端衬着

压缩 js

延迟加载未立即利用的 js

尽可能削减polyfill。"targets":"0.25%"

迟缓的资本加载速度

压缩图像

预加载重要资本

压缩文本文件 Gzip、br

serviceWorker 停止缓存

压缩图像

预加载重要资本

压缩文本文件 Gzip、br

serviceWorker 停止缓存

客户端衬着

压缩 js

延迟加载未立即利用的 js

尽可能削减polyfill。"targets":"0.25%"

压缩 js

延迟加载未立即利用的 js

尽可能削减polyfill。"targets":"0.25%"

Cumulative Layout Shift

有些时候我们会碰着，初始加载时字体突然变大/变小， 元素位置突然挪动位等。

CLS 就是通过丈量发作偏移的频次来表达出页面的不不变性。

常见的招致 CLS 比力差的原因有：

没指定宽高的图片

没有设置宽高的 iframe

没有设置宽高的资本位（顶部 banner、告白等）

前面提到的 无款式文本闪烁（FOUT， 用默认字体替代新字体）/ 不成见文本闪烁（FOIT，获取新字体前的展现不成见文本）。link rel=preload和font-display: optional连系利用

动画利用了修改 width、height、top、right、bottom、left 等属性值的体例来实现。应优先利用 css transfrom来实现动画。

没指定宽高的图片

没有设置宽高的 iframe

没有设置宽高的资本位（顶部 banner、告白等）

前面提到的 无款式文本闪烁（FOUT， 用默认字体替代新字体）/ 不成见文本闪烁（FOIT，获取新字体前的展现不成见文本）。link rel=preload和font-display: optional连系利用

动画利用了修改 width、height、top、right、bottom、left 等属性值的体例来实现。应优先利用 css transfrom来实现动画。

以上就是目前 Chrome lighthouse 用来揣度页面体验的 6 个目标。假设我们要优化页面，也应从那 6 个方面来进手，一一改进，在现有的可量化目标下有的放矢。

参考材料：

一周热点 | 2023.02.08-2023.02.14 顶流开源项目做者全职做开源的“血泪史”：进狱、耗尽积存、被网暴…… 非WebKit引擎的iOS阅读器即将到来

那里有最新开源资讯、软件更新、手艺干货等内容

点那里 ↓↓↓ 记得 存眷✔ 标星⭐ 哦