客户端容器 ｜ 青训营笔记

嬛嬛ya
164 阅读6分钟

image.png

01-浏览器架构

  • 浏览器架构演进
    • 单进程架构:所有模块运行在同一个进程里，包含网络、插件、JavaScript运行环境等
    • 多进程架构:主进程、网络进程、渲染进程、GPU进程、插件进程
    • 面向服务架构:将原来的UI、数据库、文件、设备、网络等，作为一个独立的基础服务

image.png

  • 浏览器架构对比

image.png

① 浏览器架构-任务管理器

image.png

②浏览器架构-多进程分工

image.png

思考

  1. 为什么会有单进程架构？

受硬件限制，早期的内存较昂贵，每一个进程都会有一些基础的框架，会占系统资源，单进程会节约这些资源。

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

我认为会替代多进程架构，如果是在性能比较好的设备上的话，会做成面向服务架构，它将帮助企业系统架构师以更迅速、更可靠、更具重用性架构整个系统，但是在性能不好的设备上也会退化成多进程架构。

02-渲染进程

  • 常见浏览器内核

image.png

  • 渲染进程-多线程架构

内部是多线程实现，主要负责页面渲染，脚本执行，事件处理，网络请求等。

image (1).png

image (2).png

  • JS引擎 VS 渲染引擎

    • 解析执行JS
    • XML解析生成
    • 桥接方式通信

image.png

  • 渲染进程-多线程工作流程

    • 网络鲜橙负责加载网页资源
    • JS引擎解析JS脚本并且执行
    • JS解析引擎空闲时，渲染线程立即工作
    • 用户交互、定时器操作等产生回调函数放入任务队列中
    • 事件线程进行事件循环，将队列里的任务取出交给JS引擎执行

image (1).png

03-Chrome运行原理

  • Chrome运行原理-如何展示网页

image.png

  • Chrome运行原理-输入处理

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

image (1).png

  • Chrome运行原理-开始导航

    • 当用户按下回车，UI线程通知网络线程发起一个网络请求，来获取站点内容
    • 请求过程中，tab处于loading状态

  • Chrome运行原理-读取响应

    • 网络线程接收到HTTP响应后，先检查响应头的媒体类型（MIME Type）
    • 如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理
    • 如果拿到的是其他类型文件，比如：zip、exe等，则交给下载管理器处理

image (2).png

  • Chrome运行原理-寻找渲染进程

    • 网络线程做完所有检查后,会告知主进程数据已准备完毕,主进程确认后为这个站点寻找一个渲染进程
    • 主进程通过IPC消息告知渲染进程去处理本次导航
    • 渲染进程开始接收数据并告知主进程自己已开始处理,导航结束,进入文档加载阶段

  • 渲染进程-资源加载

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

image.png

  • 渲染进程-构建渲染树

    • 构建DOM树，将HTML文件转化成浏览器够理解的结构
    • 构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化成可理解的CSSOM
    • 构建渲染树，渲染树是DOM树和CSSOM树的结合

image.png

  • 渲染进程-页面进程

    • 根据渲染树计算每个节点的位置和大小
    • 在浏览器页面区域绘制元素边框
    • 遍历渲染树，将元素以盒模型的形式写入文档流

image.png

  • 渲染进程-页面绘制

    • 构建图层：为特定的节点生成专用图层
    • 绘制图层：一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程
    • 合成线程接收指令生成图块
    • 栅格线程将图块进行栅格化
    • 展示在屏幕上

image.png

image.png

04-跨端容器

  • 为什么要跨端

    • 开发成本、效率
    • 一致性体验
    • 前端开发生态

  • 有哪些跨端方案

    • webview
    • 小程序
    • RN/WeeX
    • Lynx
    • Flutter

  • 跨端容器-WebView

    1、WebView，即网页视图，用于加载网页Url，并展示其内容的组件

    2、可以内嵌在移动端App内，实现前端混合开发，大多数混合框架都是基于WebView的二次开发；比如Ionic、Cordova

  • 跨端容器-常用WebView分类

    WebView、Android、IOS、国产Android

image (1).png

  • 跨端容器-使用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通信

    • JS环境中提供通信的JSBridge
    • Native端提供SDK响应JSBridge发出的调用
    • 前端和客户端分别实现对应功能模块

  • 跨端容器-小程序

    • 微信、支付宝、百度小程序、小米直达号
    • 渲染层-webview
    • 双线程,多webview架构
    • 数据通信,Native转发

  • 跨端容器-React Native/WeeX

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

  • 跨端容器-Lynx

    • Vue
    • JS Core/V8
    • JSBinding
    • Native Ul/Skia

  • 跨端容器-Flutter

    • wideget
    • dart vm
    • skia图形库

  • 跨端容器-通用原理

    • UI组件
    • 渲染引擎
    • 逻辑控制引擎
    • 通信桥梁
    • 底层API抹平表现差异

思考

1、同样是基于webview渲染，为什么小程序体验会比webview流畅？

普通的WebView要去在服务器下载资源，小程序会把要的资源先下载下来，使用的资源是本地的，所以会流畅很多。小程序基于WebView上精致很多，有些操作是封死的状态，体验感就好一些。

2、未来的跨端方案会是什么？

①IoT方向发展

现阶段IoT行业得益于技术爆炸和市场需求的不断扩大，IoT拥有可观的前景。物联网可以很好地提高效率和节约成本，比如我们熟悉的智能家电、空调、电视等，都可以方便地联网。

②桌面小程序

为了适应社会的快节奏，我们越来越注重移动端和桌面设备的数据同步，在移动端的应用功能也希望在桌面终端使用。有了桌面小程序后，就不用在电脑看着微信提示

image.png

image.png

avatar
文章
阅读
粉丝