web浏览器以及跨端方案
浏览器架构
浏览器架构变迁
1.单进程架构：所有模块运行在同一个进程里，包括网络、插件、JavaScript运行环境等 2.多进程架构：主进程、网络进程、渲染进程、渲染进程、GPU进程、插件进程等 3.面向服务架构：将原来的UI、数据库、文件、设备、网络等，作为一个单独的基础服务（也是多进程架构）
浏览器各架构对比
多进程架构介绍
多进程分工
- 浏览器（主进程）：主要负责页面展示逻辑，用户交互，子进程管理；包括地址栏、书签、前进、后退、收藏夹等
- GPU进程：负责UI绘制，包含整个浏览器全部UI
- 网络进程：网络服务进程，负责网络资源加载
- 标签页（渲染进程）：控制tab内的所有内容，将html、css和JavaScript转换为用户可交互的页面
- 插件进程：控制网站运行的插件，比如flash、ModHeader等
- 其他进程:适用程序 Storage/Network/Audio Service等（基础服务）
为什么会有单进程架构？
受硬件限制，早期内存昂贵，节约资源
面向服务架构是否会替代多进程架构？
会，优势：性能比较好的设备上，会做成面向服务架构，在性能比较差的设备上，会转化成多进程架构
渲染进程
常见浏览器内核
渲染进程多线程架构
内部是多线程实现，主要负责页面渲染，脚本执行，事件处理，网络请求等
| 线程 | 功能 |
|---|---|
| JS引擎 | 负责解析js脚本，运行js程序，每个渲染进程下只有一个js引擎线程，与GUI渲染线程互斥，如果js任务执行事件过长，会导致页面卡顿 |
| GUI渲染 | 负责渲染浏览器界面，解析html、css，构建dom树和render树、布局、绘制，和js引擎线程互斥，GUI更新会在js引擎空闲时立即执行 |
| 定时器触发 | 定时器所在线程，setTimeout、setInterval计时完毕后，将回调添加到事件队列，等待js引擎执行 |
| 网络线程 | 在XHR、Fetch等发起请求后新开一个网络线程请求，如果设置了回调函数，在状态变更时，将回调放入事件队列，等待js引擎执行 |
| 事件触发 | 由宿主环境提供，用于控制事件循环，不断地从事件队列里取出任务执行 |
JS引擎VS渲染引擎
1.解析执行JS 2.XML解析生成渲染树，显示在屏幕 3.桥接方式通信
它俩相互独立，通过bridge时会处理dom，会有延迟
多线程工作流程
1.网络线程负责加载网页资源 2.js引擎解析js脚本并且执行 3.js解析引擎空闲时，渲染线程立即工作 4.用户交互、定时器操作等产生回调函数放入任务队列中 5.事件线程进行事件循环，将队列里的任务取出交给js引擎执行
一道笔试题
以下代码在浏览器环境下输出顺序、内容
const now = Date.now()
setTImeout(()=>{
console.log('time10',Date.now()-now)//输出？
},10)
setTImeout(()=>{
console.log('time30',Date.now()-now)//输出？
},30)
while(true){
if(Date.now()-now>=20){
break}
}
console.log(Date.now()-now)//输出？
Chrome运行原理
如何展示网页
浏览器地址输入URL后发生了什么
主进程工作流程
- 输入处理
1.用户url框输入内容后，ui线程会判断输入的是一个url地址还是一个query查询条件
2.如果是url，直接请求站点资源
3.如果是query，将输入发送给搜索引擎
- 开始导航
1.当用户按下回车，ui线程通知网络线程发起一个网络请求，来获取站点内容
2.请求过程中，tab处于loading状态
- 读取响应
1.网络线程接收到HTTP响应后，先检查响应头的媒体类型（MIME Type）
2.如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理
3.如果拿到的是其他类型文件，比如Zip、exe等，则交给下载管理器处理
- 寻找渲染进程
1.网络线程做完所有检查后，会告知主进程数据已准备完毕，主进程确认后为这个站点寻找一个渲染进程
2.主进程通过IPC消息告知渲染进程去处理本次导航
3.渲染进程开始接收数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段
渲染进程工作流程
- 资源加载
1.收到主进程的消息后，开始加载HTML文档
2.除此之外，还需要加载子资源，比如一些图片，css样式文件以及JavaScript脚本
- 构建渲染树
1.构建DOM树，将HTML文本转化成浏览器能够理解的结构
2.构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解的CSSOM
3.构建渲染树，渲染树是DOM树和CSSOM树的结合
- 页面布局
1.根据渲染树计算每个节点的位置和大小
2.在浏览器页面区域绘制元素边框
3.遍历渲染树，将元素以盒模型的形式写入文档流
- 页面绘制
1.构建图层：为特定的节点生成专用图层
2.绘制图层：一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程
3.合成线程接收指令生成图块
4.栅格线程将图块进行栅格化
5.展示在屏幕上
（我们看到的是一层一层的！合成是为了减少绘制次数，（一次多画几笔）一般GPU会加速栅格化过程，再调用显卡呈现）
浏览器性能优化
- 前端性能
- 时间都花在哪
- 什么情况下卡顿
主要时间花在scripting和idle捏
黄色部分是卡顿 来不及刷新
- 首屏优化
- 压缩、分包、删除无用代码（减少体积，将js分包，可以运用浏览器运行能力）
- 静态资源分离（不要和服务放在一起）
- js脚本非阻塞加载（放包or底部）
- 缓存策略
- ssr
- 预置loading、骨架屏
- 渲染优化
- GPU加速
- 减少回流，重绘（left和top会影响布局，会回流，建议使用transform代替；比如display：none会影响结构，也可以用transform代替；比如table用div）
- 离屏渲染（开个内存，把要的东西先渲染好再加载过去，比如canvas，会减少掉帧，更流畅）
- 懒加载（提前加载到本地，滚动什么的时候直接从缓存取）
- js优化
- 防止内存泄漏（使用全局变量时；dom时，使用内存很大，要及时清除，还有定时器啥的（写点自动清除的））
- 循环尽早跳出（break,return）
- 合理使用闭包（减少元素创建）
- 减少DOM访问（写style时css类替代等）
- 防抖、节流
- Web Workers（比如用在一些音频处理上）
跨端容器
跨端的由来
为什么需要跨端
（优点）
1.开发成本、效率
2.一致性体验
3.前端开发生态
跨端容器（WebView）
1.WebView即网络视图，用于加载网页url，并展示其内容的控件
2.可以内嵌在移动端App内，实现前端混合开发，大多数混合框架都是基于WebView的二次开发，比如lonic，Cordova
常用WebView分类
WebView优势
1.一次开发，处处使用，学习成本低
2.随时发布，及时更新，不用下载安装包
3.移动设备性能不断提升，性能有保障
4.通过JSBridge和原生系统交互，实现复杂功能
WebView使用原生能力
-
JavaScript调用Native
- API注入：native获取JavaScript环境上下文，对其挂载的对象或者方法进行拦截
- 使用webview url scheme跳转拦截
- ios上window.webkit.messageHandler直接通信
-
Native调用JavaScript
- 直接通过webview暴露的API执行js代码
- IOS webview.stringByEvaluatingJavaScriptFromString
- Android webview.evaluateJavascript
WebView<=>Native通信
1.js环境中提供通信的jsbridge
2.native端提供sdk响应jsbridge发出的调用
3.前端和客户端分别实现对应功能模块
小程序
React Native/WeeX
1.原生组件渲染
2.React/Vue框架
3.virtual dom
4.JSBridge
Lynx
1.Vue
2.JS Core/V8
3.JSBinding
4.Native UI/Skia
Flutter
1.wideget
2.dart vm
3.ska图形库
常见的跨端方案
思考？
1.同样是基于webview渲染，为什么小程序体验比webview流畅
因为小程序把危险的webview操作ban了
2.未来的跨端方案会是什么
回归webview，虽然性能体验不是最好的，但是一定是最广的
