一、浏览器架构
演进
- 单进程架构：所有模块运行在同一进程，包括网络、插件、JS运行环境等
- 多进程架构：主进程、网络进程、渲染进程、GPU进程、插件进程
- 面向服务架构：将原来的UI、数据库、文件、设备、网络等作为一个独立的基础服务
对比
多进程分工
问题
- 为什么会有单进程架构？ ——早期受硬件限制，内存昂贵，单进程架构可以节约资源
- 面向服务架构是否会替代多进程架构？ ——长期来看可能会，面向服务架构基于多进程架构演进，在性能好的设备上效果更好
二、渲染进程
常见浏览器内核
- 一些国产浏览器的极速模式为Webkit内核
多线程架构
内核是多线程实现，主要负责页面渲染、脚本执行、事件处理、网络请求等
| 渲染进程 | 功能 |
|---|---|
| js引擎线程 | 解析js脚本，运行js程序，每个渲染进程下只有一个js引擎线程，与GUI渲染线程互斥，js任务执行事件过长会导致页面卡顿 |
| GUI渲染线程 | 渲染浏览器界面，解析html、css，构建dom树和render树、布局、绘制，与js引擎线程互斥，GUI更新在js引擎空闲时立即执行 |
| 定时器线程 | 定时器所在线程，setTimeout、setInterval计时完毕后将回调添加到事件队列，等待js引擎执行 |
| 网络线程 | 在XHR、Fetch等发起请求后新开一个网络线程请求，如果设置了回调函数，在状态变更时，将回调放入事件队列，等待$引擎执行 |
| 事件线程 | 由宿主环境提供，用于控制事件循环，不断地从事件队列里取出任务执行 |
js引擎线程 and GUI渲染线程
- 解析执行js
- XML解析生成渲染树，显示在屏幕上
- 桥接方式通信
多线程工作流程
- 网络线程 加载网页资源
- js引擎 解析js脚本并执行
- js解析引擎 空闲时，渲染线程 工作
- 用户交互、定时器操作等产生回调函数放入任务队列中
- 事件进程 进行事件循环，将队列里的任务取出交给 js引擎 执行
三、Chrome运行原理
网页展示
地址栏输入URL后
输入处理
- 地址栏输入内容后，UI进程 判断输入的是 URL地址 or query查询条件
- URL -> 请求站点资源
- query -> 输入发送给搜索引擎
开始导航
- 按下回车，UI线程 通知 网络线程 发起一个网络请求，获取站点内容
- 请求过程中，tab处于loading状态
读取响应
- 网络线程 接收到 HTTP响应 后，检查响应头的媒体类型（MINE Type）
- 如果 响应主体 是一个 HTML文件 ，浏览器 将内容交给 渲染进程 处理
- 如果拿到其他类型文件，如zip、exe等，则交给 下载管理器 处理
寻找渲染进程
- 网络线程 做完所有检查后，告知 主进程 数据准备完毕，主进程 确认后为这个站点寻找一个 渲染进程
- 主进程 通过 IPC 告知 渲染进程 处理本次导航
- 渲染进程 接收数据并告知 主进程 已开始处理，导航结束，进入文档加载阶段
渲染进程 - 资源加载
- 收到 主进程 消息后，开始加载 HTML文档
- 加载 子资源，如图片、CSS样式文件、js脚本
渲染进程 - 构建渲染树
- 构建DOM树，将 HTML文本 转化为 浏览器 可理解的结构
- 构建CSDOM树，将 CSS代码 转化为 浏览器 可理解的 CSDOM
- 构建渲染树（DOM树和CSDOM树的结合）
渲染进程 - 页面布局
- 根据 渲染树 计算每个节点的位置和大小
- 在 浏览器 页面区域绘制元素边框
- 遍历 渲染树，将元素以盒模型的形式写入文档流
渲染进程 - 页面绘制
- 构建图层：为特定节点生成专用图层
- 绘制图层：一个图层分成多个绘制指令，按顺序组成一个绘制列表，交给 合成线程
- 合成线程 接收指令，生成 图块
- 栅格线程 将 图块 进行 栅格化（通常使用GPU加速）
- 在屏幕上展示
前端性能performance
首屏优化
- 压缩、分包、删除无用代码
- 静态资源分离
- JS脚本非阻塞加载
- 缓存策略
- SSR
- 预置loading、骨架屏
渲染优化
- GPU加速（透明度、transform）
- 减少回流、重绘
- 离屏渲染
- 懒加载（资源提前加载到本地）
JS优化
- 防止内存泄漏
- 循环尽早break
- 合理使用闭包
- 减少DOM访问（变量缓存）
- 防抖、节流
- Web Workers
四、跨端容器
为什么跨端
- 开发成本、效率
- 一致性体验
- 前端开发生态
跨端方案
- webview
- 小程序
- React Native / WeeX
- Lynx
- Flutter
WebView
- 即网页视图，用于加载网页URL，展示其内容的组件
- 可以内嵌在移动端APP内，实现前端混合开发，大多数混合框架基于 WebView 二次开发，如 lonic、Cordova
常见 WebView 分类
| platform | webview | 内核 |
|---|---|---|
| Android4.4 | webview | Webkit |
| Android4.4 以上 | webview | chromium |
| Android 国内部分 | X5 webview | chromium改造版 |
| IOS | Ulwebview | Webkit |
| IOS8 以上 | WKwebview | Webkit |
WebView 优势
- 一次开发，处处使用，学习成本低
- 随时发布，即时更新，免下载安装包
- 移动设备性能不断提升，性能有保障
- 通过 JSBridge 和原生系统交互，实现复杂功能
WebView 使用原生能力
JS 调用 Native
- API注入：Native?获取JS环境上下文，对其挂载的对象或者方法进行拦截
- 使用 Webview URL Scheme 跳转拦截
- IOS：window.webkit.messageHandler 直接通信
Native调用Javascript
- 直接通过 webview 暴露的API执行JS代码
- IOS：webview.stringByEvaluatingJavaScriptFromString
- Android：webview.evaluateJavascript
WebView <-> Native 通信
- JS环境中提供通信的 JSBridge
- Native 端提供 SDK 响应 JSBridge 发出的调用
- 前端和客户端分别实现对应功能模块
小程序
- 微信、支付宝、百度小程序、小米直达号
- 渲染层 - webview
- 双线程，多 webview 架构
- 数据通信，Native 转发
React Native / WeeX
- 原生组件渲染
- React / Vue 框架
- virtual dom（JS对象）
- JSBridge（业务方 和 Native 通信）
- 在 Android 和 IOS 中的渲染效果不同
Lynx
- Vue（框架）
- JS Core / V8（引擎）
- JSBinding（高效的 JSBridge）
- Native Ul / Skia
Flutter
- wideget（UI组件）
- dart vm
- skia 图形库
通用原理
- UI组件（View、Text）
- 渲染引擎（webview、Native、自研引擎）
- 逻辑控制引擎（JS引擎、dart vm）
- 通信Bridge
- 底层API抹平表现差异
跨端方案对比
| 方案 | 学习成本 | 开发者体验 | 兼容平台 | 生态活跃度 | 备注 |
|---|---|---|---|---|---|
| webview | ⭐︎⭐︎ | ⭐︎⭐︎⭐︎⭐︎ | Android、IOS、H5 | ⭐︎⭐︎⭐︎⭐︎⭐︎ | 生态繁荣，标准统一，多端兼容，开发成本低，lonic、uni-app等开发框架，Native插件丰富 |
| 小程序 | ⭐︎⭐︎ | ⭐︎⭐︎⭐︎ | Android、IOS | ⭐︎⭐︎⭐︎ | uni-app、wepy等开发框架，强依赖平台能力，适合小型应用、小游戏 |
| RN | ⭐︎⭐︎⭐︎ | ⭐︎⭐︎⭐︎ | Android、IOS | ⭐︎⭐︎⭐︎ | 原生UI组件，React到RN无缝切换，适合React开发者 |
| WeeX | ⭐︎⭐︎⭐︎ | ⭐︎⭐︎⭐︎ | Android、IOS、H5 | ⭐︎⭐︎ | 原生UI组件，主要淘系APP应用 |
| Lynx | ⭐︎⭐︎⭐︎ | ⭐︎⭐︎ | Android、IOS | ⭐︎⭐︎ | 原生UI组件，正在考虑skia渲染，字节APP应用较多 |
| Flutter | ⭐︎⭐︎⭐︎⭐︎ | ⭐︎⭐︎ | Android、IOS、H5 | ⭐︎⭐︎⭐︎⭐︎ | dart开发，学习成本最高 |
- webview 和 小程序：学习成本低，不涉及原生和客户端概念
- Flitter：学习成本高，需要学习新语言
问题
- 同样基于 webview 渲染，为什么小程序体验比 webview 流畅？ ——小程序使用离线缓存，基于 webview 优化
- 未来可能的跨端方案？ ——webview，应用最广
