客户端容器
web浏览器以及跨端方案
01 浏览器架构
浏览器架构演进
1.单进程架构：所有模块在同一个进程里，包含网络、插件、javascript运行环境等
2.多进程架构：（进程间隔开，安全性高）主进程、网络进程、渲染进程、GPU进程、插件进程
3.面向服务架构：升级版多进程架构 基础服务等作为一个独立的基础服务
将原来的UI\数据库、文件、设备、网络等，作为一个独立的基础服务
设备间定义好ip接口，通过ip通信进行交互
浏览器架构对比
单进程： 扩展性低 安全性低（插件访问） 稳定性低（页面崩溃导致浏览器崩溃）
流畅度卡顿
多进程架构：扩展性中 安全性（插件隔离）稳定性高 流畅度高
面向服务架构：扩展性高 安全性高 稳定性高 流畅度流程
浏览器进程-任务管理器
浏览器（主进程）：大多数能看到的 前进后退 标签页 主要负责展示逻辑，用户交互，子进程管理
CPU进程：负责UI绘制，包含整个浏览器的全部UI
网络进程：网络服务进程，负责网络资源加载
标签页（渲染进程 之后着重讲） 控制tab内的所有内容，将Html,javascript转化为用户可以交互的网页
插件进程：控制网站运行的插件，比如flash,modheader等
其他进程：上图所示程序：stortage network audio service
为什么会会有单进程架构：早起硬件限制
面向服务架构（谷歌2016的演进 优势：在性能好的设备上会变成面向服务器架构 在差设备上会退化成多进程）是否会替代多进程架构：长期来看会替代
02渲染进程
常见浏览器内核：
渲染进程-多线程架构
内部是多线程实现，主要负责界面渲染，脚本执行，事件处理，网络请求
JS引擎vs 渲染引擎（相互独立的）
1.解析执行JS 2.XML解析生成渲染树，显示在屏幕 3.桥接方式通信
渲染进程-多线程工作流程
1.网络线程负责加载网页资源
2.JS引擎解析JS脚本并且执行
3.JS解析引擎空闲时，渲染线程立即工作
4.用户交互、定时器操作等产生回调函数放入任务队列中
5.时间进程进行事件循环，将队列里的任务取出交给JS引擎队列
（事件循环：把队列里的事件回调）
20s时把data回调到现在执行
30s时回调
先输出log(data.now()-now) const now是赋予变量
03chrome 浏览器运行原理
1.如何展示网页
（浏览器地址输入URL后发生了什么）经典面试问题
1.输入处理：ui限制会先看是地址URL请求站点资源还是查询条件（QUERY发送给搜索引擎)
2.开始导航：UI线程通知网络线程发起一个网络请求，来获取站点内容
请求过程中，tab处于loading
3.读取响应：http响应后检查应头的媒体类型
如果是html文件 则将后续内容交给渲染进程 如果拿到其他类型文件（zip.exe)则走的是下载的逻辑
4.寻找渲染进程
网络线程检查后，会告知祝进程数据已准备完毕，祝进程确认后为这个站点寻找一个渲染进程——主进程通过IPC消息告知渲染进程去处理本次导航——渲染进程开始接收数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段
5.资源加载
收到主进程消息后，开始加载html文档资源——还需加载一些子资源，图片，css央视文件或者js脚本
6.构建渲染树
构建dom树，将html文本转化成浏览器能偶理解的结构——构建cssom树，浏览器同样不认识css，需要将css代码转化成可以理解的cssom——构建渲染树，渲染树是dom树和cssom树的结合
7.页面布局
根据渲染树计算每个节点的位置和大小——在浏览器页面区域绘制元素边框——遍历渲染树，将元素以盒模型的形式写入文档流
8.页面绘制
构建图层：为特定节点生成专用图层——绘制图层 一个图层分成很多指令，按指令顺序绘制列表，交给合成线——合成线程接收指令生成图块——栅格线程将图块进行栅格化（gpu加速生成一个一个像素点）——展示在屏幕上
前端性能performance
1.时间都花在哪
2.什么情况下会卡顿
前端优化手段：
首屏优化：
1.压缩、分包、删除无用代码
2.静态资源分离
3.js脚本非阻塞加载
4.缓存策略
5.Ssr
6.预置loading、骨架屏（防止白屏，不在body里挂idel）
渲染优化：
1.gpu加速（透明度改变：像素点改变）在set里设置wellsum属性（？
2.减少回流、重绘（left top?影响布局会回流 tab布局 ui divr工具实现
3.离屏渲染（开辟一段内存缓冲区，在里面渲染好了再添加到显示器上）
解决动画掉帧
4.懒加载（提前加载到本地，从缓存里面去取）
JS优化：
1.防止内存泄漏（用全局变量，dom和JS变量，变量删除了，但是dom没会可能内存泄漏 ，定时器忘记删除，可以放定时清除的定时器
2.循环尽早break或者return
3.合理使用闭包
4.减少dom访问（JS和渲染引擎交互费时间，所以减少dom访问，如果一个dom经常访问可以找一个内存储存起来）
5.防抖、节流（一段时间内多次调用执行一次）
6.Web workers
04跨端容器
为什么需要跨端：
1.开发成本低、效率高
2.一致性体验
3.前端开发生态（解放客户端人力
开发工具：html5 css3 javascript
终端：web 安卓 ios
有哪些跨端方案：
Webview:网页视图，用于加载网页url，并展示其内容动的控件
可以内嵌在移动端app内，实现前端混合开发，大多数混合矿机都是基于webview的二次开发，比如ionic,cordova
常用webview分类：安卓（webview，ios(safiri，国产安卓(uc\qq自己的webview
使用webview的优势：一次开发，处处使用，使用成本低 随时发布，及时更新不用下载安装包， 性能有保障
webview使用原生能力：
javascript调用native
native调用javascript
Webview js bridge进行native通信
1.js环境中提供通信的js bridge
2.native端提供sdk响应js bridge发出的调用
3.前端和客户端分别实现对应模块功能
实现一个简易js bridge
小程序
轻应用时代
2.渲染层：webview
3.双线程 多webview架构
4.数据通信，native转发
React native (rn) wee x
1.原生组件渲染
2.React\vue框架
3.Virtual dom
4.Js bridge
Lynx(字节本公司的）没开源 正考虑向skia迁移
把dom的构建放在native层 js只用管业务逻辑
1.vue
2.Js cor/v8
3.Jsbinding(更高效的js bridge)
4.Native ui/skia
Flutter
1.Widget
2.Dart vm
3.skia图形库
跨端容器通用原理：
1.Ui组件
2.渲染引擎
3.逻辑控制引擎
4.通信桥梁
5.底层api抹平表现差异
跨端方案对比：
同样是web view渲染，小程序为什么体验比web view更流畅？
预缓存，基于webview把一些危险操作都封死了，收口
未来的跨端方案？
回归webview，性能体验不是最好的，但却是最广的（前端开发
⭐️：比较重要
