安科网

浏览器渲染机制

jiangbo0

jiangbo0

2019-07-01

关注 关注
本文示例源代码请戳github博客，建议大家动手敲敲代码。

前言

浏览器渲染页面的过程

从耗时的角度，浏览器请求、加载、渲染一个页面，时间花在下面五件事情上：

  1. DNS 查询
  2. TCP 连接
  3. HTTP 请求即响应
  4. 服务器响应
  5. 客户端渲染

本文讨论第五个部分，即浏览器对内容的渲染，这一部分（渲染树构建、布局及绘制），又可以分为下面五个步骤：

  1. 处理 HTML 标记并构建 DOM 树。
  2. 处理 CSS 标记并构建 CSSOM 树
  3. 将 DOM 与 CSSOM 合并成一个渲染树。
  4. 根据渲染树来布局，以计算每个节点的几何信息。
  5. 将各个节点绘制到屏幕上。

需要明白，这五个步骤并不一定一次性顺序完成。如果 DOM 或 CSSOM 被修改，以上过程需要重复执行，这样才能计算出哪些像素需要在屏幕上进行重新渲染。实际页面中，CSS 与 JavaScript 往往会多次修改 DOM 和 CSSOM。

1、浏览器的线程

在详细说明之前我们来看一下浏览器线程。这将有助于我们理解后续内容。

浏览器是多线程的，它们在内核制控下相互配合以保持同步。一个浏览器至少实现三个常驻线程：JavaScript 引擎线程，GUI 渲染线程，浏览器事件触发线程。

  • GUI 渲染线程：负责渲染浏览器界面 HTML 元素，当界面需要重绘（Repaint）或由于某种操作引发回流（reflow）时，该线程就会执行。在 Javascript 引擎运行脚本期间，GUI 渲染线程都是处于挂起状态的，也就是说被”冻结”了。
  • JavaScript 引擎线程：主要负责处理 Javascript 脚本程序。
  • 定时器触发线程：浏览器定时计数器并不是由 JavaScript 引擎计数的， JavaScript 引擎是单线程的， 如果处于阻塞线程状态就会影响记计时的准确， 因此浏览器通过单独线程来计时并触发定时。
  • 事件触发线程：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JS 引擎的处理。这些事件包括当前执行的代码块如定时任务、浏览器内核的其他线程如鼠标点击、AJAX 异步请求等。由于 JS 的单线程关系所有这些事件都得排队等待 JS 引擎处理。定时块任何和 ajax 请求等这些异步任务，事件触发线程只是在到达定时时间或者是 ajax 请求成功后，把回调函数放到事件队列当中。
  • 异步 HTTP 请求线程：在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求， 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。在发起了一个异步请求时，http 请求线程则负责去请求服务器，有了响应以后，事件触发线程再把回到函数放到事件队列当中。

2、构建DOM树与CSSOM树

浏览器从网络或硬盘中获得HTML字节数据后会经过一个流程将字节解析为DOM树：

  • 编码： 先将HTML的原始字节数据转换为文件指定编码的字符。
  • 令牌化： 然后浏览器会根据HTML规范来将字符串转换成各种令牌（如<html>、<body>这样的标签以及标签中的字符串和属性等都会被转化为令牌，每个令牌具有特殊含义和一组规则）。令牌记录了标签的开始与结束，通过这个特性可以轻松判断一个标签是否为子标签（假设有<html>与<body>两个标签，当<html>标签的令牌还未遇到它的结束令牌</html>就遇见了<body>标签令牌，那么<body>就是<html>的子标签）。
  • 生成对象： 接下来每个令牌都会被转换成定义其属性和规则的对象（这个对象就是节点对象）
  • 构建完毕： DOM树构建完成，整个对象集合就像是一棵树形结构。可能有人会疑惑为什么DOM是一个树形结构，这是因为标签之间含有复杂的父子关系，树形结构正好可以诠释这个关系（CSSOS同理，层叠样式也含有父子关系。例如： div p {font-size: 18px}，会先寻找所有p标签并判断它的父标签是否为div之后才会决定要不要采用这个样式进行渲染）。

整个DOM树的构建过程其实就是： 字节 -> 字符 -> 令牌 -> 节点对象 -> 对象模型，
下面将通过一个示例HTML代码与配图更形象地解释这个过程。

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

浏览器渲染机制

当上述HTML代码遇见<link>标签时，浏览器会发送请求获得该标签中标记的CSS文件（使用内联CSS可以省略请求的步骤提高速度，但没有必要为了这点速度而丢失了模块化与可维护性），style.css中的内容如下：

body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }

浏览器获得外部CSS文件的数据后，就会像构建DOM树一样开始构建CSSOM树，这个过程没有什么特别的差别。
浏览器渲染机制

3、构建渲染树

在构建了DOM树和CSSOM树之后，浏览器只是拥有了两个互相独立的对象集合，DOM树描述了文档的结构与内容，CSSOM树则描述了对文档应用的样式规则，想要渲染出页面，就需要将DOM树与CSSOM树结合在一起，这就是渲染树。
浏览器渲染机制

  • 浏览器会先从DOM树的根节点开始遍历每个可见节点（不可见的节点自然就没必要渲染到页面了，不可见的节点还包括被CSS设置了display: none属性的节点，值得注意的是visibility: hidden属性并不算是不可见属性，它的语义是隐藏元素，但元素仍然占据着布局空间，所以它会被渲染成一个空框）
  • 对每个可见节点，找到其适配的CSS样式规则并应用。
  • 渲染树构建完成，每个节点都是可见节点并且都含有其内容和对应规则的样式。

4、布局与绘制

CSS采用了一种叫做盒子模型的思维模型来表示每个节点与其他元素之间的距离，盒子模型包括外边距(Margin)，内边距(Padding)，边框(Border)，内容(Content)。页面中的每个标签其实都是一个个盒子

浏览器渲染机制
布局阶段会从渲染树的根节点开始遍历，然后确定每个节点对象在页面上的确切大小与位置，布局阶段的输出是一个盒子模型，它会精确地捕获每个元素在屏幕内的确切位置与大小，所有相对的测量值也都会被转换为屏幕内的绝对像素值。

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Critial Path: Hello world!</title>
  </head>
  <body>
    <div style="width: 50%">
      <div style="width: 50%">Hello world!</div>
    </div>
  </body>
</html>

浏览器渲染机制

当Layout布局事件完成后，浏览器会立即发出Paint Setup与Paint事件，开始将渲染树绘制成像素，绘制所需的时间跟CSS样式的复杂度成正比，绘制完成后，用户就可以看到页面的最终呈现效果了。

我们对一个网页发送请求并获得渲染后的页面可能也就经过了1~2秒，但浏览器其实已经做了上述所讲的非常多的工作，总结一下浏览器关键渲染路径的整个过程：

  • 处理HTML标记数据并生成DOM树。
  • 处理CSS标记数据并生成CSSOM树。
  • 将DOM树与CSSOM树合并在一起生成渲染树。
  • 遍历渲染树开始布局，计算每个节点的位置信息。
  • 将每个节点绘制到屏幕。

5、外部资源是如何请求的

为了直观的观察浏览器加载和渲染的细节，本地用nodejs搭建一个简单的HTTP Server。
index.js

const http = require('http');
const fs = require('fs');
const hostname = '127.0.0.1';
const port = 8080;
http.createServer((req, res) => {
  if (req.url == '/a.js') {
    fs.readFile('a.js', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      setTimeout(function () {
        res.write(data);
        res.end()
      }, 5000)
    })
  } else if (req.url == '/b.js') {
    fs.readFile('b.js', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      res.write(data);
      res.end()
    })
  } else if (req.url == '/style.css') {
    fs.readFile('style.css', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/css'});
        res.write(data);
        res.end()
    })
  } else if (req.url == '/index.html') {
    fs.readFile('index.html', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.write(data);
      res.end()
    })
  }
}).listen(port, hostname, () => {
  console.log('Server running at ' + hostname + '：' + port);
});

index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
    <script src='http://127.0.0.1:8080/a.js'></script>
</head>
<body>
<p id='header'>1111111</p>
<script src='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

style.css

#header{
    color: red;
}

a.js、b.js暂时为空
可以看到，服务端将对a.js的请求延迟5秒返回。Server启动后，在chrome浏览器中打开http://127.0.0.1:8080/index.html
我们打开chrome的调试面板
浏览器渲染机制
第一次解析html的时候，外部资源好像是一起请求的，说资源是预解析加载的，就是说style.css和b.js是a.js造成阻塞的时候才发起的请求，图中也是可以解释得通，因为第一次Parse HTML的时候就遇到阻塞，然后预解析就去发起请求，所以看起来是一起请求的。

6、HTML 是否解析一部分就显示一部分

我们修改一下html代码

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<script src='http://127.0.0.1:8080/a.js'></script>
<script src='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

浏览器渲染机制
因为a.js的延迟，解析到a.js所在的script标签的时候，a.js还没有下载完成，阻塞并停止解析，之前解析的已经绘制显示出来了。当a.js下载完成并执行完之后继续后面的解析。当然，浏览器不是解析一个标签就绘制显示一次，当遇到阻塞或者比较耗时的操作的时候才会先绘制一部分解析好的。

7、js文件的位置对HTML解析有什么影响

7.1 js文件在头部加载。

修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
    <script src='http://127.0.0.1:8080/a.js'></script>
    <script src='http://127.0.0.1:8080/b.js'></script>
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
</body>
</html>

浏览器渲染机制
因为a.js的阻塞使得解析停止，a.js下载完成之前，页面无法显示任何东西。

7.2、js文件在中间加载。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<script src='http://127.0.0.1:8080/a.js'></script>
<script src='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

浏览器渲染机制
解析到js文件时出现阻塞。阻塞后面的解析，导致后面的不能很快的显示。

7.3、js文件在尾部加载。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script src='http://127.0.0.1:8080/a.js'></script>
<script src='http://127.0.0.1:8080/b.js'></script>
</body>
</html>

解析到a.js部分的时候，页面要显示的东西已经解析完了，a.js不会影响页面的呈现速度。

由上面我们可以总结一下

  • 直接引入的 JS 会阻塞页面的渲染（GUI 线程和 JS 线程互斥）
  • JS 不阻塞资源的加载
  • JS 顺序执行，阻塞后续 JS 逻辑的执行

下面我们来看下异步js

7.4、async和defer的作用是什么？有什么区别?

接下来我们对比下 defer 和 async 属性的区别：
浏览器渲染机制
其中蓝色线代表JavaScript加载；红色线代表JavaScript执行；绿色线代表 HTML 解析。

  • 情况1<script src="script.js"></script>

没有 defer 或 async，浏览器会立即加载并执行指定的脚本，也就是说不等待后续载入的文档元素，读到就加载并执行。

  • 情况2<script async src="script.js"></script> (异步下载)

async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行——无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。

  • 情况3 <script defer src="script.js"></script>(延迟执行)

defer 属性表示延迟执行引入的 JavaScript，即这段 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，然后触发 DOMContentLoaded 事件。

defer 与相比普通 script，有两点区别：

  • 载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。
  • 在加载多个JS脚本的时候，async是无顺序的加载，而defer是有顺序的加载。

8、css文件的影响

服务端将style.css的相应也设置延迟。

fs.readFile('style.css', 'utf-8', function (err, data) {
  res.writeHead(200, {'Content-Type': 'text/css'});
  setTimeout(function () {
    res.write(data);
    res.end()
  }, 5000)
})
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script src='http://127.0.0.1:8080/a.js' async></script>
<script src='http://127.0.0.1:8080/b.js' async></script>
</body>
</html>

可以看出来，css文件不会阻塞HTML解析，但是会阻塞渲染，导致css文件未下载完成之前已经解析好html也无法先显示出来。

我们把css调整到尾部

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
<script src='http://127.0.0.1:8080/a.js' async></script>
<script src='http://127.0.0.1:8080/b.js' async></script>
</body>
</html>

这是页面可以渲染了，但是没有样式。直到css加载完成

以上我们可以简单总结。

  • CSS 放在 head 中会阻塞页面的渲染（页面的渲染会等到 css 加载完成）
  • CSS 阻塞 JS 的执行 （因为 GUI 线程和 JS 线程是互斥的，因为有可能 JS 会操作 CSS）
  • CSS 不阻塞外部脚本的加载（不阻塞 JS 的加载，但阻塞 JS 的执行，因为浏览器都会有预先扫描器）

参考
浏览器渲染过程与性能优化
聊聊浏览器的渲染机制
你不知道的浏览器页面渲染机制

线程阻塞 html代码 线程 javascript

jiangbo0

jiangbo0

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

彻底搞懂 Netty 线程模型

在学习Netty 之前我们最好先掌握 BIO、NIO、AIO 基础知识，前面我们已经花了三篇文章去讲这些知识。我们开始来学习 Netty 的具体知识了，本文就Netty线程模型展开分析。简单来说，内核将可读可写事件通知应用，由应用主动发起读写事件；NIO

arctan0 2020-10-14

Linux系统编程—信号量

大家知道，互斥锁可以用于线程间同步，但是，每次只能有一个线程抢到互斥锁，这样限制了程序的并发行。如果我们希望允许多个线程同时访问同一个资源，那么使用互斥锁是没有办法实现的，只能互斥锁会将整个共享资源锁住，只允许一个线程访问。这种现象，使得线程依次轮流运行，

hackerlpy 2020-09-25

漫话：应用程序被拖慢？罪魁祸首竟然是Log4j！

之前一段时间，为我们发现的一个SaaS应用程序会间歇性地卡顿、变慢，因为很长时间都没有定位到原因，所以解决的办法就只能是重启。这个现象和之前我们遇到的程序变得卡顿不太一样，因为我们发现这个应用程序不仅在高流量期间时会变慢，有时在低流量时期也会变慢。所以这令

大唐帝国前营 2020-08-18

高性能 Java 应用层网关设计实践

不少人对 Java 网关的实现也比较感兴趣，所以这篇文章我们来简单谈谈 Java 应用网关设计，本文将会从以下几个方面来阐述 Java 应用层网关的设计。接入层流量首先进入 Java 核心网关，经过一系列的 pipeline 处理后发起泛化调用再打入业务

yuanlu 2020-08-17

区分python中的进程与线程

今天整理的文章是给大家梳理Python的进程与线程的区别，没什么代码，希望大家能清楚知道他们的区别，什么情况用线程，什么情况用进程做到心中有数，希望大家能熟练掌握.进程一般由程序、数据集、进程控制块三部分组成。提高并发性,通过线程可方便有效地实现并发性。在

chunjiekid 2020-08-16

Linux平台服务器多线程开发（一）

根据运行环境和调度者的身份，线程可分为内核线程和用户线程。可见，内核线程相当于用于线程运行的容器。换句话说，一个进程的所有执行线程共享该进程的时间片，它们对外表现出相同的优先级。并且由于它不占用额外的内核资源，所有即使一个进程创建了很多线程，也不会对系统性

cuiweisaidelike 2020-08-02

Linux平台服务器多线程开发（一）

根据运行环境和调度者的身份，线程可分为内核线程和用户线程。可见，内核线程相当于用于线程运行的容器。换句话说，一个进程的所有执行线程共享该进程的时间片，它们对外表现出相同的优先级。并且由于它不占用额外的内核资源，所有即使一个进程创建了很多线程，也不会对系统性

comeonxueRong 2020-08-02

Android开发笔记：使用 runOnUiThread() 方法更新 UI

在Android中对UI进行操作是不允许在子线程中进行的，但是直接在主线程中进行UI操作容易造成阻塞导致应用卡顿。一般使用runOnUiThread()方法在需要进行UI操作的时候将当前线程切换到主线程，使用方法如下：

zzqLivecn 2020-07-09

C语言多线程

线程在Unix系统下，通常被称为轻量级的进程，线程虽然不是进程，但却可以看作是Unix进程的表亲，同一进程中的多条线程将共享该进程中的全部系统资源，如虚拟地址空间，文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈，自己的寄存器环境，自己的线程

yunfeitian 2020-07-05

JDK源码那些事儿之传说中的AQS-概览

从这篇文章开始分析JDK源码中AQS的底层实现原理，作为多线程访问共享资源的同步器框架基础实现，涉及到的东西还是比较多的，一起来看看传说中的AQS实现吧。由于涉及到AQS篇幅过多，本篇先总体介绍AQS，分析部分源码实现，对于共享资源的获取和释放以及Cond

hell0kitty 2020-07-04

C# 多线程的阻塞和继续

　　在工作中，会遇到需求多线程处理相应的业务需求，最典型的包括Socket的通信。　　多线程处理里，就会考虑到，哪个线程先运转，哪个线程后运转的情况。　　这里我介绍一下，运用ManualResetEvent类来对线程进行堵塞和持续操作。　　它有三个重要的办

TreasureZ 2020-06-25

【MySQL】05-锁

根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock 。全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都select出来存成

阿亮 2020-06-21

python 锁

每个线程在执行的过程都需要先获取GIL，保证同一时刻只有一个线程可以执行代码。计数器不能为0，当计数器为0时acquire（）将阻塞线程，直到其他线程调release（）。

小菜鸟的代码世界 2020-06-17

我的jdk源码（二十三）：ReentrantLock类

ReentrantLock再将Sync作进一步的封装，开放出去Lock的接口。ReentrantLock是通过在请求锁的时候判断CLH列表有没有比当前线程等待时间更久的线程来实现公平性的。否则请求直接失败。非公平锁没有这个限制，只要state为0,就可以使

凉白开 2020-06-17

Netty（五）Netty 高性能之道

通过使用 Netty相比于传统基于 Java 序列化+BIO的通信框架，性能提升了 8 倍多。实上，我对这个数据并不感到惊讶，根据我多的 NIO 编程经验，通过选择合适的 NIO 框架，精心的设计 Reactor 线程。模型，达到上述性能指标是完全有可能的

gzx0 2020-06-14

C++11多线程 – Part 8:std::future，std::promise以及线程的返回值

本文主要关注将std::future与std::promise对象一起使用。很多时候，我们遇到希望线程返回结果的情况。现在的问题是如何做到这一点？将指针传递给新线程，该线程将在其中设置数据。当新线程设置数据并向条件变量发出信号时，主线程将唤醒并从该指针获取

Magicsoftware 2020-06-01

第53天： Python 线程池

大家都知道当任务过多，任务量过大时如果想提高效率的一个最简单的方法就是用多线程去处理，比如爬取上万个网页中的特定数据，以及将爬取数据和清洗数据的工作交给不同的线程去处理，也就是生产者消费者模式，都是典型的多线程使用场景。那是不是意味着线程数量越多，程序的执

fengling 2020-05-31

python 线程通信 生产者与消费者

线程通信的生产者与消费者。python的queue模块中提供了同步的线程安全的队列类,都具有原子性，实现线程间的同步。用于消费者，每次get()以后，使用task_done() 是告诉队列正在处理的get任务完成。如果join()当前处于阻塞状态，那么当处

haokele 2020-05-31

第49天：Python 多线程之 threading 模块

在之前的文章中，我们已经介绍了 Python 通过 _thread 和 threading 模块提供了对多线程的支持，threading 模块兼具了 _thread 模块的现有功能，又扩展了一些新的功能，具有十分丰富的线程操作功能，本节我们就来详细学习一下

maimang00 2020-05-30

python的线程

python的线程和java的线程是有差别的，在一些等待的任务上有优势，如用户输入、文件读写、网络收发数据等。在这些情况下可以释放珍贵的内存cpu资源。musics = [‘音乐1‘, ‘音乐2‘, ‘音乐3‘, ‘音乐4‘, ‘音乐5‘, ‘音乐6‘,

yawei 2020-05-30
jiangbo0

jiangbo0

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号