客户端容器｜ 青训营笔记

1. 浏览器架构

1.1 浏览器架构演进

0. 单进程架构：所有模块运行在同一个进程中，包含网络、插件、JavaScript 运行环境等
1. 多进程架构：主进程、网络进程、渲染进程、GPU 进程、插件进程
2. 面向服务架构：将原来的 UI、数据库、文件、设备、网络等作为一个独立的基础服务

1.2 浏览器架构对比

架构类型	扩展性	安全性	稳定性	流畅性
单进程架构	低，所有模块运行在同一个进程中，访问同一块内存区域，数据没有隔离，新增模块可能会影响原有功能	低，第三方插件可直接访问操作系统里的任意资源	低，第三方插件漏洞或者某个 tab 页面 JavaScript 脚本问题可能导致浏览器崩溃	卡顿，所有页面运行在同一个进程中，开启多个页面时明显卡顿
多进程架构	中，各进程分配独立的内存区域，有些进程功能较大，耦合度高	高，运行在独立沙箱中，不能访问系统敏感资源	高，进程相互隔离，当一个页面或者插件崩溃时，不会影响其他进程	流畅，每个页面运行在独立的渲染进程中，充分利用系统资源
面向服务架构	高，服务模块划分更细，更频繁、耦合度低，易于扩展	高，运行在独立沙箱中，不能访问系统敏感资源	高，进程相互隔离，当一个页面或者插件崩溃时，不会影响其他进程	流畅，每个页面运行在独立的渲染进程中，充分利用系统资源

1.3 多进程分工

进程名称	进程描述
浏览器（主进程）	主要负责页面展示逻辑，用户交互，子进程管理：包括地址栏、书签、前进、后退、收藏夹等
GPU 进程	负责 UI 绘制，包含整个浏览器全部 UI
网络进程	网络服务进程，负责网络资源加载
标签页（渲染进程）	控制 tab 内的所有内容，将 HTML、CSS 和 JavaScript 转化为用户可交互的网页
插件进程	控制网站运行的插件，比如 flash、ModHeaders 等
其他进程	适用程序 Storage/Network/Audio Service 等

2. 渲染进程

2.1 常见浏览器内核

内核	浏览器	JS 引擎	补充说明
Trident	IE 4-11	JScript，Chakra	于1994年发布，IE 8 以前使用 JScript 引擎，IE 9 开始用 Chakra 引擎
Gecko	Firefox	SpiderMonkey	Gecko 内核主要用在 Firefox 浏览器上，同时是一个跨平台的内核，支持在 Windows、BSD、Linux、Max OS X 中使用
Webkit	Safari、Chrome、Android 浏览器	JavaScriptCore	由 Apple 公司技术团队开发，并在2005年开源
Blink	Chrome，Opera	V8	Google 基于 Webkit 开发的内核，在 Webkit 的基础上加入多进程、沙箱等技术，于2013年开源
Edge	Edge	Chakra	2015年由微软发布，用于 Edge 浏览器上，由于性能较差，运行不稳定等原因，2018年微软将 Edge 浏览器内核迁移到 Chromium
Trident + Webkit(Blink)	国产浏览器QQ、360、搜狗、UC 等	都有	在早期银行系统都是在 IE 上进行开发，想要支持银行系统就切换到 Trident 内核，想要体验就切换到 Webkit 内核

2.2 多线程架构

内部是多线程实现，主要负责页面渲染，脚本执行，事件处理，网络请求等。

线程	功能
JS 引擎	负责解析 js 脚本，运行 js 程序，每个渲染进程下面只会有一个 js 引擎线程。与 GUI 渲染线程互斥，如果 js 任务执行事件过长，会导致页面卡顿
GUI 渲染	负责渲染浏览器界面，解析 HTML、CSS，构建 dom 树和render 树、布局、绘制，和js 引擎线程互斥，GUI 更新会在 js 引擎空闲时立即执行
定时器触发	定时器所在线程，setTimeout、setInterval 计时完毕后，将回调添加到事件队列，等待 js 引擎执行
网络线程	在 XHR、Fetch 等发起请求后新开一个网络线程请求，如果设置了回调函数，在状态变更时，将回调放入事件队列，等待 js 引擎执行
事件触发	由宿主环境提供，用于控制事件循环，不断地从事件队列中取出任务执行

JS 引擎 VS 渲染引擎

0. 解析执行 JS
1. XML 解析生成渲染树，显示在屏幕
2. 桥接方式通信

2.3 多线程工作流程

0. 网络线程负责加载网页资源
1. JS 引擎解析 JS 脚本并且执行
2. JS 解析引擎空闲时，渲染引擎立即工作
3. 用户交互、定时器操作等产生回调函数放入任务队列中
4. 事件线程进行事件循环，将队列中的任务取出交给 JS 引擎执行

3. Chrome 运行原理

3.1 浏览器地址输入 URL 背后发生了什么

3.1.1 输入处理

0. 用户 URL 狂输入内容之后，UI 线程会判断输入的是一个 URL 还是 query 查询条件
1. 如果是 URL，直接请求站点资源
2. 如果是 query，将输入发生给搜索引擎

3.1.2 开始导航

0. 当用户按下回车，UI 线程通知网络线程发起一个网络请求，来获取站点内容
1. 请求过程中，tab 处于 loading 状态

3.1.3 读取响应

0. 网络线程接收到 HTTP 响应后，先检查响应头的媒体类型（MIME Type）
1. 如果响应主体是一个 HTML 文件，浏览器将内容交给渲染进程处理
2. 如果拿到的是其他类型文件，比如 zip、exe 等，则交给下载管理器处理

3.1.4 寻找渲染进程

0. 网络线程做完所有检查后，会告知主进程数据已准备完毕，主进程确认后为这个站点寻找一个渲染进程
1. 主进程通过 IPC 消息告知渲染引擎去处理本次导航
2. 渲染引擎开始接收数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段

3.2 渲染进程

3.2.1 资源加载

0. 收到主进程的消息后，开始加载 HTML 文档
1. 除此之外，还需要加载子资源，比如一些图片，CSS 样式文件以及 JavaScript 脚本

3.2.2 构建渲染树

0. 构建 DOM 树，将 HTML 文本转换成浏览器能够理解的结构
1. 构建 CSSOM 树，将 CSS 文本转换成浏览器能够理解的结构
2. 构建渲染树，渲染树是 DOM 树和 CSSOM 树的结合

3.2.3 页面布局

0. 根据渲染树计算每个节点的位置和大小
1. 在浏览器页面区域绘制元素边框
2. 遍历渲染树，将元素以盒模型的形式写入文档流

3.2.4 页面绘制

0. 构建图层：为特定的节点生成专用图层
1. 绘制图层：一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程
2. 合成线程接收指令生成图块
3. 栅格线程将图块进行栅格化
4. 展示在屏幕上

3.3 前端性能 performance

3.3.1 首屏优化

0. 压缩、分包、删除无用代码
1. 静态资源分离
2. JS 脚本非阻塞加载
3. 缓存策略
4. SSR
5. 预置 loading、骨架屏

3.3.2 渲染优化

0. GPU 加速
1. 减少回流、重绘
2. 离屏渲染
3. 懒加载

3.3.3 JS 优化

0. 防止内存泄漏
1. 循环尽早 break
2. 合理使用闭包
3. 减少 DOM 访问
4. 防抖、节流
5. Web Workers

4. 跨端容器

为什么需要跨端

0. 开发成本、效率
1. 一致性体验
2. 前端开发生态

有哪些跨端方案

• webview
• 小程序
• RN/Weex
• Lynx
• Flutter

4.1 WebView

0. WebView，即网页视图，用于加载网页 URL，并展示其内容的控件
1. 可以内嵌在移动端 APP 内，实现前端混合开发，大多数混合框架都是基于 WebView 的二次开发，比如 Ionic、Cordova

4.1.1 常用 WebView 分类

platform	webview	内核
Android4.4	webview	Webkit
Android4.4 以上	webview	chromiun
Android 国内部分	x5 webview	chromiun 改造版
IOS	UIwebview	Webkit
IOS8 以上	WKwebview	Webkit

4.1.2 使用 WebView 优势

0. 一次开发，处处使用，学习成本低
1. 随时发布，及时更新，不用下载安装包
2. 移动设备性能不断提升，性能有保障
3. 通过 JSBridge 和原生系统交互，实现复杂功能

4.1.3 WebView 使用原生能力

JavaScript 调用 Native

• API 注入：Native 获取 JavaScript 环境上下文，对其挂载的对象或者方法进行拦截
• 使用 WebView URL Scheme 跳转拦截
• IOS 上 window.webkit.messageHandler 直接通信

Native 调用 JavaScript

• 直接通过 webview 暴露的 API 执行 JS 代码
• IOS webview.stringByEvaluatingJavaScriptFromString
• Android webview.evaluateJavascript

4.1.4 WebView <-> Native 通信

0. JS 环境中提供通信的 JSBridge
1. Native 端提供 SDK 响应 JSBridge 发出的调用
2. 前端和客户端分别实现对应功能模块

4.2 小程序

0. 微信、支付宝、百度小程序、小米直达号
1. 渲染层 - webview
2. 双线程，多 webview 架构
3. 数据通信，Native 转发

4.3 React Native / Weex

0. 原生组件渲染
1. React / Vue 框架
2. virtual dom
3. JSBridge

4.4 Lynx

0. Vue
1. JS Core / V8
2. JSBinding
3. Native UI / Skia

4.5 Flutter

0. wideget
1. dart vm
2. skia 图形库

4.6 通用原理

0. UI 组件
1. 渲染引擎
2. 逻辑控制引擎
3. 通信桥梁
4. 底层 API 抹平表现差异

4.7 跨端方案对比

序号	学习成本	开发体验	兼容平台	生态活跃度	补充说明
webview	2	4	Android、IOS、HTML5	5	生态繁荣，标准统一，多端兼容，开发成本低，Ionic，uni-app 等开发框架，Native 插件丰富
小程序	2	3	Android、IOS	3	uni-app、wepy 等开发框架，强依赖平台能力，适合小型应用，小游戏
RN	3	3	Android、IOS	3	原生 UI 组件，React 到 RN 无缝切换，适合 React 开发者
WeeX	3	3	Android、IOS、HTML5	2	原生 UI 组件，主要淘系 APP 使用
Lynx	3	2	Android、IOS	2	原生 UI 组件，正考虑 skia 渲染，字节旗下 APp 内应用较多
Flutter	4	2	Android、IOS、HTML5	4	dart 开发，学习成本最高