Ecool

state 基本定义 state是组件内部的状态（数据），不能够直接修改，必须要通过setState来改变值的状态，从而达到更新组件内部数据的作用。 props 基本定义 props是指组件间传递的一种方式，props自然也可以传递state。由于React的数据流是自上而下的，所以是从父组件向子组件进行传递；另外组件内部的this.props属性是只读的不可修改。 代码示例 // 父组件 import stateJj from './stateJj.js'; // 引入子组件 class stateJjFather extends React.Component { constructor(props) { super(props); // 设置state的默认值 且只能在constructor中设置 this.state = { mes: '给子组件的信息', obj： { }, arr: [] } } fun(e) { } render() { const {mes, obj, arr} = this.state; return ( <div> // 不写箭头函数 this指向会发生错误 也可以使用bind的方式绑定this <stateJj name={'给子组件的信息'} name1={mes} fun={(e) => this.fun(e)} obj={obj} arr={arr} /> </div> ); } } // 子组件 class stateJj extends React.Component { constructor(props) { super(props); this.props; // 这里面就有父组件传的值 // 设置 默认state this.state = { text: props.initialValue || 'placeholder' }; // ES6 类中函数必须手动绑定 this.handleChange = this.handleChange.bind(this); } handleChange(event) { this.setState({ text: event.target.value }); } render() { return ( <div> {mes} </div> ); } } // 设置props值的类型 stateJj.propTypes = { optionalArray: PropTypes.array, optionalBool: PropTypes.bool, optionalFunc: PropTypes.func, optionalNumber: PropTypes.number, optionalObject: PropTypes.object, optionalString: PropTypes.string, optionalSymbol: PropTypes.symbol, // 目前可以声明的所有变量类型 }; // 设置默认的props值 stateJj.defaultProps = { }; props的特性 只读性 props经常被用作渲染组件和初始化状态，当一个组件被实例化之后，它的props是只读的，不可改变的。如果props在渲染过程中可以被改变，会导致这个组件显示的形态变得不可预测。只有通过父组件重新渲染的方式才可以把新的props传入组件中。 ...

一、前言 缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。 对于一个数据请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。 接下来的内容中我们将通过缓存位置、缓存策略以及实际场景应用缓存策略来探讨浏览器缓存机制。 如需获取思维导图或想阅读更多优质文章请猛戳GitHub博客 二、缓存位置 从缓存位置上来说分为四种，并且各自有优先级，当依次查找缓存且都没有命中的时候，才会去请求网络。 Service Worker Memory Cache Disk Cache Push Cache 1.Service Worker Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。 Service Worker 实现缓存功能一般分为三个步骤：首先需要先注册 Service Worker，然后监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。 当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。 2.Memory Cache Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。 那么既然内存缓存这么高效，我们是不是能让数据都存放在内存中呢？ 这是不可能的。计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。 当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存 内存缓存中有一块重要的缓存资源是preloader相关指令（例如<link rel="prefetch">）下载的资源。总所周知preloader的相关指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络请求下一个资源。 需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。 3.Disk Cache Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。 ...

React 中的元素、组件、实例和节点，是React中关系密切的4个概念，也是很容易让React 初学者迷惑的4个概念。现在，老干部就来详细地介绍这4个概念，以及它们之间的联系和区别，满足喜欢咬文嚼字、刨根问底的同学（老干部就是其中一员）的好奇心。 元素 (Element) React 元素其实就是一个简单JavaScript对象，一个React 元素和界面上的一部分DOM对应，描述了这部分DOM的结构及渲染效果。一般我们通过JSX语法创建React 元素，例如： const element = <h1 className='greeting'>Hello, world</h1>; element是一个React 元素。在编译环节，JSX 语法会被编译成对React.createElement()的调用，从这个函数名上也可以看出，JSX语法返回的是一个React 元素。上面的例子编译后的结果为： const element = React.createElement( 'h1', {className: 'greeting'}, 'Hello, world!' ); 最终，element的值是类似下面的一个简单JavaScript对象： const element = { type: 'h1', props: { className: 'greeting', children: 'Hello, world' } } React 元素可以分为两类：DOM类型的元素和组件类型的元素。DOM类型的元素使用像h1、div、p等DOM节点创建React 元素，前面的例子就是一个DOM类型的元素；组件类型的元素使用React 组件创建React 元素，例如： const buttonElement = <Button color='red'>OK</Button>; buttonElement就是一个组件类型的元素，它的值是： const buttonElement = { type: 'Button', props: { color: 'red', children: 'OK' } } 对于DOM类型的元素，因为和页面的DOM节点直接对应，所以React知道如何进行渲染。但是对于组件类型的元素，如buttonElement，React是无法直接知道应该把buttonElement渲染成哪种结构的页面DOM，这时就需要组件自身提供React能够识别的DOM节点信息，具体实现方式在介绍组件时会详细介绍。 有了React 元素，我们应该如何使用它呢？其实，绝大多数情况下，我们都不会直接使用React 元素，React 内部会自动根据React 元素，渲染出最终的页面DOM。更确切地说，React元素描述的是React虚拟DOM的结构，React会根据虚拟DOM渲染出页面的真实DOM。 组件 (Component) React 组件，应该是大家最熟悉的React中的概念。React通过组件的思想，将界面拆分成一个个可以复用的模块，每一个模块就是一个React 组件。一个React 应用由若干组件组合而成，一个复杂组件也可以由若干简单组件组合而成。 React组件和React元素关系密切，React组件最核心的作用是返回React元素。这里你也许会有疑问：React元素不应该是由React.createElement() 返回的吗？但React.createElement()的调用本身也是需要有“人”负责的，React组件正是这个“责任人”。React组件负责调用React.createElement()，返回React元素，供React内部将其渲染成最终的页面DOM。 既然组件的核心作用是返回React元素，那么最简单的组件就是一个返回React元素的函数： function Welcome(props) { return <h1>Hello, {props.name}</h1>; } Welcome是一个用函数定义的组件。如果使用类（class）定义组件，返回React元素的工作具体就由组件的render方法承担，例如： ...

V8 是 Google 开发的 JavaScript 引擎（用于 Chrome、Node.js 等），它的核心优化机制可以总结为：即时编译（JIT） + 隐式类型优化 + 内联缓存 + 垃圾回收机制，通过这些方式来大幅提升 JS 的执行性能。 一、V8 的执行流程 V8 不直接解释执行 JavaScript，而是： 解析（Parser）：将 JS 源码解析为 AST（抽象语法树） 生成字节码（Bytecode）：由 Ignition 引擎生成并执行初始字节码 收集类型信息（Profiler）：运行时收集变量类型、函数调用等信息 优化编译（JIT）：将热点代码交给 TurboFan 引擎编译为高效的机器码 二、核心优化机制 1. 隐藏类（Hidden Class）与内联缓存（Inline Cache） 为了优化对象属性访问，V8 引入了隐藏类机制，类似 C++ 中的类结构： 初次创建对象时，生成一个隐藏类（HiddenClass） 添加属性时会生成新的隐藏类链表结构 相同结构的对象共享隐藏类，从而使访问更快 不要动态给对象添加属性，尽量保持对象结构稳定。 内联缓存：缓存某个属性的访问位置，使得后续同样结构的对象访问不必重新查找。 function Person(name) { this.name = name; } const p1 = new Person("Tom"); const p2 = new Person("Jerry"); // 内联缓存会优化 this.name 的访问路径 2. 类型反馈与优化编译（Type Feedback + JIT） V8 在执行字节码时会收集类型信息（比如函数参数、返回值的类型），并标记频繁调用的代码为“热点代码”： 热点代码会被交给 TurboFan 做优化编译 编译时使用收集到的类型信息来生成专用的机器码（类型特化） 例如： function add(a, b) { return a + b; } add(1, 2); // 优化为整数加法 add("a", "b"); // 类型变化 -> 去优化 不要在同一个函数中混用不同类型，可能导致优化失败或退化。 ...

区分进程和线程 线程和进程区分不清，是很多新手都会犯的错误，没有关系。这很正常。先看看下面这个形象的比喻： - 进程是一个工厂，工厂有它的独立资源 - 工厂之间相互独立 - 线程是工厂中的工人，多个工人协作完成任务 - 工厂内有一个或多个工人 - 工人之间共享空间 再完善完善概念： - 工厂的资源 -> 系统分配的内存（独立的一块内存） - 工厂之间的相互独立 -> 进程之间相互独立 - 多个工人协作完成任务 -> 多个线程在进程中协作完成任务 - 工厂内有一个或多个工人 -> 一个进程由一个或多个线程组成 - 工人之间共享空间 -> 同一进程下的各个线程之间共享程序的内存空间（包括代码段、数据集、堆等） 然后再巩固下： 如果是windows电脑中，可以打开任务管理器，可以看到有一个后台进程列表。对，那里就是查看进程的地方，而且可以看到每个进程的内存资源信息以及cpu占有率。 所以，应该更容易理解了：进程是cpu资源分配的最小单位（系统会给它分配内存） 最后，再用较为官方的术语描述一遍： 进程是cpu资源分配的最小单位（是能拥有资源和独立运行的最小单位） 线程是cpu调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程） tips 不同进程之间也可以通信，不过代价较大 现在，一般通用的叫法：单线程与多线程，都是指在一个进程内的单和多。（所以核心还是得属于一个进程才行） 浏览器是多进程的 理解了进程与线程了区别后，接下来对浏览器进行一定程度上的认识：（先看下简化理解） 浏览器是多进程的 浏览器之所以能够运行，是因为系统给它的进程分配了资源（cpu、内存） 简单点理解，每打开一个Tab页，就相当于创建了一个独立的浏览器进程。 关于以上几点的验证，请再第一张图： 图中打开了Chrome浏览器的多个标签页，然后可以在Chrome的任务管理器中看到有多个进程（分别是每一个Tab页面有一个独立的进程，以及一个主进程）。 感兴趣的可以自行尝试下，如果再多打开一个Tab页，进程正常会+1以上 **注意：**在这里浏览器应该也有自己的优化机制，有时候打开多个tab页后，可以在Chrome任务管理器中看到，有些进程被合并了 （所以每一个Tab标签对应一个进程并不一定是绝对的） 浏览器都包含哪些进程？ 知道了浏览器是多进程后，再来看看它到底包含哪些进程：（为了简化理解，仅列举主要进程） Browser进程：浏览器的主进程（负责协调、主控），只有一个。作用有 负责浏览器界面显示，与用户交互。如前进，后退等 负责各个页面的管理，创建和销毁其他进程 将Renderer进程得到的内存中的Bitmap，绘制到用户界面上 网络资源的管理，下载等 第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建 GPU进程：最多一个，用于3D绘制等 浏览器渲染进程（浏览器内核）（Renderer进程，内部是多线程的）：默认每个Tab页面一个进程，互不影响。主要作用为 页面渲染，脚本执行，事件处理等 强化记忆：在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程） 当然，浏览器有时会将多个进程合并（譬如打开多个空白标签页后，会发现多个空白标签页被合并成了一个进程），如图 另外，可以通过Chrome的更多工具 -> 任务管理器自行验证 浏览器多进程的优势 相比于单进程浏览器，多进程有如下优点： 避免单个page crash影响整个浏览器 避免第三方插件crash影响整个浏览器 多进程充分利用多核优势 方便使用沙盒模型隔离插件等进程，提高浏览器稳定性 简单点理解：如果浏览器是单进程，那么某个Tab页崩溃了，就影响了整个浏览器，体验有多差；同理如果是单进程，插件崩溃了也会影响整个浏览器；而且多进程还有其它的诸多优势。。。 当然，内存等资源消耗也会更大，有点空间换时间的意思。 重点是浏览器内核（渲染进程） 重点来了，我们可以看到，上面提到了这么多的进程，那么，对于普通的前端操作来说，最终要的是什么呢？答案是渲染进程 ...

渲染流程 首先要了解的概念: 渲染引擎：它是浏览器最核心的部分是 “Rendering Engine”，不过我们一般习惯将之称为 “浏览器内核” 渲染引擎主要包括的线程： 各个线程主要职责： GUI渲染线程：GUI 渲染线程负责渲染浏览器界面，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等。当界面需要重绘（Repaint）或由于某种操作引发回流（Reflow）时，该线程就会执行。 JavaScript引擎线程: JavaScript 引擎线程主要负责解析 JavaScript 脚本并运行相关代码。 JavaScript 引擎在一个Tab页（Renderer 进程）中无论什么时候都只有一个 JavaScript 线程在运行 JavaScript 程序。需要提起一点就是，GUI线程与JavaScript引擎线程是互斥的，这也是就是为什么JavaScript操作时间过长，会造成页面渲染不连贯，导致页面出现阻塞的原理。 事件触发线程：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。 通常JavaScript引擎是单线程的，所以这些事件都会排队等待JS执行。 定时器触发器： 我们日常使用的setInterval 和 setTimeout 就在该线程中，原因可能就是：由于JS引擎是单线程的，如果处于阻塞线程状态就会影响记时的准确，所以需要通过单独的线程来记时并触发响应的事件这样子更为合理。 Http请求线程： 在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求，这个线程就Http请求线程，它 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。 有了上述的概念，对接下我们讲渲染流水线会有所帮助 简略版的渲染机制 很久之前就把浏览器工作原理读完了，看了很多博客，文章，当时简简单单的梳理一些内容,如下👇 简略版渲染机制一般分为以下几个步骤 处理 HTML 并构建 DOM 树。 处理 CSS 构建 CSSOM 树。 将 DOM 与 CSSOM 合并成一个渲染树。 根据渲染树来布局，计算每个节点的位置。 调用 GPU 绘制，合成图层，显示在屏幕上。 接下来大概就是这么说： 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。 ...

时下虽然接入 JSX 语法的框架越来越多，但与之缘分最深的毫无疑问仍然是 React。 2013 年，当 React 带着 JSX 横空出世时，社区曾对 JSX 有过不少的争议，但如今，越来越多的人面对 JSX 都要说上一句“真香”！我们就来一起认识下这个“真香”的 JSX，聊一聊“JSX 代码是如何‘摇身一变’成为 DOM 的”。 开始之前请先思考几个问题： JSX 的本质是什么，它和 JS 之间到底是什么关系？ 为什么要用 JSX？不用会有什么后果？ JSX 背后的功能模块是什么，这个功能模块都做了哪些事情？ 面对以上问题，如果无法形成清晰且系统的思路，那么很可能是把 JSX 想得过于简单了。大多数人只是简单地把它理解为模板语法的一种，但事实上，JSX 作为 React 框架的一大特色，它与 React 本身的运作机制之间存在着千丝万缕的联系，上述 3 个问题的答案，就恰恰隐藏在这层“联系”中。 JSX 的本质：JavaScript 的语法扩展 JSX 到底是什么?看看 React 官网给出的一段定义： JSX 是 JavaScript 的一种语法扩展，它和模板语言很接近，但是它充分具备 JavaScript 的能力。 “语法扩展”这一点在理解上几乎不会产生歧义，不过“它充分具备 JavaScript 的能力”这句，却总让人摸不着头脑，JSX 和 JS 怎么看也不像是“一路人”啊？这就引出了“JSX 语法是如何在 JavaScript 中生效的”这个问题。 JSX 语法是如何在 JavaScript 中生效的：认识 Babel Facebook 公司给 JSX 的定位是 JavaScript 的“扩展”，而非 JavaScript 的“某个版本”，这就直接决定了浏览器并不会像天然支持 JavaScript 一样地支持 JSX。那么，JSX 的语法是如何在 JavaScript 中生效的呢？React 官网其实早已给过我们线索： ...

一句话总结：中间人攻击的关键在于获取公钥。 一、我和小美传纸条 我和隔壁班的小美互相喜欢，经常互相传纸条。但我懒得动，一般让老王帮我顺路带过去，我信任老王，所以就是简单把纸对折一下就交给老王了。 二、带锁的盒子 有一天我发现，老王居然偷看我的纸条！ 我很生气，于是买了一个带锁的盒子，并配了两把钥匙🔑，我留一把，另一把让老王交给小美。我心想这下子老王没钥匙，看不了我们的纸条了。 三、一个需要两把钥匙的盒子 又过了几天，我发现老王还是会偷看，为什么呢？原来这老小子当初传递钥匙的时候，自己去复刻了一把！ 于是我又想了一个办法，换了一个更高级的盒子，这个盒子必须用一对钥匙才能使用，使用公钥上锁，必须使用私钥才能打开。我委托老王把我的公钥交给小美，把小美的公钥拿给我。 以后我们都用对方的公钥来进行加密，对方用自己的私钥就能解密。而且就算老王把公钥拿去复刻一把也没关系，没有私钥他就打不开箱子，完美！ 四、班主任 过了几天，我发现老王还是能偷看我们的纸条，为什么呢？？？？？？ 我想了好几天终于想明白了！原来老王当初传递钥匙的时候，他把我俩的公钥自己留下了，这老小子把自己的公钥给了我们俩。他现在有手里有四把钥匙，想看什么看什么！ 这次我们终于意识到问题的关键，不管什么方案，让老王传钥匙就得坏事！于是我和小美商量好，这次不通过老王，而是通过我的班主任传递公钥，终于可以愉快的聊天了！ 五、网络中的加密知识 对称加密 对称加密使用同一个密钥进行加密和解密。它的优点是速度快，它的问题是密钥传播过程中一旦泄露，就功亏一篑了。 非对称加密 非对称加密使用一对密钥：公钥和私钥。公钥用于加密，私钥用于解密。它的优点是密钥分发问题得到解决，公钥可以公开传播。缺点是速度较慢，通常用于加密小数据量或密钥交换。常见做法是通过非对称加密建立链接，交换对称加密密钥，然后使用对称加密的方式进行消息传递。 证书 数字证书是由认证机构（CA）签发的，包含公钥及其持有者身份信息的电子文档。它通过 CA 的数字签名验证其真实性，确保通信双方的身份和公钥的可信性。（证书就是上面例子中的班主任，是一个可信任的获取对方公钥的机构。） 六、中间人攻击 中间人攻击的关键在于攻击者成功获取并提供可信公钥，欺骗用户使其认为其公钥是合法服务器的公钥。这可以通过伪造证书或利用受损的 CA 来实现。（用上面例子来说，就是老王把自己的公钥伪装成小美的公钥给了我） 作为普通用户防御措施很简单，当访问一个网站时，如果浏览器弹出“证书不可信”告警的时候，不要点“我信任”。 常见考点 1. 中间人攻击的基本概念 问题： 什么是中间人攻击？请用通俗的语言解释。 中间人攻击有哪些典型的攻击方式？ 被动攻击（如窃听）。 主动攻击（如数据篡改）。 中间人攻击的危害有哪些？ 关键点： 中间人攻击是一种攻击者拦截并篡改通信内容的攻击。 危害包括：窃取敏感数据（如密码）、篡改通信内容、伪装身份等。 2. 中间人攻击的原理 问题： 中间人攻击是如何实现的？请简要描述其工作流程。 在 HTTP 中，为什么容易发生中间人攻击？ HTTPS 是否完全能防止中间人攻击？为什么？ DNS 劫持和 ARP 欺骗是如何帮助实现中间人攻击的？ 关键点： 工作流程： 攻击者充当通信双方之间的“中间人”。 拦截通信数据，可能进行监听或篡改。 常见技术： ARP 欺骗：伪装网关。 DNS 劫持：将域名解析到攻击者控制的服务器。 Wi-Fi 劫持：在公共网络中拦截通信数据。 3. 防御中间人攻击的技术措施 问题： HTTPS 如何防御中间人攻击？它的安全机制是什么？ 什么是证书信任链？如何防止伪造的证书？ 什么是 HSTS（HTTP Strict Transport Security）？它如何防御中间人攻击？ 什么是双向 SSL/TLS？它如何进一步提高安全性？ 如何防止公共 Wi-Fi 中的中间人攻击？ 关键点： ...

CSS 发展史 上图是20 世纪 90 年万维网刚出现时，由于当时并没有可以装饰网页的方法，原始的 Web 页面呈现的效果，随着 CSS（层叠样式表，Cascading Style Sheets）的诞生与发展，Web页面的样式有了翻天覆地的变化。 CSS的发布过程 CSS1.0 19912月W3C发布了第一个有关样式的标准CSS1.0。这个版本中，已经包含了的相关font的相关属性、颜色与背景的相关属性、文字的相关属性、box的相关属性等。 CSS2.0 1985年5月，CSS2.0正式推出。这个版本推荐的是内容和表现效果分离的方式，并开始使用样式表结构。 CSS2.1 2004年2月，CSS2.1正式推出。它在CSS2.0的基础上略微做了改动，删除了许多不被浏览器支持的属性 CSS3 从2011年开始CSS被分为多个模块单独升级。这些模块统称为CSS3 包含有： CSS 选择器level3 CSS 媒体查询level3 CSS color level3 CSS4 设计中 CSS 标准的制定大概有下面几个步骤 下面主要介绍的是与我们日常工作有关联的一些新特性，其中一些已经在主流浏览器中得到了支持，还有一些特性还在草案阶段，可能还会有一些变化。 CSS 伪类选择器 is()和where() 在编写css时，有时会需要使用很长的选择器列表来定位具有相同样式的子元素，比如对所有H元素下的span设置为block，之前会这么写: 这样写选择器看起来很长，可读性差。 此时，可以使用is()来提高易读性，同时避免使用长选择器 浏览器支持: :is() Chrome 88/ Firefox 78/ Edge 88 /Safari 14 :where() Chrome 88/ Firefox 78/ Edge 88 /Safari 14 注意： is()和where()在使用方法上和其他的伪类选择器一样，可以任意组合排列。 is()和where()的功能大体上是一样的，他们的差异性体现在选择器的权重上 where()选择器没有权重，也就是权重是0 is()选择器的权重由它的选择器列表中的最搞权重决定 规则示例: ...

导读 移动端适配，是我们在开发中经常会遇到的，这里面可能会遇到非常多的问题： 1px问题 UI图完美适配方案 iPhoneX适配方案 横屏适配 高清屏图片模糊问题 … 上面这些问题可能我们在开发中已经知道如何解决，但是问题产生的原理，以及解决方案的原理可能会模糊不清。在解决这些问题的过程中，我们往往会遇到非常多的概念：像素、分辨率、PPI、DPI、DP、DIP、DPR、视口等等，你真的能分清这些概念的意义吗？ 本文将从移动端适配的基础概念出发，探究移动端适配各种问题的解决方案和实现原理。 一、英寸 一般用英寸描述屏幕的物理大小，如电脑显示器的17、22，手机显示器的4.8、5.7等使用的单位都是英寸。 需要注意，上面的尺寸都是屏幕对角线的长度： 英寸(inch,缩写为in)在荷兰语中的本意是大拇指，一英寸就是指甲底部普通人拇指的宽度。 英寸和厘米的换算：1英寸 = 2.54 厘米 二、分辨率 2.1 像素 像素即一个小方块，它具有特定的位置和颜色。 图片、电子屏幕（手机、电脑）就是由无数个具有特定颜色和特定位置的小方块拼接而成。 像素可以作为图片或电子屏幕的最小组成单位。 下面我们使用sketch打开一张图片： 将这些图片放大即可看到这些像素点： 通常我们所说的分辨率有两种，屏幕分辨率和图像分辨率。 2.2 屏幕分辨率 屏幕分辨率指一个屏幕具体由多少个像素点组成。 下面是apple的官网上对手机分辨率的描述： iPhone XS Max 和 iPhone SE的分辨率分别为2688 x 1242和1136 x 640。这表示手机分别在垂直和水平上所具有的像素点数。 当然分辨率高不代表屏幕就清晰，屏幕的清晰程度还与尺寸有关。 2.3 图像分辨率 我们通常说的图片分辨率其实是指图片含有的像素数，比如一张图片的分辨率为800 x 400。这表示图片分别在垂直和水平上所具有的像素点数为800和400。 同一尺寸的图片，分辨率越高，图片越清晰。 2.4 PPI PPI(Pixel Per Inch)：每英寸包括的像素数。 PPI可以用于描述屏幕的清晰度以及一张图片的质量。 使用PPI描述图片时，PPI越高，图片质量越高，使用PPI描述屏幕时，PPI越高，屏幕越清晰。 在上面描述手机分辨率的图片中，我们可以看到：iPhone XS Max 和 iPhone SE的PPI分别为458和326，这足以证明前者的屏幕更清晰。 由于手机尺寸为手机对角线的长度，我们通常使用如下的方法计算PPI: iPhone 6的PPI为 ...