客户端容器的笔记

Keria23333
107 阅读6分钟

浏览器架构：

1 单进程：所有模块运行在同一个进程里（网络，插件，js（这样可能会导致CPU单核压力过大。。。。。））

2 多进程：主进程，网络，插件，GPU，渲染有各自的进程（不会因为单一任务崩溃影响到后续任务的执行）

3 面向服务架构：原本的ui等作为单独的服务

架构对比

2 3 做了沙盒隔离；崩溃一个不会连坐后面的进程；

任务管理器

浏览器多进程分工：

为什么会有单进程架构？

以前硬件太拉，为了压缩算力的无奈之举。

面向服务架构是否会替代多进程架构？

有可能会被替代。

渲染进程

主要包含：

主线程（Main thread）(下载资源、执行js、计算样式、进行布局、绘制合成)

光栅线程（Raster thread）

合成线程（Compositor thread）

工作线程（Worker thread）

渲染进程内部（）

解释&执行JS

XML解析生成渲染树，显示在屏幕

NAT方式通信

过程图解：

多进程工作

网络线程负责加载网页资源

JS引擎解析JS脚本并执行

JS解析引擎空闲时，渲染进程立即工作

用户交互、定时器操作等产生回调函数放入任务队列中

事件线程进行事件循环，将队列里的任务 取出交给JS引擎执行

图解

chrome原理

如图

具体的：

1.输入处理：

  • 用户URL框输入内容后，UI 线程会判断输入的时一个URL地址呢还是一个query查询条件；
      • 如果是URL，直接请求站点资源；
      • 如果是query，将输入发送给搜索引擎。

2.开始导航：

  • 当用户按下回车，UI线程通知网络线程发起一个网络请求，来获取站点内容；
  • 请求过程中，tab页处于loading状态
  1. 读取响应：
  • 网络线程接受到HTTP响应后，先检查响应头的媒体类型（MIME type）；
  • 如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理；
  • 如果拿到的是其他类型文件，比如zip、exe等，则交给下载管理器处理。
  • 如图
  • 4.寻找渲染进程：
  • 网络线程做完所有检查后，会告知主进程数据已经准备完毕，主进程确认后为这个站点寻找一个渲染进程；
  • 主进程通过IPC消息告知渲染进程去处理本次导航；
  • 渲染进程开始接受数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段。

5.渲染进程-资源加载：

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

6.渲染进程-构建渲染树：

  • 构建DOM树，将HTML文本转化成浏览器能够理解的结构；
  • 构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解的CSSOM；
  • 构建渲染树，渲染树是DOM树和CSSOM树的结合。
  • 7.页面布局

CPU根据渲染树计算每个节点的位置和大小，再在浏览器页面区域绘制元素边框

同时遍历渲染树，将元素以盒模型的形式写入文档流

前端性能performance的优化

时间花在哪儿

解析，等待资源加载 占大头

首屏优化的措施

  • 压缩、分包、删除无用代码
  • 静态资源分离（服务、资源分离）
  • JS脚本非阻塞加载
  • 缓存策略
  • SSR
  • 预置loading、骨架屏

渲染优化

  • GPU加速：一般是利用CSS 3
  • 减少回流、重绘
  • 离屏渲染：完成后直接展示结果，对立于非离屏渲染的过程展示式渲染
  • 懒加载

JS优化

  • 防止内存泄漏
  • 循环尽早break
  • 合理使用闭包
  • 减少DOM访问
  • 防抖、节流
  • Web Worker

跨端容器

为什么需要跨端

  • 开发成本、效率
  • 一致性体验
  • 前端开发生态
  • （人话：统一写作代码的标准）

有哪些跨端方案

  • webview（***）
  • 小程序
  • RN 、Weex
  • Lynx
  • Flutter

webview

Webview，即网页视图，用于加载网页Url,并展示其内容的控件。

常用iOS，Android（国内和其他）

可以内嵌在移动端App内，实现前端混合开发，大多数混合框架都是基于Webview的二次开发：比如lonic、Cordova、uniapp。

优点：

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

webvivew与原生能力的通信（js与native互相调用）

Javascript调用Native：

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

Native调用Javascript：

  • 直接通过webview暴露的API执行JS代码

  • IOS方法：webview.stringByEvaluatingJavaScriptFromString

  • Android方法：webview.evaluateJavascript

实现一个简单的JSBridge:（来自飞书安酱的笔记，因为视频的代码看不清T.T）

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 Args0: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{
// 安卓对window上约定的对象进行拦截
return window.AndroidBridge(JSON.stringify(Args0))
}
}

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 {responseId} = response
// 从Callbacks找到对应的回调处理方法
if(typeof Callbacks[responseId]) === 'function'{
CallbacksresponseId
// 回调后删除该次回调函数
delete Callbacks[responseId]
}
}

// 挂在在window上，供native直接调用
window.JSBridge = {
applyNative,
applyWebview
}

小程序

常见小程序：微信小程序、支付宝小程序、百度小程序、小米直达号

小程序架构：

  • 渲染层-webview
  • 双线程，多webview架构,数据和渲染隔离
  • 数据通信，Native转发

React Native / Weex

  • 原生组件渲染
  • React / Vue 框架
  • virtual dom
  • JSBridge

在安卓和IOS中展示是不一样的，因为底层还是调用的安卓或IOS的底层组件(感觉和API的调用关系很大)。

字节自研Lynx(未开源）

Flutter

  • wideget（告诉用户当前状态的视图的样子）
  • dart vm（搭建源的虚拟环境）
  • skia图形库

通用原理：各种桥梁

方案对比

ps：未来大概率回归webview

总结

avatar
文章
阅读
粉丝