浏览器架构
浏览器架构演进
- 单进程架构:所有模块运行在同一个进程里,包含网络、插件、JavaScripti运行环境等
- 多进程架构:主进程、网络进程、渲染进程、GPU进程、插件进程
- 面向服务架构:将原来的U儿、数据库、文件、设备、网络等,作为一个独立的基础服务
浏览器架构对比
浏览器架构-任务管理器
浏览器架构-多进程分工
浏览器架构-思考??
- 为什么会有单进程架构?
- 面向服务架构是否会替代多进程架构?
渲染进程
常见浏览器内核
渲染进程-多线程架构
内部是多线程实现,主要负责页面渲染,脚本执行,事件处理,网络请求等
JS引擎VS渲染引擎
- 解析执行JS
- ML解析生成渲染树,显示在屏幕
- 桥接方式通信
渲染进程-多线程工作流程
- 网络线程负责加载网页资源
- JS引擎解析S脚本并且执行
- JS解析引擎空闲时,渲染线程立即工作
- 用户交互、定时器操作等产生回调函数放入任务队列中
- 事件线程进行事件循环,将队列里的任务取出交给S引擎执行
一道笔试题
以下代码在浏览器环境下输出顺序、内容
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) //输出??
渲染进程-资源加载
- 收到主进程的消息后,开始加载HTML文档
- 除此之外,还需要加载子资源,比如一些图片,CSS样式文件以及JavaScript脚本
渲染进程-构建渲染树
1.构建DOM树,将HTML文本转化成浏览器能多理解的结构 2.构建CSSOM树,浏览器同样不认识CSS,需要将CSS代码转化为可理解的CSSOM 3.构建渲染树,渲染树是DOM树和CSSOM树的结合
渲染进程-页面布局
- 根据渲染树计算每个节点的位置和大小
- 在浏览器页面区域绘制元素边框
- 遍历渲染树,将元素以盒模型的形式写入文档流
渲染进程-页面绘制
- 构建图层:为特定的节点生成专用图层
- 绘制图层:一个图层分成很多绘制指令,然后将这些指令按顺序组成一个绘制列表,交给合成线程
- 合成线程接收指令生成图块
- 栅格线程将图块进行栅格化
- 展示在屏幕上
前端性能performance
- 时间都花在哪
- 什么情况下卡顿
首屏优化
- 压缩、分包、删除无用代码
- 静态资源分离
- JS脚本非阻塞加载
- 缓存策略
- SSR
- 预置loading、骨架屏
渲染优化
- GPU加速
- 减少回流、重绘
- 离屏渲染
- 懒加载
JS优化
- 防止内存泄漏
- 循环尽早break
- 合理使用闭包
- 减少Dom访问
- 防抖、节流
- Web Workers
Chrome运行原理
Chrome运行原理-如何展示网页
浏览器地址输入URL后发生了什么
Chrome运行原理-输入处理
- 用户U框输入内容的后,U川线程会判断输入的是一个URL地址呢,还是一个quey查询条件
- 如果是URL,直接清求站点资源
- 如果是query,将输入发送给搜索引擎
Chrome运行原理-开始导航
- 当用户按下回车,U线程通知网络线程发起一个网络请求,来获取站点内容
- 请求过程中,tab处于loading状态
Chrome运行原理-读取响应
- 网络线程接收到HTTP响应后,先检查响应头的媒体类型(MIME Type)
- 如果响应主体是一个HTML文件,浏览器将内容交给渲染进程处理
- 如果拿到的是其他类型文件,比如zip、exe等,则交给下载管理器处理
Chrome运行原理-寻找渲染进程
- 网络线程做完所有检查后,会告知主进程数据已准备完毕,主进程确认后为这个站点寻找一个渲染进程
- 主进程通过PC消息告知渲染进程去处理本次导航
- 渲染进程开始接收数据并告知主进程自己已开始处理,导航结束,进入文档加载阶段
跨端容器
为什么需要跨端
- 开发成本、效率
- 一致性体验
- 前端开发生态
有哪些跨端方案
- webview
- 小程序
- RNMeeX
- Lynx
- Flutter
跨端容器-WebView
- Webview,即网页视图,用于加载网页Url,并展示其内容的控件
- 可以内嵌在移动端App内,实现前端混合开发,大多数混合框架都是基于Vebview的二次开发;比如lonic、Cordova
跨端容器-常用NWebView分类
常用webview,Android,IOS、国产Android
跨端容器-使用WebView优势
- 一次开发,处处使用,学习成本低
- 随时发布,即时更新,不用下载安装包
- 移动设备性能不断提升,性能有保障
- 通过JSBridge和原生系统交互,实现复杂功能
跨端容器-WebView使用原生能力
Javascript调用Native
- API注入:Native获取]avascript环境上下文,对其挂载的对象或者方法进行拦截
- 使用Webview URL Scheme跳转拦截
- lOS上window.webkit.messageHandler直接通信
Native调用Javascript
- 直接通过webview暴露的API执行JS代码
- lOS webview.string ByEvaluatingJavaScriptFromString
- Android webview.evaluateJavascript
跨端容器-VebView<->Native通信
- JS环境中提供通信的JSBridge
- Native端提供SDK响应JSBridge发出的调用
- 前端和客户端分别实现对应功能模块
跨端容器-实现一个简易]SBridge
interface CallArgs {
callId:string //调用Id,唯一标识
module:string //调用模块
method:string //调用方法
data:any //参数
}
const Callbacks={} //存放回调函数callId为key
function applyNative = (payload:CallArgs,callback:Function) => {
const callId = prefix + callTime++
Callbacks[callId] = callback
const Argso: CallArgs = {
callId: callId,
module: payload.module || 'layout',
method: payload.method || 'randomsize',
data: payload.data,
}
if(IOS) {
return window.webkitURL.messageHandler.postMessage(JSON.stringify(Args0))
}else {
//Android对window上约定的对象进行拦截
return window.AndroidBridge(JSON.stringify(Argso))
}
}
interface ResponseArgs {
responseId:string //回调Id,与callId对应
errCode:number
errMsg?:string
data:unknown
}
//native端调用webview,参数都经过序列化
const applywebview = (res:string)=> {
const response = JSON.parse(res) as ResponseArgs
const { responseld } = response
//从Cal1 backs找到对应的回调处理方法
if(type of Callbacks[responseId] == 'function') {
Callbacks[responseId](response)
//回调后删除该次回调函数
delete Callbacks [responseId]
}
}
window.JSBridge =
applyNative,
applyWebview //挂载在vindow.上,供native直接调用
}
跨端容器-小程序
- 微信、支付宝、百度小程序、小米直达号
- 渲染层-Webview
- 双线程,多webview架构
- 数据通信,Native转发
跨端容器-React Native/WeeX
- 原生组件渲染
- React/ue框架
- virtual dom
- JSBridge
跨端容器-Lynx
- Vue
- JS Core V8
- JSBinding
- Native Ul Skia
跨端容器-Flutter
- wideget
- dart vm
- skia图形库
跨端容器-通用原理
- UI组件
- 渲染引擎
- 逻辑控制引擎
- 通信桥梁
- 底层AP抹平表现差异
跨端方案对比
跨端容器-思考?
- 同样是基于webview渲染,为什么小程序体验比webview流畅
- 未来的跨端方案会是什么