如何形象地解释 JavaScript 中 map，foreach，reduce 间的区别

Posted 2023-04-25

Array.prototype.map()
map() 方法创建一个新数组，其结果是该数组中的每个元素调用一个提供的函数。

Array.prototype.forEach()
forEach() 方法对数组的每个元素执行一次提供的函数。

Array.prototype.reduce()
reduce() 方法对累加器和数组的每个值 (从左到右)应用一个函数，以将其减少为单个值。

虽然都是循环遍历一次 但是map跟reduce是可以带返回值的。
map可以在循环中用回调创建一个新的【数组】，
reduce可以在循环中用回调创建一个新的【单个值】，
forEach仅是循环 与基本的的for无异 参考技术A foreach相当于for遍历

浏览器如何读取和解释 CSS？

【中文标题】浏览器如何读取和解释 CSS？

【英文标题】：How do browsers read and interpret CSS?

【发布时间】：2011-04-01 11:09:48

【问题描述】：

两部分问题：

浏览器是否像 JavaScript 一样具有内置的 CSS 解释器？ 浏览器究竟何时读取 CSS，何时应用 CSS？

具体来说，我想澄清一下 JavaScript 和 CSS 是如何或为什么不同的，因为你需要专门等到 window.onload 才能让解释器正确地 getElementById。但是，在 CSS 中，您可以巧妙地选择样式并将其应用于类和 id。

（如果这很重要，假设我指的是一个头部带有外部样式表的基本 HTML 页面）

【参考方案1】：

CSS 渲染是一个有趣的话题，所有的竞争对手都在努力加速视图层（HTML 和 CSS）渲染，以便在眨眼之间为最终用户提供最佳效果。

首先，不同的浏览器都有自己的 CSS 解析器/渲染引擎

Google Chrome、Opera（来自版本 15）-

使用 Webkit fork 称为 Blink 渲染引擎

Safari - 使用 Webkit（

现在分叉为 Webkit2

） Internet Explorer - 使用Trident 渲染引擎。 （

+ 更新：Windows 10 上的 Edge 在其未来版本中使用 Chromium fork

） Mozilla firefox -

使用Gecko

所有这些渲染引擎都包含 CSS 解释器和HTML DOM parser。

所有这些引擎都遵循下面列出的模型，这些是W3C standard的集合

Visual processing Model Box Model CSS 2.1 Addressing Model

注意：所有这些模型都是相互关联和相互依赖的。他们是 不是单独的模型定义标准来呈现 CSS。这些型号 阐明如何根据内联样式等优先级处理 CSS， 特异性等。

---

解释：

---

第 1 阶段：

---

所有浏览器都从服务器下载 HTML 和 CSS 脚本，然后将 HTML 标记解析为名为 content tree 的树中的 DOM 节点。

当 HTML 文档被解析时，浏览器渲染引擎会构建另一棵树，称为 渲染树。这棵树是按显示顺序排列的视觉元素。

Firefox 将其称为框架，而 Webkit 将它们称为 Renderer 或 Renderer 对象。

见下图：（来源：HTML5 Rocks）

---

第 2 阶段：

---

在上述过程之后，这两棵树都会经过布局过程，这意味着浏览器会告诉视口每个节点必须放置在屏幕上的哪个位置。

这被W3C定义为定位方案（点击此链接了解详细信息），它指示浏览器如何以及在何处放置元素。以下是 3 种类型。

正常流 花车 绝对位置

---

第 3 阶段：

---

现在称为绘画的最后阶段。这是一个渐进的过程，渲染引擎遍历每个渲染树节点并使用 UI 后端层直观地绘制它们。此时所有visual Fx 都已应用，如字体大小、背景颜色、表格绘制等。

注意：如果您尝试打开任何 网页连接速度慢。为更好的用户而设计的大多数现代浏览器 经验尝试尽快显示元素。这给出了 用户的印象是页面正在加载并且必须等待完成。

---

工作流程框图以便更好地理解

来源HTML5 Rocks

Webkit：

Mozilla 的壁虎：

---

参考：（请阅读以下链接。它们是网络上与该主题相关的最佳资源）

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

（最佳解释）

http://www.slideshare.net/ariyahidayat/understanding-webkit-rendering https://html.spec.whatwg.org/multipage/syntax.html#parsing http://dbaron.org/talks/2008-11-12-faster-html-and-css/slide-3.xhtml https://css-tricks.com/almanac/properties/t/text-rendering/ https://www.webkit.org/blog/114/webcore-rendering-i-the-basics/ http://www.w3.org/TR/CSS21/intro.html#addressing

【讨论】：

基于这个流程，浏览器渲染一个css会不会很慢，其中颜色、背景颜色等都被提前声明了，定位和大小在选择器的末尾声明？我很想知道属性的定义顺序是否对渲染速度有影响，如果是，那么它是什么？

通常 CSS 是从下往上解释的。一些浏览器采用自上而下的方法。建议使用 LESS 或 SASS 等 CSS 预处理器，因为这些工具可帮助您编写高效的 CSS。顺序和方案不会影响速度，除非您不重复不必要地覆盖样式的代码，而是创建视觉错误，例如在 Jquery mobile 中修复著名的页脚。

这应该是公认的答案。更详细更完整

【参考方案2】：

如果您最近使用过慢速连接，您会发现 CSS 将在元素（缓慢）出现时应用到元素，实际上是在 DOM 结构加载时重排页面内容。由于 CSS 不是一种编程语言，它不依赖于在给定时间可用的对象来正确解析 (JavaScript)，并且浏览器能够在检索更多 HTML 时简单地重新评估页面的结构将样式应用于新元素。

也许这就是为什么即使在今天，Mobile Safari 的瓶颈始终不是 3G 连接，而是页面渲染。

【讨论】：

所以，澄清一下，浏览器循环遍历每个元素的 CSS 选择器，而不是循环遍历每个选择器的 HTML 元素？

不，浏览器以阻塞的方式下载和解释 CSS，一次消耗整个 CSS 语句或外部文件。因此，如果您的 CSS 位于头部，它会在渲染之前进行处理。然后，当 HTML 元素流入并被解释时，浏览器会在发现这些元素时不断将样式应用于这些元素。

【参考方案3】：

是的，浏览器内置了 CSS 解释器。您不“等到 window.onload”的原因是，虽然 Javascript 是图灵完备的命令式编程语言，但 CSS 只是浏览器的一组样式规则适用于它遇到的匹配元素。

【参考方案4】：

浏览器从右到左读取 CSS 行。这就是 Google 和 Mozilla 所说的。谷歌在http://code.google.com/speed/page-speed/docs/rendering.html 上说“引擎从右到左评估每条规则”。 Mozilla 在https://developer.mozilla.org/en/Writing_Efficient_CSS 上说“样式系统通过从键选择器开始，然后向左移动来匹配规则”

以这条 CSS 行为例：'.item h4'。浏览器首先搜索页面上的所有 'h4' 标签，然后查看 h4 标签是否有一个类名为 'item' 的父级。如果找到，则应用 CSS 规则。

【讨论】：

很好的答案，但它没有解释 when 浏览器这样做。它是否解析 CSS 文件，查看 .item h4，循环遍历所有 HTML 元素，然后应用样式，然后继续下一个 CSS 选择器？还是先解析 HTML，然后循环遍历 CSS 选择器，匹配.item h4，然后移动到下一个元素？

（来自我上面的评论）IOW，它是基于每个选择器循环遍历 HTML 元素，还是基于每个元素循环遍历 CSS 选择器？

【参考方案5】：

我最近偶然看到这篇关于谷歌页面速度的文章：

当浏览器解析 HTML 时，它会构建一个内部文档树来表示要显示的所有元素。然后，它根据标准 CSS 级联、继承和排序规则将元素与各种样式表中指定的样式进行匹配。在 Mozilla 的实现中（可能还有其他实现），对于每个元素，CSS 引擎都会搜索样式规则以找到匹配项。引擎从右到左评估每个规则，从最右边的选择器（称为“键”）开始，遍历每个选择器，直到找到匹配项或丢弃规则。 （“选择器”是规则应该应用到的文档元素。）

http://code.google.com/speed/page-speed/docs/rendering.html

【参考方案6】：

这是我找到的关于浏览器如何处理 HTML 和 CSS 的最佳描述：

渲染引擎将开始解析 HTML 文档并将标签转换为名为“内容树”的树中的 DOM 节点。它将解析外部 CSS 文件和样式元素中的样式数据。 HTML 中的样式信息和可视化指令将用于创建另一棵树 - 渲染树。

---

一般来说，渲染引擎的工作是：

标记规则（将输入分解为标记 AKA Lexer） 根据语言语法规则分析文档结构构建解析树

CSS 解析器

与 HTML 不同，CSS 是 context free grammar（具有确定性语法）。 所以我们将有CSS specification 定义 CSS 词法和语法语法， 解析器通过样式表应用。

词汇语法（词汇）由每个标记的正则表达式定义：

comment     \/\*[^*]*\*+([^/*][^*]*\*+)*\/
num     [0-9]+|[0-9]*"."[0-9]+
nonascii    [\200-\377]
nmstart     [_a-z]|nonascii|escape
nmchar      [_a-z0-9-]|nonascii|escape
name        nmchar+
ident       nmstartnmchar*

"ident" 是标识符的缩写，类似于类名。 "name" 是一个元素 id（由 "#" 引用）

语法语法在BNF中描述。

ruleset
  : selector [ ',' S* selector ]*
    '' S* declaration [ ';' S* declaration ]* '' S*
  ;
selector
  : simple_selector [ combinator selector | S+ [ combinator selector ] ]
  ;
simple_selector
  : element_name [ HASH | class | attrib | pseudo ]*
  | [ HASH | class | attrib | pseudo ]+
  ;
class
  : '.' IDENT
  ;
element_name
  : IDENT | '*'
  ;
attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ IDENT | STRING ] S* ] ']'
  ;
pseudo
  : ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ]
  ;

有关浏览器工作流程的详细说明，请查看article。

【讨论】：

文章提到 WebKit 使用 Flex 和 Bison 解析器生成器从 CSS 语法文件自动创建解析器。不过，我无法找到那些语法文件。任何想法？我也将此作为正式问题发布@@***.com/questions/31721308/…

【参考方案7】：

我相信浏览器会在找到 CSS 时对其进行解释，其效果是正文中的 CSS（内联）优先于头部中的 CSS（也是外部的）